[FFmpeg-devel] [PATCH v24 00/21] Subtitle Filtering

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of Michael
> Niedermayer
> Sent: Tuesday, December 14, 2021 11:06 PM
> To: FFmpeg development discussions and patches <ffmpeg-devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v24 00/21] Subtitle Filtering
> 
> On Mon, Dec 13, 2021 at 11:40:16PM +0000, Soft Works wrote:
> > New in V24
> >
> > - Fixes bugs as reported by Michal
> > - graphicsub2video: use 1x1 output frame size as long as subtitle size is
> unknown (0x0) and no size is not explicitly set
> > - decode: set subtitle frame size from decoding context
> > - ffmpeg: re-init graph when subtitle size changes
> > - ffmpeg_filter: always insert subscale filter for sub2video compatibility
> > - vf_overlaytextsubs: ensure equal in/out video formats
> >
> > GITHUB Branch: https://github.com/softworkz/FFmpeg/tree/subs_v24_plus
> 
> I didnt immedeatly spot any "hard" failures from this.
> Quite a few cases change output, should i report these ? I didnt see anything
> obviously wrong vissually in any

Thanks again for testing!

I think as long as the results are visually equal, we should be just fine.

We already know that there are several categories which are causing 
binary differences:

- The processing differences
  - sub2video always creates full RGBA frames which may require conversion
    while the new filters can overlay on yuva directly
  - when scaling is required, the new subscale filter scales the 
    individual subtitle rects only to overlay directly or
    draw onto transparent full frames afterwards
- Timing differences 
  - Sometimes like one frame earlier or later
    (as can be seen in the test ref diffs)
  - Different eof behavior
    actually 'more correct' than before
    (see my previous response where the current implementation 
    outputs an erroneous frame at the end with bogus timing)

I've also seen a case once, where a 1-pixel offset exists between 
current and new implementation, but I don't think that this is
actionable without having a case with a clear indication about
which (current or new) is right and which is wrong, and 
whether a "right/wrong" even exist in such cases.
Most likely this is caused by rounding differences that 
occur when scaling individual rects (and their integer positions)
instead of full frames.


So, from my side, we're all good, as long as there are no
visible differences.


> heres a random pick:
> ./ffmpeg -f lavfi -i "movie=tickets/1332/Starship_Troopers.vob[out0+subcc]"
> -vn -map s /tmp/file-eia608.srt
> 
> @@ -6,12 +6,12 @@
>  2
>  00:00:15,249 --> 00:00:18,252
>  <font face="Monospace">{\an7}- TAKE THE NUMBER TWO CHAIR,
> -\h\hIBANEZ.
> +  IBANEZ.
>  - YES, MA’AM.</font>
> 
>  3
>  00:00:22,756 --> 00:00:27,761
> -<font
> face="Monospace">{\an7}\h\h\h\h\h\h\h\h\h\h\h\h\h\h\h\h\h\h\h\hIDENTIFY.
> +<font face="Monospace">{\an7}                    IDENTIFY.
>  IBANEZ, "T"-THREE-TWO-FIVE-"A,"
>  CLEAR.</font>

Yes, this change is intentional and the result of the bugfix in commit

> avutil/ass_split: Add parsing of hard-space tags (\h)
(not on the ML, only on GitHub)

Hard spaces in form of '\h' are specific to the ASS/SSA spec, but current
ffmpeg doesn't parse and convert them.

Those '\h' sequences are invalid in ttml, text and webvtt. For SRT, there's
no clear spec and while I've seen it somewhere declared to be "valid",
it is not supported by all clients, that's why I've changed this to 
emit spaces instead, just like for ttml and text. For webvtt I'm converting
them to  

I think I've fond away how to submit those commits in a way that they
can be applied by patchwork despite the mixed line endings.
Will make another attempt shortly.

Thanks again for testing,
softworkz