Subtitle Filtering 2022 #18
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
/preview |
softworkz
force-pushed
the
submit_subfiltering
branch
from
b9ab108 to
25cb9c8
Compare
softworkz
force-pushed
the
submit_subfiltering
branch
from
25cb9c8 to
a764c14
Compare
|
There is an issue in commit 8e1a90b: |
softworkz
force-pushed
the
submit_subfiltering
branch
from
a764c14 to
c001133
Compare
|
/submit |
|
Submitted as [email protected] To fetch this version into To fetch this version to local tag |
![ffmpeg-codebot[bot]](https://avatars.githubusercontent.com/in/158557?s=60&v=4){kind=small}
…al subtitles Signed-off-by: softworkz <[email protected]>
Signed-off-by: softworkz <[email protected]>
Added a text2graphicsub subtitle filter which converts text-based subtitle tracks to bitmap-based subtitle tracks. The filter uses libass to render the subtitles. It takes as parameters an output height and width, as well as a number of colors in the output palette as well as sources of fonts. All its arguments are optional. Reviewed-by: softworkz <[email protected]> Signed-off-by: softworkz <[email protected]> Signed-off-by: tcoza <[email protected]>
Signed-off-by: softworkz <[email protected]>
and provide a compatibility shim for the legacy api Signed-off-by: softworkz <[email protected]>
…itle encoding This commit actually enables subtitle filtering in ffmpeg by sending and receiving subtitle frames to and from a filtergraph. The heartbeat functionality from the previous sub2video implementation is removed and now provided by the 'subfeed' filter. The other part of sub2video functionality is retained by auto-insertion of the new graphicsub2video filter. Justification for changed test refs: - sub2video The previous results were incorrect. The command line for this test specifies -r 5 (5 frames per second), which is now fulfilled by the additional frames in the reference output. Example: The first subtitle time is 499000, the second is 15355000, which means 0.5s and 15.35s with a difference of 14.85s. 15s * 5fps = 75 frames and that's now the exact number of video frames between these two subtitle events. - sub2video_basic The previous results had some incorrect output because multiple frames had the same dts The non-empty content frames are visually identical, the different CRC is due to the different blending algorithm that is being used. - sub2video_time_limited Subtitle frames are emitted to the filter graphs at a 5 fps rate by default. The time limit for this test is 15s * 5fps = 75 frames which matches the count in the new ref. - sub-dvb Running ffprobe -show_frames on the source file shows that there are 7 subtitle frames with 0 rects in the source at the start and 2 at the end. This translates to the 14 and 4 additional entries in the new test results. - filter-overlay-dvdsub-2397 Overlay results have slightly different CRCs due to different blending implementation - sub-scc The first entry is no longer in the output because it is before the actual start time and the strim filter removes such entries now (like for video and audio) Signed-off-by: softworkz <[email protected]>
softworkz
force-pushed
the
submit_subfiltering
branch
from
fa0d5eb to
c5487d7
Compare
|
/submit |
|
Submitted as [email protected] To fetch this version into To fetch this version to local tag |
The previous code expected a segment of type CLUT definition to exist in order to accept a set of segments to be complete. This was an incorrect assumption as the presence of a CLUT segment is not mandatory. (version 1.6.1 of the spec is probably a bit more clear about this than earlier versions: https://www.etsi.org/deliver/etsi_en/ 300700_300799/300743/01.06.01_20/en_300743v010601a.pdf) The flawed condition prevented proper fallback to using the default resolution for the decoding context. Signed-off-by: softworkz <[email protected]>
softworkz
force-pushed
the
submit_subfiltering
branch
from
c5487d7 to
bb11798
Compare
|
/submit |
|
Submitted as [email protected] To fetch this version into To fetch this version to local tag |
| @@ -77,6 +77,7 @@ HEADERS = adler32.h \ | |||
| sha512.h \ | |||
There was a problem hiding this comment.
On the FFmpeg mailing list, Hendrik Leppkes wrote (reply to this):
On Tue, Oct 25, 2022 at 11:14 AM softworkz <[email protected]> wrote:
>
> @@ -712,6 +712,53 @@ typedef struct AVFrame {
> * Duration of the frame, in the same units as pts. 0 if unknown.
> */
> int64_t duration;
> +
> + /**
> + * Media type of the frame (audio, video, subtitles..)
> + *
> + * See AVMEDIA_TYPE_xxx
> + */
> + enum AVMediaType type;
> +
> + /**
> + * Number of items in the @ref subtitle_areas array.
> + */
> + unsigned num_subtitle_areas;
> +
> + /**
> + * Array of subtitle areas, may be empty.
> + */
> + AVSubtitleArea **subtitle_areas;
> +
> + /**
> + * Header containing style information for text subtitles.
> + */
> + AVBufferRef *subtitle_header;
> +
> + /**
> + * Indicates that a subtitle frame is a repeated frame for arbitrating flow
> + * in a filter graph.
> + * The field subtitle_timing.start_pts always indicates the original presentation
> + * time, while the frame's pts field may be different.
> + */
> + int repeat_sub;
> +
> + struct SubtitleTiming
> + {
> + /**
> + * The display start time, in AV_TIME_BASE.
> + *
> + * For subtitle frames, AVFrame.pts is populated from the packet pts value,
> + * which is not always the same as this value.
> + */
> + int64_t start_pts;
There is still no explanation here why they are not the same, why they
could not just be the same, and which field a user should look at.
The cover letter talks about clarity why this is needed is important,
but then provides none of that.
"Its required" is not an argument. So please enlighten us once again
why we absolutely need two timestamps for subtitles, instead of just
one. As far as I can see, subtitle frames only have one relevant time
- when its supposed to be shown on the screen. What would the other
time ever be good for to a user?
Similarly for the duration, of course. I can even see the
AVFrame.duration field in this patch snippet just above the additions
that would seem to fully replace this one.
- Hendrik
> +
> + /**
> + * Display duration, in AV_TIME_BASE.
> + */
> + int64_t duration;
> +
> + } subtitle_timing;
> } AVFrame;
>
>
> @@ -788,6 +835,8 @@ void av_frame_move_ref(AVFrame *dst, AVFrame *src);
> /**
> * Allocate new buffer(s) for audio or video data.
> *
> + * Note: For subtitle data, use av_frame_get_buffer2
> + *
> * The following fields must be set on frame before calling this function:
> * - format (pixel format for video, sample format for audio)
> * - width and height for video
> @@ -807,9 +856,39 @@ void av_frame_move_ref(AVFrame *dst, AVFrame *src);
> * recommended to pass 0 here unless you know what you are doing.
> *
> * @return 0 on success, a negative AVERROR on error.
> + *
> + * @deprecated Use @ref av_frame_get_buffer2 instead and set @ref AVFrame.type
> + * before calling.
> */
> +attribute_deprecated
> int av_frame_get_buffer(AVFrame *frame, int align);
>
> +/**
> + * Allocate new buffer(s) for audio, video or subtitle data.
> + *
> + * The following fields must be set on frame before calling this function:
> + * - format (pixel format for video, sample format for audio)
> + * - width and height for video
> + * - nb_samples and channel_layout for audio
> + * - type (AVMediaType)
> + *
> + * This function will fill AVFrame.data and AVFrame.buf arrays and, if
> + * necessary, allocate and fill AVFrame.extended_data and AVFrame.extended_buf.
> + * For planar formats, one buffer will be allocated for each plane.
> + *
> + * @warning: if frame already has been allocated, calling this function will
> + * leak memory. In addition, undefined behavior can occur in certain
> + * cases.
> + *
> + * @param frame frame in which to store the new buffers.
> + * @param align Required buffer size alignment. If equal to 0, alignment will be
> + * chosen automatically for the current CPU. It is highly
> + * recommended to pass 0 here unless you know what you are doing.
> + *
> + * @return 0 on success, a negative AVERROR on error.
> + */
> +int av_frame_get_buffer2(AVFrame *frame, int align);
> +
> /**
> * Check if the frame data is writable.
> *
> diff --git a/libavutil/subfmt.c b/libavutil/subfmt.c
> new file mode 100644
> index 0000000000..c72ebe2a43
> --- /dev/null
> +++ b/libavutil/subfmt.c
> @@ -0,0 +1,45 @@
> +/*
> + * Copyright (c) 2021 softworkz
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
> + */
> +
> +#include <string.h>
> +#include "common.h"
> +#include "subfmt.h"
> +
> +static const char sub_fmt_info[AV_SUBTITLE_FMT_NB][24] = {
> + [AV_SUBTITLE_FMT_UNKNOWN] = "Unknown subtitle format",
> + [AV_SUBTITLE_FMT_BITMAP] = "Graphical subtitles",
> + [AV_SUBTITLE_FMT_TEXT] = "Text subtitles (plain)",
> + [AV_SUBTITLE_FMT_ASS] = "Text subtitles (ass)",
> +};
> +
> +const char *av_get_subtitle_fmt_name(enum AVSubtitleType sub_fmt)
> +{
> + if (sub_fmt < 0 || sub_fmt >= AV_SUBTITLE_FMT_NB)
> + return NULL;
> + return sub_fmt_info[sub_fmt];
> +}
> +
> +enum AVSubtitleType av_get_subtitle_fmt(const char *name)
> +{
> + for (int i = 0; i < AV_SUBTITLE_FMT_NB; i++)
> + if (!strcmp(sub_fmt_info[i], name))
> + return i;
> + return AV_SUBTITLE_FMT_NONE;
> +}
> diff --git a/libavutil/subfmt.h b/libavutil/subfmt.h
> index 791b45519f..3b8a0613b2 100644
> --- a/libavutil/subfmt.h
> +++ b/libavutil/subfmt.h
> @@ -21,6 +21,9 @@
> #ifndef AVUTIL_SUBFMT_H
> #define AVUTIL_SUBFMT_H
>
> +#include <stdint.h>
> +
> +#include "buffer.h"
> #include "version.h"
>
> enum AVSubtitleType {
> @@ -65,4 +68,48 @@ enum AVSubtitleType {
> AV_SUBTITLE_FMT_NB, ///< number of subtitle formats, DO NOT USE THIS if you want to link with shared libav* because the number of formats might differ between versions.
> };
>
> +typedef struct AVSubtitleArea {
> +#define AV_NUM_BUFFER_POINTERS 1
> +
> + enum AVSubtitleType type;
> + int flags;
> +
> + int x; ///< top left corner of area.
> + int y; ///< top left corner of area.
> + int w; ///< width of area.
> + int h; ///< height of area.
> + int nb_colors; ///< number of colors in bitmap palette (@ref pal).
> +
> + /**
> + * Buffers and line sizes for the bitmap of this subtitle.
> + *
> + * @{
> + */
> + AVBufferRef *buf[AV_NUM_BUFFER_POINTERS];
> + int linesize[AV_NUM_BUFFER_POINTERS];
> + /**
> + * @}
> + */
> +
> + uint32_t pal[256]; ///< RGBA palette for the bitmap.
> +
> + char *text; ///< 0-terminated plain UTF-8 text
> + char *ass; ///< 0-terminated ASS/SSA compatible event line.
> +
> +} AVSubtitleArea;
> +
> +/**
> + * Return the name of sub_fmt, or NULL if sub_fmt is not
> + * recognized.
> + */
> +const char *av_get_subtitle_fmt_name(enum AVSubtitleType sub_fmt);
> +
> +/**
> + * Return a subtitle format corresponding to name, or AV_SUBTITLE_FMT_NONE
> + * on error.
> + *
> + * @param name Subtitle format name.
> + */
> +enum AVSubtitleType av_get_subtitle_fmt(const char *name);
> +
> #endif /* AVUTIL_SUBFMT_H */
> --
> ffmpeg-codebot
>
> _______________________________________________
> ffmpeg-devel mailing list
> [email protected]
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> [email protected] with subject "unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
[email protected]
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
[email protected] with subject "unsubscribe".
There was a problem hiding this comment.
On the FFmpeg mailing list, Soft Works wrote (reply to this):
> -----Original Message-----
> From: ffmpeg-devel <[email protected]> On Behalf Of
> Hendrik Leppkes
> Sent: Tuesday, October 25, 2022 11:38 AM
> To: FFmpeg development discussions and patches <ffmpeg-
> [email protected]>
> Subject: Re: [FFmpeg-devel] [PATCH v9 02/25] avutil/frame: Prepare
> AVFrame for subtitle handling
>
> On Tue, Oct 25, 2022 at 11:14 AM softworkz <[email protected]>
> wrote:
> >
> > @@ -712,6 +712,53 @@ typedef struct AVFrame {
> > * Duration of the frame, in the same units as pts. 0 if
> unknown.
> > */
> > int64_t duration;
> > +
> > + /**
> > + * Media type of the frame (audio, video, subtitles..)
> > + *
> > + * See AVMEDIA_TYPE_xxx
> > + */
> > + enum AVMediaType type;
> > +
> > + /**
> > + * Number of items in the @ref subtitle_areas array.
> > + */
> > + unsigned num_subtitle_areas;
> > +
> > + /**
> > + * Array of subtitle areas, may be empty.
> > + */
> > + AVSubtitleArea **subtitle_areas;
> > +
> > + /**
> > + * Header containing style information for text subtitles.
> > + */
> > + AVBufferRef *subtitle_header;
> > +
> > + /**
> > + * Indicates that a subtitle frame is a repeated frame for
> arbitrating flow
> > + * in a filter graph.
> > + * The field subtitle_timing.start_pts always indicates the
> original presentation
> > + * time, while the frame's pts field may be different.
> > + */
> > + int repeat_sub;
> > +
> > + struct SubtitleTiming
> > + {
> > + /**
> > + * The display start time, in AV_TIME_BASE.
> > + *
> > + * For subtitle frames, AVFrame.pts is populated from the
> packet pts value,
> > + * which is not always the same as this value.
> > + */
> > + int64_t start_pts;
>
> There is still no explanation here why they are not the same, why
> they
> could not just be the same, and which field a user should look at.
> The cover letter talks about clarity why this is needed is important,
> but then provides none of that.
>
> "Its required" is not an argument. So please enlighten us once again
> why we absolutely need two timestamps for subtitles, instead of just
> one. As far as I can see, subtitle frames only have one relevant time
> - when its supposed to be shown on the screen. What would the other
> time ever be good for to a user?
> Similarly for the duration, of course. I can even see the
> AVFrame.duration field in this patch snippet just above the additions
> that would seem to fully replace this one.
>
> - Hendrik
Hi Hendrik,
thanks a lot for your reply.
Probably I should have better advertised the article I had written
specifically to explain the background of this:
https://github.com/softworkz/SubtitleFilteringDemos/issues/1
I hope it's understandable - please let me know when you have
questions.
Thanks again,
softworkz
_______________________________________________
ffmpeg-devel mailing list
[email protected]
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
[email protected] with subject "unsubscribe".
There was a problem hiding this comment.
On the FFmpeg mailing list, Soft Works wrote (reply to this):
> -----Original Message-----
> From: ffmpeg-devel <[email protected]> On Behalf Of
> Soft Works
> Sent: Tuesday, October 25, 2022 11:59 AM
> To: FFmpeg development discussions and patches <ffmpeg-
> [email protected]>
> Subject: Re: [FFmpeg-devel] [PATCH v9 02/25] avutil/frame: Prepare
> AVFrame for subtitle handling
>
>
>
> > -----Original Message-----
> > From: ffmpeg-devel <[email protected]> On Behalf Of
> > Hendrik Leppkes
> > Sent: Tuesday, October 25, 2022 11:38 AM
> > To: FFmpeg development discussions and patches <ffmpeg-
> > [email protected]>
> > Subject: Re: [FFmpeg-devel] [PATCH v9 02/25] avutil/frame: Prepare
> > AVFrame for subtitle handling
> >
> > On Tue, Oct 25, 2022 at 11:14 AM softworkz <[email protected]>
> > wrote:
> > >
> > > @@ -712,6 +712,53 @@ typedef struct AVFrame {
> > > * Duration of the frame, in the same units as pts. 0 if
> > unknown.
> > > */
> > > int64_t duration;
> > > +
> > > + /**
> > > + * Media type of the frame (audio, video, subtitles..)
> > > + *
> > > + * See AVMEDIA_TYPE_xxx
> > > + */
> > > + enum AVMediaType type;
> > > +
> > > + /**
> > > + * Number of items in the @ref subtitle_areas array.
> > > + */
> > > + unsigned num_subtitle_areas;
> > > +
> > > + /**
> > > + * Array of subtitle areas, may be empty.
> > > + */
> > > + AVSubtitleArea **subtitle_areas;
> > > +
> > > + /**
> > > + * Header containing style information for text subtitles.
> > > + */
> > > + AVBufferRef *subtitle_header;
> > > +
> > > + /**
> > > + * Indicates that a subtitle frame is a repeated frame for
> > arbitrating flow
> > > + * in a filter graph.
> > > + * The field subtitle_timing.start_pts always indicates the
> > original presentation
> > > + * time, while the frame's pts field may be different.
> > > + */
> > > + int repeat_sub;
> > > +
> > > + struct SubtitleTiming
> > > + {
> > > + /**
> > > + * The display start time, in AV_TIME_BASE.
> > > + *
> > > + * For subtitle frames, AVFrame.pts is populated from
> the
> > packet pts value,
> > > + * which is not always the same as this value.
> > > + */
> > > + int64_t start_pts;
> >
> > There is still no explanation here why they are not the same, why
> > they
> > could not just be the same, and which field a user should look at.
> > The cover letter talks about clarity why this is needed is
> important,
> > but then provides none of that.
> >
> > "Its required" is not an argument. So please enlighten us once
> again
> > why we absolutely need two timestamps for subtitles, instead of
> just
> > one. As far as I can see, subtitle frames only have one relevant
> time
> > - when its supposed to be shown on the screen. What would the other
> > time ever be good for to a user?
> > Similarly for the duration, of course. I can even see the
> > AVFrame.duration field in this patch snippet just above the
> additions
> > that would seem to fully replace this one.
> >
> > - Hendrik
>
> Hi Hendrik,
>
> thanks a lot for your reply.
>
> Probably I should have better advertised the article I had written
> specifically to explain the background of this:
>
> https://github.com/softworkz/SubtitleFilteringDemos/issues/1
@Hendrik - did that answer your question?
You are also welcome to contact me directly for discussing details
or going through specific examples; or just to ping me for logging
on to IRC for chat.
softworkz
_______________________________________________
ffmpeg-devel mailing list
[email protected]
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
[email protected] with subject "unsubscribe".
|
User |
|
User |
| @@ -24,68 +24,193 @@ | |||
| #include <string.h> | |||
There was a problem hiding this comment.
On the FFmpeg mailing list, Michael Niedermayer wrote (reply to this):
--===============1175881865082314697==
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="l0l+eSofNeLXHSnY"
Content-Disposition: inline
--l0l+eSofNeLXHSnY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Oct 25, 2022 at 09:13:44AM +0000, softworkz wrote:
> From: softworkz <[email protected]>
>=20
> and provide a compatibility shim for the legacy api
>=20
> Signed-off-by: softworkz <[email protected]>
> ---
> libavcodec/assenc.c | 189 ++++++++++++++++++++++++++++++------
> libavcodec/avcodec.h | 5 +-
> libavcodec/codec_internal.h | 12 ---
> libavcodec/dvbsubenc.c | 96 ++++++++++--------
> libavcodec/dvdsubenc.c | 103 ++++++++++++--------
> libavcodec/encode.c | 61 +++++++++++-
> libavcodec/movtextenc.c | 114 ++++++++++++++++------
> libavcodec/srtenc.c | 108 ++++++++++++++-------
> libavcodec/tests/avcodec.c | 5 +-
> libavcodec/ttmlenc.c | 101 ++++++++++++++-----
> libavcodec/utils.c | 1 -
> libavcodec/webvttenc.c | 86 +++++++++++-----
> libavcodec/xsubenc.c | 88 ++++++++++-------
> 13 files changed, 689 insertions(+), 280 deletions(-)
Causes this testcase to fail:
=2E/ffmpeg -i 'bgc.sub.dub.ogm' -vframes 3 -bitexact -y nosubs.webm
https://samples.ffmpeg.org/ogg/
I did not investgate why or if this a bug or expected. Just reporting a dif=
ference
ive seen
thx
[...]
--=20
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes
--l0l+eSofNeLXHSnY
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCY1rFogAKCRBhHseHBAsP
q0GUAJ4ruktwZAPMK9T2QMRBO1ikUnVDZQCffgDCPU3M8x+JM5bkMUhFzyzBjRU=
=Sw6W
-----END PGP SIGNATURE-----
--l0l+eSofNeLXHSnY--
--===============1175881865082314697==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
ffmpeg-devel mailing list
[email protected]
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
[email protected] with subject "unsubscribe".
--===============1175881865082314697==--
There was a problem hiding this comment.
On the FFmpeg mailing list, Soft Works wrote (reply to this):
> -----Original Message-----
> From: ffmpeg-devel <[email protected]> On Behalf Of
> Michael Niedermayer
> Sent: Thursday, October 27, 2022 7:54 PM
> To: FFmpeg development discussions and patches <ffmpeg-
> [email protected]>
> Subject: Re: [FFmpeg-devel] [PATCH v9 23/25] avcodec/subtitles:
> Migrate subtitle encoders to frame-based API
>
> On Tue, Oct 25, 2022 at 09:13:44AM +0000, softworkz wrote:
> > From: softworkz <[email protected]>
> >
> > and provide a compatibility shim for the legacy api
> >
> > Signed-off-by: softworkz <[email protected]>
> > ---
> > libavcodec/assenc.c | 189 ++++++++++++++++++++++++++++++--
> ----
> > libavcodec/avcodec.h | 5 +-
> > libavcodec/codec_internal.h | 12 ---
> > libavcodec/dvbsubenc.c | 96 ++++++++++--------
> > libavcodec/dvdsubenc.c | 103 ++++++++++++--------
> > libavcodec/encode.c | 61 +++++++++++-
> > libavcodec/movtextenc.c | 114 ++++++++++++++++------
> > libavcodec/srtenc.c | 108 ++++++++++++++-------
> > libavcodec/tests/avcodec.c | 5 +-
> > libavcodec/ttmlenc.c | 101 ++++++++++++++-----
> > libavcodec/utils.c | 1 -
> > libavcodec/webvttenc.c | 86 +++++++++++-----
> > libavcodec/xsubenc.c | 88 ++++++++++-------
> > 13 files changed, 689 insertions(+), 280 deletions(-)
>
> Causes this testcase to fail:
> ./ffmpeg -i 'bgc.sub.dub.ogm' -vframes 3 -bitexact -y nosubs.webm
>
> https://samples.ffmpeg.org/ogg/
>
> I did not investgate why or if this a bug or expected. Just reporting
> a difference
> ive seen
Hi Michael,
thanks a lot for testing my patchset!
I have run the command with and without my patchset and I can confirm
that the output is different.
Though, from analyzing the output files, it appears that the output
with my patchset applied seems "more correct" than the output that ffmpeg
is currently creating.
The details of the investigation can be found here:
https://github.com/softworkz/SubtitleFilteringDemos/issues/2
Thanks again,
softworkz
_______________________________________________
ffmpeg-devel mailing list
[email protected]
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
[email protected] with subject "unsubscribe".
|
User |
|
On the FFmpeg mailing list, Soft Works wrote (reply to this): |
|
Please merge this |
I can't. You need to write to the ffmpeg-devel mailing list that you want it: https://lists.ffmpeg.org/mailman/listinfo/ffmpeg-devel/ |
|
Right I'm sorry I thought because I saw a bot here that it was just mirroring all of my comments to that mailing list. I will email |
Yea, this works for the other direction - from ML to here, but not from here to the ML. |
|
positions are preserved. |
This was referenced Oct 30, 2023
|
hi, how can I fix this error |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Subtitle Filtering 2022
This is a substantial update to the earlier subtitle filtering patch series.
A primary goal has been to address others' concerns as much as possible on one side and to provide more clarity and control over the way things are working. Clarity is is specifically important to allow for a better understanding of the need for a subtitle start pts value that can be different from the frame's pts value. This is done by refactoring the subtitle timing fields in AVFrame, adding a frame field to indicate repeated subtitle frames, and finally the full removal of the heartbeat functionality, replaced by a new 'subfeed' filter that provides different modes for arbitrating subtitle frames in a filter graph. Finally, each subtitle filter's documentation has been amended by a section describing the filter's timeline behavior (in v3 update).
Subtitle Filtering Demos
I published a demonstration of subtitle filtering capabilities with OCR, text and bitmap subtitle manipulation involved:
Demo 1: Text-Manipulation with Bitmap Subtitles
v9
v8
v7
v6 - Fix assertion errors
v5 - Conversion to Graphic Subtitles, and other enhancements
This filter closes the last open "gap" in subtitle processing.
v4 - Quality Improvements
v3 - Rebase
due to merge conflicts - apologies.
Changes in v2
Changes from previous version v24:
AVFrame
The start time is now added to the subtitle start_pts during decoding
The sub_end_time field is adjusted accordingly
which it is effectively after removing the start_time
Contains subtitle_pts renamed to 'subtitle_timing.start_pts'
and 'subtitle_timing.duration'
provides a clear indication whether a subtitle frame is an actual
subtitle event or a repeated subtitle frame in a filter graph
Heartbeat Removal
command lines
New 'subfeed' Filter
delay input frames with unknown duration and infer duration from start of subsequent frame
Queues input frames
Outputs frames at a fixed (configurable) rate
Either sends a matching input frame (repeatedly) or empty frames otherwise
similar to repeat mode, but splits input frames by duration into small segments with same content
No fixed output rate
Useful in combination with duration fixup or overlap fixup
ffmpeg Tool Changes
This is needed for example when a format header depends on having received an initial frame to derive certain header values from
(to ensure correct scaling)
Subtitle Encoding
based on repeat_sub field in AVFrame
Subtitle OCR can create multiple areas at different positions. Previously, the texts were always squashed into a single area ('subtitle rect'), which was not ideal.
Multiple text areas are now generally supported:
Changed to use the 'receive_packet' encoding API
A single frame with multiple text areas will create multiple packets now
A newline is inserted between the text from multiple areas
graphicsub2text (OCR)
Other Filter Changes
Plus a dozen of things I forgot..
cc: Hendrik Leppkes [email protected]
cc: Soft Works [email protected]
cc: Michael Niedermayer [email protected]