Re: [gst-devel] nogotiating h264 packing formats

[Sebastian D. <seb...@co...>]

Am Dienstag, den 02.12.2008, 10:07 +0100 schrieb Wim Taymans:
> On Tue, 2008-12-02 at 10:06 +0200, Stefan Kost wrote:
> > hi,
> > 
> > h264 streams come in two flavours:
> > 1) length prefixed, each NALU is prefixed by a 32bit length field
> > (length of NALU)
> > 2) startcode delimmited, as described in annex b of h264 spec, NALUs are
> > separated by 24 bit value 0x000001.
> > 
> > It looks like MP4/3GP/MOV and MKV use the AVC1 encoding
> > (length-prefix),while AVI, ES, and TS use
> > the Annex B encoding (startcodes).
> > 
> > When demuxing videos that contain h264 streams, demuxer will just demux
> > what the file contains. decoders can check the presence of the
> > codec-data on the caps. If codec-data is given, stream is length
> > prefixed (1), otherwise its startedcode delimmited (where the SPS and
> > PPS are in the stream an not in codec-data).
> > 
> > When muxing we have no mean to negotiate that right now. The x264enc
> > encoder has a byte-stream property to select the flavor, but that
> > requires manual setup to have it right. Doing t wrong usualy still
> > works, but then the file is not well playable.
> > 
> > Should we add h264packing={length-prefixed,startcode-delimmited} to the
> > caps?
> 
> codec_data on the caps currently signals the AVC1 encoding because you
> need to parse the codec data to get the size of the length prefix.
> 
> The absense of codec_data signals an annex B stream.

Just curious but where is the format of the codec_data defined? Is it
somewhere in ISO/IEC 14496-10? :)