[gst-devel] nogotiating h264 packing formats
Sebastian Dröge
sebastian.droege at collabora.co.uk
Mon Dec 22 11:06:23 CET 2008
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? :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20081222/07ba6396/attachment.pgp>
More information about the gstreamer-devel
mailing list