After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 747850 - h264parser/h264parse: Handle trailing 0s in NALU
h264parser/h264parse: Handle trailing 0s in NALU
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
unspecified
Other All
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-04-14 13:52 UTC by Edward Hervey
Modified: 2018-11-03 13:34 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
codecparsers/h264: Add a NALU field specifying size with trailing 0s (3.89 KB, patch)
2015-04-14 13:52 UTC, Edward Hervey
none Details | Review
h264parse: Use full NALU size to know what to skip/flush (3.27 KB, patch)
2015-04-14 13:52 UTC, Edward Hervey
none Details | Review
Updating patch removing the trailing 0 when there is no transformation (4.35 KB, patch)
2015-04-30 09:02 UTC, Nicolas Huet
none Details | Review

Description Edward Hervey 2015-04-14 13:52:39 UTC
the H264 spec allows to have leading/traling zeros in byte stream

The problem is that we don't know about it, and therefore we iterating over
NALU we are never guaranteed to end at the next NALU start code, but instead
on potentially trailing zero bytes

This would cause h264parse to tell baseparse to skip those few bytes, resulting
in the next buffer being a DISCONT one ... whereas it's not.
Comment 1 Edward Hervey 2015-04-14 13:52:44 UTC
Created attachment 301547 [details] [review]
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.
Comment 2 Edward Hervey 2015-04-14 13:52:50 UTC
Created attachment 301548 [details] [review]
h264parse: Use full NALU size to know what to skip/flush

There might be trailing zeros in NALU which we need to properly handle
in order to know where the next NALU really is (i.e. we will end up on
a start code for the next NALU).

This avoids constantly skipping a few bytes here and there, resulting
in baseparse giving us DISCONT buffers.
Comment 3 Nicolas Huet 2015-04-30 09:02:02 UTC
Created attachment 302631 [details] [review]
Updating patch removing the trailing 0 when there is no transformation

Discont is a regression introduced by https://bugzilla.gnome.org/show_bug.cgi?id=721384

Your patch keep the trailling 0 at the end of the NAL when there is no "transformation" of the data: NAL to NAL for example.
It would reintroduce the spec issue (the last byte of a NAL shall not be 0x00/Thiago Sousa Santos). 

Removing bytes means we need to modify the input buffer. I modified your patch to push the NAL units without the trailing 0 in "frame_out" adapter when there is no transformation.
Comment 4 GStreamer system administrator 2018-11-03 13:34:18 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/240.