[FFmpeg-devel] [PATCH 2/3] avformat/mux: stop delaying writing the header

[James Almer]

On 11/27/2017 8:18 PM, Michael Niedermayer wrote:
> On Sun, Nov 26, 2017 at 05:51:03PM -0300, James Almer wrote:
>> Every bitstream filter behaves as intended now, so there's no need to
>> wait for the first packet of every stream.
>>
>> Signed-off-by: James Almer <jamrial at gmail.com>
>> ---
>>  libavformat/avformat.h         |  2 +-
>>  libavformat/internal.h         |  6 -----
>>  libavformat/mux.c              | 52 ++++++++----------------------------------
>>  libavformat/options_table.h    |  2 +-
>>  libavformat/tests/fifo_muxer.c | 52 ------------------------------------------
>>  tests/ref/fate/fifo-muxer-tst  |  1 -
>>  6 files changed, 12 insertions(+), 103 deletions(-)
> 
> Is this intended to change any files ?
> 
> this changes slightly:
> ./ffmpeg -i ~/tickets/2263/2263-slow-ss.mkv -vframes 3 file.mkv
> 
> not saying this is a issue in the patch or anything (i am in favor of
> the simplification in fact), just that i saw this change

I can't access that file, but just in case it's related, this patch is
meant to be applied after the first. Otherwise, as the first patch
states, stream parameters that might be changed by ffmpeg.c while
processing an input frame (specifically field_order) will not be taken
into account during write_header.
You might remember i have sent this patch alone before, and how it
affected matroska files because of differing field_order values,
including fate-rgb24-mkv.

For that matter, ffmpeg.c changing any output codecpar values while
reading an input frame (that is, long after the output file and streams
have been initialized) is a very hacky thing to do. This is something
I'd expect avformat_find_stream_info() to do instead, since it decodes
some frames to get all the info it needs, and not the API user (ffmpeg.c).