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

Michael Niedermayer michael at niedermayer.cc
Sat Sep 9 18:41:19 EEST 2017

On Thu, Sep 07, 2017 at 04:17:24PM -0300, James Almer wrote:
> There's no need to wait for the first packet of every stream now that
> every bitstream filter behaves as intended.
> Signed-off-by: James Almer <jamrial at gmail.com>
> ---
> What should we do with the AVFMT_FLAG_AUTO_BSF flag? Do we deprecate
> it and force the automatic insertion of muxer-required bitstream
> filters now that the generic muxing code will always behave the same,
> or keep it to give the user a choice to apply said bitstream filters?
> I ask because some filters, like vp9_superframe, are necessary to
> avoid creating broken files, so it's not wise to allow the user to
> disable it.
> It would also go in line with AVCodec.bsfs, which is essentially a
> non-optional (for reasons made obvious in fa1749dd34) autobsf at the
> codec level instead of container level.

> The change to fate-rgb24-mkv is a regression that can be prevented by
> committing https://ffmpeg.org/pipermail/ffmpeg-devel/2017-May/211311.html
> or a similar solution, maybe using avformat_init_output(), to make sure
> ffmpeg.c sets AVCodecParameters->field_order for the output stream before
> calling avformat_write_header().

i do see differences in other mkv output, i assume these are also from

one example
./ffmpeg -copyts -ss 11 -i ~/tickets/2263/2263-slow-ss.mkv -vframes 3 moon.mkv

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20170909/566824a7/attachment.sig>

More information about the ffmpeg-devel mailing list