Message ID | DM8P223MB03650A5791C36AF9040F74C3BA749@DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM |
---|---|
Headers | show |
Series | Subtitle Filtering | expand |
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 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> [...]
> -----Original Message----- > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Michael > Niedermayer > Sent: Tuesday, December 14, 2021 11:06 PM > To: FFmpeg development discussions and patches <ffmpeg-devel@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