[FFmpeg-devel] [PATCH 2/3] lavf/srtdec: Permit streaming input

Tomas Härdin git at haerdin.se
Sat Mar 30 10:31:12 EET 2024


lör 2024-03-30 klockan 00:35 +0100 skrev Michael Niedermayer:
> breaks fate here:
> 
> --- ./tests/ref/fate/sub-srt-madness-timeshift  2024-03-29
> 20:43:34.617419731 +0100
> +++ tests/data/fate/sub-srt-madness-timeshift   2024-03-30

Sorry but this file is utter crap and shouldn't be part of FATE. Look
at this:

> 53
> 00:00:01,111 --> 00:00:02,222
> okay, let's make things easy
> 
> 21 lol jk
> 00:00:03,333 --> 00:00:04,444
> hello
> 5
> 
> 
> don't forget me.
> 3
> 
> 
> 00:00:05,555 --> 00:00:06,666
> 
> 
> no.
> let's add some fun
> 44 yes we can
> 00:00:07,777 --> 00:00:06,666
> let's do it in reverse bc wtf not
> 

This file is crafted to test srtdec as it is, rather than following
what passes for an SRT spec (that doom9 forum post[1] and the videolan
wiki[2]). We should remove it, or keep it as a sample that should fail
parsing.

More interesting is fate-sub-srt-badsyntax. Despite the name it doesn't
really have bad syntax, but its cues are in a random order. I guess it
exists to test the cue sorting logic. But should subtitle demuxers
really sort subtitles in this way? We don't do that for other formats
that can have non-decreasing timestamps. For comparison, the WebVTT
spec explicitly disallows decreasing timestamps. I also wonder how this
file was created. My guess is "via a text editor" since it seems to
consist of bits from different SRT files. There's little reason to
support such deliberately broken files, at least having a bunch of
sorting logic just for it. There's no reason we couldn't output packets
in stored order.

The rest of the subtitle test cases pass.

/Tomas

[1] https://forum.doom9.org/showthread.php?p=470941#post470941
[2] https://wiki.videolan.org/SubRip/


More information about the ffmpeg-devel mailing list