On Wed, 26 Feb 2014, Tim Walker wrote:
On 26 Feb 2014, at 08:47, Martin Storsjö <[email protected]> wrote:
On Wed, 26 Feb 2014, Tim Walker wrote:
ff_avc_parse_nal_units_buf(pkt->data, &data, &size);
…in matroskaenc.c, only when a start code is found in
the extradata (Annex B formatted), but not if the
extradata is e.g. already hvcC-formatted?
Yes, generally you'd assume that the packets use MP4 style nal prefixes instead
of annex b, if the extradata is in avcC/hvcC format (since it's much easier to
determine what format is being used based on extradata, instead of allowing
extradata in one format and packets in another, or even better, different
format in each packet...)
Hmm. It looks like the libavcodec libx264 wrapper provides extradata in
Annex B format - does it also provide packets in Annex B format, or with
MP4-style NAL prefixes (looks like the former, but I'm not sure)?
Yes, it provides packets in Annex B format as well - I don't think I've
ever seen a H264 encoder that outputs in any other format (except for ones
that output raw NALs without any prefix at all).
Perhaps a better question, what issue(s) (if any) would occur if a
caller provided avcC- of hvcC-formatted extradata, but Annex B formatted
packets?
With most of our current muxers, you'd end up with the packets written in
annex B format.
The 2 or 3 most common bitstream format combinations (as far as I've seen)
are with everything in Annex B, with SPS/PPS in extradata, or with SPS/PPS
in-band in the stream, or with SPS/PPS in extradata in avcC format and
packets with MP4 style nal prefixes. Other combinations are kinda unlikely
I think (unless you explicitly want to screw things up).
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
