[FFmpeg-devel] [PATCH 24/35] fftools/ffmpeg: use the sync queues to handle -frames

[Andreas Rheinhardt]

Anton Khirnov:
> Quoting Andreas Rheinhardt (2022-06-16 22:33:46)
>> Anton Khirnov:
>>> Same issues apply to it as to -shortest.
>>>
>>> Changes the results of the following tests:
>>> - matroska-flac-extradata-update
>>>   The test reencodes two input FLAC streams into three output FLAC
>>>   streams. The last output stream is limited to 8 frames. The current
>>>   code results in the first two output streams having 12 frames, after
>>>   this commit all three streams have 8 frames and are the same length.
>>>   This new result is better, since it is predictable.
>>
>> The point of the test was that only one stream is limited so that one
>> can see the extradata update directly in the test result: The unlimited
>> streams have a different extradata than the limited stream (because said
>> extradata contains an md5 of the decoded data). So it is expected that
>> the extradata hashes of the first two streams coincide and differ from
>> the hash of the last stream.
> 
> Right, but my point is that the amount of data that ends up in those
> unlimited streams is largely an accident of how the code happens to
> work currently and is not guaranteed by anything.
> 

The documentation of frames reads:
"-frames[:stream_specifier] framecount (output,per-stream)
    Stop writing to the stream after framecount frames."
It does not say that the other streams end after one stream has reached
its framecount. So it is guaranteed by the documentation that the other
streams don't end prematurely.
(Why do you think that this is an accident?)

> Are you suggesting any specific changes to the test or the patch? E.g.
> the atrim filter could be used to replicate previous behaviour if you'd
> like to keep it.
> 
>> (The current test results btw show an imperfection: The extradata of the
>> last stream is not updated, as the encoder is not flushed (or the flush
>> packet does not arrive at the muxer). Fixing this (as seems to be the
>> case) is good.)
> 
> Correct - frame-limiting is now done before sending frames to the
> encoder, so all packets, including the one from flushing the encoder,
> get to the muxer.
>