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

[Michael Niedermayer]

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
field_order

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>