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

[Andreas Rheinhardt]

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