[Bug 747850] h264parser/h264parse: Handle trailing 0s in NALU

[GStreamer (GNOME Bugzilla)]

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

--- Comment #1 from Edward Hervey <bilboed at bilboed.com> ---
Created attachment 301547
  --> https://bugzilla.gnome.org/attachment.cgi?id=301547&action=edit
codecparsers/h264: Add a NALU field specifying size with trailing 0s

In bytestream, h264 NALU can have trailing (or leading) zero bytes.

Previously those trailing bytes was being silently ignored in the
resulting NALU parsing result. While this was not breaking anything
per-se, it would lead to users of the API to only skip by 'size'
bytes when moving to the (supposedly) next NALU start ... but which
would actually not start there.

Astute readers might be wondering why we don't ignore "leading" 0s
instead of trailing ones. The H.264 specification indicates that
leading_zero_8bits should only happen for the first byte stream NALU
of the bitstream and then they should be taken as trailing_zero_8bits.

There is one special case for SPS/PPS/AU which *should* have an extra
zero_byte in front of the start code.

See B.1.1 (Byte stream NAL unit syntax) and B.1.2 (Byte stream NAL unit
semantics) from H.264 specifications for more details.

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