[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