[gstreamer-bugs] [Bug 606662] h264: add stream-format to output caps

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=606662
  GStreamer | gst-plugins-ugly | git

Wim Taymans <wim.taymans> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wim.taymans at gmail.com

--- Comment #22 from Wim Taymans <wim.taymans at gmail.com> 2010-01-25 15:40:58 UTC ---
Regardless of what is currently done where and if it's right or wrong is rather
irrelevant. What we want here is to describe the various ways H264 streams can
be formatted and put into buffers.

At the lowest level there are NAL units which may be separated from eachother
with:

 - start codes (annex B). start codec between NAL units must be found to know
       the length of the NAL unit.
 - length prefix (AVC). each NAL unit is prefixed with the length. The size of
       this length prefix is transmitted in an 'AVC Decoder Configuration
       Record' that we pass along in codec_data in the caps.

Currently we implicitely assume AVC mode when we see a codec_data in the caps.
AVC mode is easier to parse as you don't need to look for start codes. The
codec_data is however more difficult to handle.

Decoders may or may not work at the NAL unit level. Usually decoders work at
the AU (Access Unit) level, which is a collection of NALs that make up a
complete frame. If the decoder doesn't handle NALs directly, a parser needs to
be inserted to group NALs into AUs for the decoder.

The typical cases that we have to deal with are these:

 - reading bytesteam H264 from a file, no NAL or AU grouping is done. NALs are
   separated by startcodes
 - mpegtsdemux/mpegpsdemux: bytestream format, essentially like a raw file no
   AU or NAL grouping is done.
 - qtdemux: AVC format, NALs are grouped into AU

IMO we need at least 6 reasonable possibilities:

 - avc-raw: ungrouped length prefixed NALs (not a good idea as resync after a
             lost packet is not possible).
 - avc-nal: a GstBuffer contains one or more complete length prefixed NALs (a
             depayloader could natuarally do this)
 - avc-au:  a GstBuffer contains one complete AU (qtdemux, ...)
 - bytestream-raw: a buffer contains ungrouped startcode separated (incomplete)
             NALs (like from a filesrc, mpegtsdemux, ...)
 - bytestream-nal: startcoded prefixed complete NALs (a depayloader could
             naturally do this)
 - bytestream-au: one startcode prefixed complete AU

So what about:

 format = (string enum) "byte-stream", "avc"
 alignment = (string enum) "none", "nal", "au"

There is no point to have a 'parsed' option (if needed for backward compat, we
can set this to TRUE). Tim tells me that we currently don't use parsed for
h264, even.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.