On Mon, 29 Dec 2014, Derek Buitenhuis wrote:
On 12/29/2014 5:22 PM, Martin Storsjö wrote:
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.
Well that sucks. I'm surprised we don't leave this up to the caller to
fill in (via find_stream_info or something), but that's probably treading
into Lovecraftian territory.
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.
OK.
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.
Is there any place to document it? It isn't exactly possible to have super
verbose avoption descriptions, and many of the movflags seem to be quite
confusing (their interactions and stuff) when writing downstream code.
Good question. Much of the muxer option documentation in the normal
documentation is aimed at the end-user of e.g. avconv, while many of these
options only make sense to set via code at different points during the
lifetime of the muxer. I guess some of it could be squeezed into the same
place but with notices that it doesn't make sense to use from normal code.
FWIW, if you're writing a fragmented mp4 file using avconv, you can use
this flag without any problems; the output stream looks just as it did
before (except better, with fields filled in better), only that some parts
of it are written later than it used to.
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
