[Mp4-tech] RE: [H.264] NALU semantics questions

[Gary Sullivan]

Jing Hu et al,
If you read the standard closely (Annex B) you will find that the first NAL unit of each "access unit" (i.e., each picture) is required to start with 0x00 00 00 01.  The others can take the shorter (3-byte) prefix pattern.  In all cases, more bytes equal to zero are allowed to be present before that pattern.
NAL units (and the RBSPs that they contain) are required to be byte aligned.
In some system environments (such as H.320) it is possible for the system to lose track of the byte alignment.  Other systems (e.g. MPEG-2/H.222.0) that carry the data inherently as a sequence of bytes cannot lost track.  The design is constructed so that a decoder can get back on track when byte alignment has been lost.  Finding the four-byte prefix is part of that recovery process.
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: Thursday, May 29, 2024 3:41 PM
To: mp4-tech lists.mpegif.org
Subject: [Mp4-tech] [H.264] NALU semantics questions
Dear experts,
I have a couple of questions regarding H.264 NALU semantics and I would really appreciate to get some answers from you.
1) The standard specifies the NALU start_code_prefix as 0x00 00 01, but a lot of applications I see require a start_code_prefix of 0x 00 00 00 01. Are these applications wrong?
2) Is an NALU allowed to be non-byte-aligned in the middle, i.e., can an application read bits from an NALU and therefore the RBSP formed by the application is bit shifted from the RBSP of the original NALU?
Thanks very much!
Jing
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20080529/9b197ec8/attachment.html