[Bug 732167] h264parse: default to byte-stream/nalu format (Annex B)

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=732167

Nicolas Dufresne (stormer) <nicolas.dufresne at collabora.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nicolas.dufresne at collabora.
                   |                            |co.uk

--- Comment #23 from Nicolas Dufresne (stormer) <nicolas.dufresne at collabora.co.uk> ---
(In reply to Sebastian Dröge (slomo) from comment #9)
> Ack, alignment=nal should be one NALU per buffer. Otherwise we could as well
> call it alignment=random :)

Just a side note, when we say "align on 4 bytes" we don't mean to allocate 4
bytes per buffer, but that the start of a buffer is a multiple of 4 (and
sometimes it also means the size of the buffer is a multiple of 4, just so the
next buffer can be aligned without padding). The use of the term alignment here
could have easily mean "nal" for one of more NALU (with start code), "au" for
one or more frame with start code. Though, considering how our decoder work,
there is a need to define the packetization. It seems we did that happen by
making alignment AU and avc being a single frame (which is not longer just an
alignement). It's a bit counter intuitive.

So with the enclose patch, will h264parse default to create one GstBuffer per
nal ? I would believe this would reduce throughput of simple pipeline like
h264parse ! filesink no ? Also, it leaves tsdemux with no model to implement
the optimal path for tsdemux ! filesink.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.