[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

--- Comment #12 from Mark Nauwelaerts <manauw at skynet.be> 2010-01-15 20:12:05 UTC ---
(In reply to comment #9)
> (In reply to comment #5)
> > It turns out that while previous commits bring more clarity, it leaves some
> > cases open.  Specifically, while avc sample spec in fact requires each
> > 'chunk'/buffer to be a complete AU (and does not make much sense if it is not),
> > byte-stream (annex b) does not care at all.
> > 
> > So, 'avc-sample' specifies everything (in particular, also the current
> > h264parse properties properties to make it so).  'byte-stream', on the other
> > hand, still leaves open whether it is NALU-aligned, AU-aligned or not aligned
> > at all
> 
> AFAICR the standard specifies that the decoder must always work with NALUs. So
> the only options are NALU-aligned, or AU-aligned.

These are likely indeed the only ones that a decoder likes.  However, it is
unlikely that either of these will happen to be in a stream of filesrc buffers
taken from some raw h264 file, and that needs to have caps as well, not only
the options that decoders would appreciate.

> 
> All decoders that I've seen work on full access-units, however, for efficient
> transmissions over the network, a slice support would be nice. In such cases
> the decoder would not be receiving full access-units.
> See: http://bul.ece.ubc.ca/VideoOverWLAN_Presentation_v1wbk.pdf
> 
> So I would say a boolean "slice-mode" would make sense. Most decoders would be
> slice-mode=false though, but if a depayloader can negotiate slice-mode=true,
> then it can work it's magic to make better use of the network. Of course this
> would require some way to set the actual slice size, not sure if that should go
> in the caps or a property.

In view of the above, other comments and some consistency with e.g. AAC case,
it might then make sense to let 'framed' assume more values than just 'true' or
'false',  e.g. 'nalu', 'au' and 'false'/'none' whatever.  Arguably, 'nalu' or
'false' would not be "very legal" in 'avc[-whatever]' mode, but neither is
parsed=false really legal for 'raw' AAC.

W.r.t. 'slice' note that not all NALUs represent a slice, which may as such
introduce some confusion.

-- 
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.