[Mp4-tech] RE: question about MPEG-4 part 2 stuffing bit

[Gary Sullivan]

Jing Hu et al,
Yes, the extra byte needs to be there even if the current position in the bitstream is byte aligned, except when short_video_header is equal to 1.  See, for example, the spec definitions of next_start_code() and next_resync_marker() and Table 6-2, which shows bit pattern stuffing lengths ranging from 1 to 8 bits (otherwise the bit stuffing pattern lengths would range from 0 to 7 bits rather than 1 to 8 bits).
Below is one possible reason why the extra data may be there.
The presence of the extra data can enable a decoder to determine exactly where the actual payload bitstream data ends within the string of received bytes between two start codes (or resync markers).
The MPEG-4 part 2 design does not allow extra zero-valued bytes to be inserted after the end of the last byte the alignment stuffing bits and prior to the next start code.  So a decoder can scan the bitstream for start codes and determine the boundary of the payload bitstream data bits by searching backwards from the next start code to find the last zero-valued bit.  Any data that precedes that bit is part of the payload (and any data after it is the alignment stuffing).  If there were some conditions that allowed the byte-alignment stuffing bits to not be present, that method of finding the payload data would not work.  There might be no way to determine which bits are the payload and which are just "stuffing" to achieve byte alignment.
Note, however, that "short header" mode operation (when short_video_header is equal to 1) is different.  It was designed for compatibility with H.263.
Older designs such as MPEG-1, MPEG-2, H.261, and H.263 work differently.  I believe they stuff only 0-7 bits, and use bits that all have the same value for the alignment stuffing.
In Part 10, which was designed later, some similar concepts are applied, but in a somewhat more sophisticated way that allows an arbitrary number of extra zero-valued bits to be inserted prior to the next start code and also allows a decoder to recover from a loss of byte alignment (for scenarios like H.320 usage where byte alignment is not always preserved at the system level) and allows carriage of arbitrary strings of data payload bits that may include start code patterns within the payload without causing start code emulation in the "encapsulated" bitstream.
Best Regards,
Gary Sullivan
________________________________
From: mp4-tech-bounces lists.mpegif.org [mailto:mp4-tech-bounces lists.mpegif.org] On Behalf Of Jing Hu (jinghu)
Sent: Monday, April 07, 2024 11:18 AM
To: mp4-tech lists.mpegif.org
Subject: [Mp4-tech] question about MPEG-4 part 2 stuffing bit
Hi,
I was wondering whether anybody can clear this out as the relevant text in the standard is a bit ambiguous.
At the end of a vop, if the bit stream is already byte-aligned, does a stuffing byte (0x7F) still need to be inserted into the bit stream. In the MoMuSys reference codes, the stuffing byte is inserted. But I also see a comment by the codes saying "this is for implementing VM 5.1 stuffing mode".
Thanks a lot!
Jing
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20080407/e938daf0/attachment.html