[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 #9 from Felipe Contreras <felipe.contreras at gmail.com> 2010-01-15 13:06:54 UTC ---
(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.

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.

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