GNOME Bugzilla – Bug 747850
h264parser/h264parse: Handle trailing 0s in NALU
Last modified: 2018-11-03 13:34:18 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.
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.
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.
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.
-- 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.