GNOME Bugzilla – Bug 764372
h264parse removes padding from byte streams
Last modified: 2018-11-03 13:48:21 UTC
When using h264parse element without a conversion (bytestream to bytestream), it removes padding bytes from the original h264 stream. Producing a real constant bitrate is then not possible anymore. This can be reproduced with the following command line (you need 10Bit libx264): # gst-launch-1.0 videotestsrc ! video/x-raw,width=1920,height=1080,format=I422_10LE,framerate=25/1 ! x264enc trellis=false option-string=avcintra-class=100 ! video/x-h264,stream-format=byte-stream ! h264parse ! mpegtsmux ! filesink location=test.ts Every frame should then have exactly 568832 bytes. But checking the file test.ts with ffprobe gives different frame sizes for every frame. The frames sizes can be checked with: # ffprobe -show_frames test.ts | grep pkt_size Removing the "h264parse" element from the above pipeline and checking the frame sizes gives the expected size of 568832 bytes for every frame.
Like all other parsers, it shouldn't drop any padding or other information by default. There's going to be a reason why it exists.
https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/gst-libs/gst/codecparsers/gsth264parser.c#n1366 The problem is this, which drops all the padding from the NALUs. Commenting out that code gives almost the correct size (it produces a bit more for some reason).
Which was added in https://bugzilla.gnome.org/show_bug.cgi?id=721384 as the spec does not allow trailing zeroes.
In combination I would say that there are incompatible requirements here. AVC Intra (the official one) is all good probably, the Panasonic one we're talking about here seems incompatible with the H264 spec. The Panasonic one requires each frame to be padded with zeroes after the end of the last NALU so that all frames have the same size. H264 forbids a NAL to end with a 0x00 byte (which the padding would do). But it allows 0x00 bytes before the next start code. So we could probably move the padding to the beginning of the next frame, but that again defeats the whole purpose of the padding to make each frame the same size. For AVC stream format this is even worse as the only way to have the padding there would be to make it part of the current frame (i.e. padding at the end of the frame, not valid h264)... as otherwise for the next frame it wouldn't directly start with a NALU after the AVC header and nothing can handle that. Not sure what to do about this here. I guess one could write another element for redoing the padding or having it done in muxers as needed.
I integrated once a Panasonic HW codec, I don't remember having to add padding to make it work. I wonder if this "format" is relevant, if it isn't something from a very old pass ?
See https://en.wikipedia.org/wiki/AVC-Intra "AVC-Intra is compliant with the H.264/MPEG-4 AVC standard[2] and Panasonic claims to follow the SMPTE RP 2027–2007[3] recommended practice specification.[4] Analysis by the x264 project has shown that Panasonic does not comply with this specification[5]" The encoder is already adding the padding, the problem is that h264parse is going to remove the padding :)
(In reply to Sebastian Dröge (slomo) from comment #6) > The encoder is already adding the padding, the problem is that h264parse is > going to remove the padding :) I see, thanks for explaining.
Since this doesn't respect the standard, what we need is a new variant for those panasonic modes so we can workaround the issues properly.
-- 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/364.