[gst-devel] nogotiating h264 packing formats

[Wim Taymans]

On Tue, 2008-12-02 at 16:10 +0200, Stefan Kost wrote:
> Wim Taymans schrieb:
> > 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.
> >
> > You would likely build your element to handle both cases. See
> > rtph264pay/depay to see how this works.
> >
> > Wim
> >   
> Its quite clear for playback. I am concerned with the other way around.
> h264pay has "scan-mode" property, but right now only seems to implement
> startcode based packing. So how does h264pay tell the decoder to not
> send a length-prefixed stream, but a startedcode delimmited one?

It can't do that right now, I guess explicitly adding a property for
that would be the only solution then. We still have to try to make the
decoders use the codec_data property to detect AVC or bytestream formats
for backwards compatibility.

Wim

> 
> Stefan
> >   
> >> Stefan
> >>
> >>
> >>
> >>
> >> -------------------------------------------------------------------------
> >> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> >> Build the coolest Linux based applications with Moblin SDK & win great prizes
> >> Grand prize is a trip for two to an Open Source event anywhere in the world
> >> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> >> _______________________________________________
> >> gstreamer-devel mailing list
> >> gstreamer-devel at lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
> >>     
> >
> >
> > -------------------------------------------------------------------------
> > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> > Build the coolest Linux based applications with Moblin SDK & win great prizes
> > Grand prize is a trip for two to an Open Source event anywhere in the world
> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > _______________________________________________
> > gstreamer-devel mailing list
> > gstreamer-devel at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
> >   
> 
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel