[gst-devel] nogotiating h264 packing formats

[Wim Taymans]

On Mon, 2008-12-22 at 11:06 +0100, Sebastian Dröge wrote:
> 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? :)

It's in ISO/IEC 14496-15, section 5.2.4.1.1 defined in the
AVCDecoderConfigurationRecord.

Wim

>