On Wed, 21 Mar 2018, Devin Heitmueller wrote:
Hi James,
No, this is done after that, while processing a packet.
It is also making changes to the output codecpar after write_header()
was called, which is wrong.
libavformat used to delay writing the header until you feed it the first
packet, an internal functionality this code here abused.
As you’re using the term “abused”, I assume you’re suggesting that it was
intentionally changed to no longer wait until the first packet was received, as
opposed to this being a bug in libavformat.
If that’s the case, then indeed we would have to delay enabling the output
until the first packet and try to figure out how badly that screws up the
decklink’s pre-roll functionality for both audio and video.
I still think ffmpeg.c should be fixed instead. There is even some
logic in ffmpeg.c to wait for a frame from all streams before
writing the header, so it seems doable.
Also as far as I see you cannot detect the field order in the muxer if
it is using a real codec (like v210) instead of a wrapped avframe.
Regards,
Marton
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
