From: Andreas Rheinhardt <andreas.rheinhardt@outlook.com> To: ffmpeg-devel@ffmpeg.org Subject: Re: [FFmpeg-devel] [PATCH 2/3] lavf/srtdec: Permit streaming input Date: Sat, 30 Mar 2024 17:02:45 +0100 Message-ID: <GV1P250MB0737BC01860AAA755ADDA8DE8F392@GV1P250MB0737.EURP250.PROD.OUTLOOK.COM> (raw) In-Reply-To: <20e0bfb5a1dccf176f187d9925ed2206929be9d8.camel@haerdin.se> Tomas Härdin: > lör 2024-03-30 klockan 15:49 +0100 skrev Nicolas George: >> Tomas Härdin (12024-03-30): >>> Players can implement sorting if they wish. >> >> API break. > > lavf's API provides no guarantees regarding presentation order >> > >>> Finally I will note that sorting does not happen when subtitles are >>> muxed in say mkv or avi, so the behavior is not even consistent >>> across >>> demuxers that support subtitles. >> >> AVI or MKV demuxer do not sort their packets because the packets are >> supposed to be already sorted; > > "Supposed to" is doing a lot of work here. IIRC AVI is fundamentally > incapable of providing out-of-order anything, this is true (B-frames > being notably haram in AVI). It is however capable of providing poorly > muxed files. For example it is perfecectly legal in AVI to mux all > video, then all audio, rather than the typical case where audio and > video are interleaved (the I in AVI). The same goes for many formats. > MOV supports basically any ordering via ctts shenanigans if I'm not > mistaken. > 1. AVI does not have a way to signal pts, but you can simply store stuff with reordering in it (in coding order); you just need something (most likely a decoder) that can properly reorder the frames for presentation. 2. IIRC our AVI demuxer tries to properly interleave the packets returned by AVI even if the input file is non-interleaved; the same goes for mov/mp4 (where the index and not the file position is used). >> ASS demuxer sorts its packets because >> there is no guarantee the text are sorted in the file > > So? I'm making a normative argument. > Normative about what? The ASS specification [1] explicitly says: "SSA does not care what order events are entered in. They could be entered in complete reverse order, and SSA would still play everything correctly in the right order ie. you cannot assume that each dialogue line is in chronological order in the script file." If you force reordering on our users, then this is a breaking change and it would impair the usefulness of libavformat: If users have to implement workaround for issues of certain file formats (for files which are not even broken according to the specification of the format in question!), then what point is there in using libavformat at all? - Andreas [1]: www.tcax.org/docs/ass-specs.htm _______________________________________________ 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 16:02 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 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 [this message] 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=GV1P250MB0737BC01860AAA755ADDA8DE8F392@GV1P250MB0737.EURP250.PROD.OUTLOOK.COM \ --to=andreas.rheinhardt@outlook.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