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. Devin _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
