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?
> 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. It looks like it should require a minor version bump.
> 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.
Code seems to be OK and straightforward, I believe.
- Derek
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
