From: Paul B Mahol <onemda@gmail.com> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> Subject: Re: [FFmpeg-devel] [PATCH 2/3] lavf/srtdec: Permit streaming input Date: Sat, 30 Mar 2024 12:36:50 +0100 Message-ID: <CAPYw7P4PDx6UBYer5w4AteVN=YdkBbcrW4kvRqDB_TMz0pwi5Q@mail.gmail.com> (raw) In-Reply-To: <87e6b2eaf3c3a2b98b693cbefd2c719403f33a83.camel@haerdin.se> On Sat, Mar 30, 2024 at 9:31 AM Tomas Härdin <git@haerdin.se> wrote: > 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. > I agree, current subtitles not being handled in streamed way is bad practice. If some subtitle have wrong order of items, than new generic subtitle filter could be implemented which would fix that by either using queue or seeking around in subtitle stream. > > /Tomas > > [1] https://forum.doom9.org/showthread.php?p=470941#post470941 > [2] https://wiki.videolan.org/SubRip/ > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
next prev parent reply other threads:[~2024-03-30 11:37 UTC|newest] Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-03-28 22:55 [FFmpeg-devel] [PATCH 1/3] lavf/subtitles: Do not eat \n\n Tomas Härdin 2024-03-28 22:56 ` [FFmpeg-devel] [PATCH 2/3] lavf/srtdec: Permit streaming input Tomas Härdin 2024-03-28 22:57 ` Tomas Härdin 2024-03-29 23:35 ` Michael Niedermayer 2024-03-30 0:03 ` Tomas Härdin 2024-03-30 8:31 ` Tomas Härdin 2024-03-30 11:36 ` Paul B Mahol [this message] 2024-03-30 11:44 ` Nicolas George 2024-03-30 14:44 ` Tomas Härdin 2024-03-30 14:49 ` Nicolas George 2024-03-30 15:23 ` Tomas Härdin 2024-03-30 15:34 ` Nicolas George 2024-03-30 16:02 ` Andreas Rheinhardt 2024-03-30 16:28 ` Tomas Härdin 2024-04-01 13:15 ` arch1t3cht 2024-04-01 14:34 ` Tomas Härdin 2024-03-28 22:57 ` [FFmpeg-devel] [PATCH 1/3] lavf/subtitles: Do not eat \n\n Tomas Härdin 2024-03-28 23:06 ` [FFmpeg-devel] [PATCH 3/3] lavf/subtitles: Unfix ticket #5032 Tomas Härdin 2024-03-29 12:29 ` Tomas Härdin 2024-03-30 0:08 ` [FFmpeg-devel] [PATCH 1/2] lavf/subtitles: Add ff_text_peek_r16(), only accept \r, \n, \r\n and \r\r\n line endings Tomas Härdin
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAPYw7P4PDx6UBYer5w4AteVN=YdkBbcrW4kvRqDB_TMz0pwi5Q@mail.gmail.com' \ --to=onemda@gmail.com \ --cc=ffmpeg-devel@ffmpeg.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel This inbox may be cloned and mirrored by anyone: git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \ ffmpegdev@gitmailbox.com public-inbox-index ffmpegdev Example config snippet for mirrors. AGPL code for this site: git clone https://public-inbox.org/public-inbox.git