On Mon, 29 Dec 2014, Derek Buitenhuis wrote:
On 12/29/2014 2:20 PM, Martin Storsjö wrote:
This delays writing the moov until the first fragment is written,
or can be flushed by the caller explicitly when wanted. If the first
sample in all streams is available at this point, we can write
a proper editlist at this point, allowing streams to start at
something else than dts=0. For AC3 and DNXHD, a packet is
needed in order to write the moov header properly.
Aside/unrelated: Why don't AC3 and DNXHD use the global header flag
with extradata like other codecs?
Probably because it's not extradata per se (e.g. a normal stream of
packets can be decoded just fine without this extra piece of data), just
that the headers in a moov atom contain fields that you can't deduce
without having a sample available.
This isn't added to the normal behaviour for empty_moov, since
the behaviour that ftyp+moov is written during avformat_write_header
would be changed. Callers that split the output stream into header+segments
(either by flushing manually, with the custom_frag flag set, or by
just differentiating between data written during avformat_write_header
and the rest) will need to be adjusted to take this option into use.
Perhaps I am having trouble understanding here. Does this mean callers
already doing this (me) need to update their code? I'm not totally clear
on this.
No, callers using the mov muxer for fragmenting/segmenting won't need to
change their code. If you want to take the extra/better/fancier behaviour
into use, you need to add the new flag - without it, your code will behave
as it did before.
I.e., ideally one might want this to be the default behaviour (since it's
allows doing a lot of things you couldn't do before) but I'm arguing it
can't be made default since it'd break existing setups (and the behaviour
is slightly less obvious), thus, an extra flag.
It looks like it should require a minor version bump.
Good point, will add that.
For handling streams that start at something else than dts=0, an
alternative would be to use different kinds of heuristics for
guessing the start dts (using AVCodecContext delay or has_b_frames
together with the frame rate), but this is not reliable and doesn't
necessarily work well with stream copy, and wouldn't work for getting
the right initialization data for AC3 or DNXHD either.
[...]
+ { "delay_moov", "Delay writing the initial moov (until the first fragment is cut, or
until the first fragment flush)", 0, AV_OPT_TYPE_CONST, {.i64 = FF_MOV_FLAG_DELAY_MOOV}, INT_MIN,
INT_MAX, AV_OPT_FLAG_ENCODING_PARAM, "movflags" },
No need for paren really.
Ok, will change.
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
