[Bug 764372] h264parse removes padding from byte streams

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Sat Apr 2 07:54:04 UTC 2016


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

--- Comment #4 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
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.

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


More information about the gstreamer-bugs mailing list