[Mp4-tech] Dropping NAL units on bit errors: Best approach?

[Gary Sullivan]

Oops.  Luqman, actually you had it right.  I thought you were saying
0x00001...........0x000001.............0x00 0x000001
when actually you were saying
0x00000001...........0x00000001.............0x00 0x00000001
All of your strings were at least FOUR bytes long, whereas the start
code prefix in the standard (start_code_prefix_one_3bytes) is only THREE
bytes long.
In the standard, most NAL units only need a three-byte prefix, although
a few (the first NAL unit of an access unit and each SPS and PPS NAL
unit) need a four-byte prefix.
In your actual example, you are correct.  The 0x00 near the end is
assigned to the SECOND NAL unit.
In my preceding example at the beginning of this message, the 0x00 would
be assigned to the THIRD NAL unit.
The rule is that if the prefixing string is three bytes long (0x000001)
or four bytes long (0x00000001) then these three or four bytes will be
assigned to the NEXT byte stream NAL unit.  If the prefixing string is
more than four bytes long, the last four bytes are assigned to the next
byte stream NAL unit and the remainder are assigned to the previous byte
stream NAL unti.
Best Regards,
Gary Sullivan
+> -----Original Message-----
+> From: mp4-tech-bounces lists.mpegif.org 
+> [mailto:mp4-tech-bounces lists.mpegif.org] On Behalf Of Gary Sullivan
+> Sent: Saturday, October 21, 2023 4:35 AM
+> To: Luqman; mp4-tech lists.mpegif.org
+> Subject: RE: [Mp4-tech] Dropping NAL units on bit errors: 
+> Best approach?
+> 
+> 
+> I don't think you have it right.
+> 
+> The boundary between "byte stream NAL units" and "access units" is
+> detailed in the standard (mostly Annex B, which is only two 
+> pages long).
+> We made a small modification of the boundary location in a 
+> corrigendum
+> activity, so make sure you have a relatively recent version 
+> and not some
+> old 2003 draft.  When there are zero-valued bytes between the final
+> payload-bearing bits of one "NAL unit" and the
+> "start_code_prefix_one_3bytes" of the next "byte stream NAL 
+> unit", all
+> but the last one of those zero-valued bytes are considered 
+> part of the
+> preceding "byte stream NAL unit" and the last one is 
+> considered part of
+> the next "byte stream NAL unit".
+> 
+> But please don't take my word for it.  Read the spec closely.
+> 
+> Best Regards,
+> 
+> Gary Sullivan 
+> 
+> +> -----Original Message-----
+> +> From: mp4-tech-bounces lists.mpegif.org 
+> +> [mailto:mp4-tech-bounces lists.mpegif.org] On Behalf Of Luqman
+> +> Sent: Friday, October 20, 2023 3:46 PM
+> +> To: mp4-tech lists.mpegif.org
+> +> Subject: Re: [Mp4-tech] Dropping NAL units on bit errors: 
+> +> Best approach?
+> +> 
+> +> > Gary Sullivan wanted us to know:
+> +> 
+> +> >Yes, it's a byte-alignment recovery trick.  As John points 
+> +> out, extra
+> +> >zero-valued bytes can be present between any pair of NAL 
+> +> units, but at
+> +> >least one such byte is required for the most important 
+> NAL units to
+> +> >enable decoder alignment recovery.  Alignment recovery is 
+> +> important in
+> +> >some scenarios but not others, but the quantity of data 
+> necessary to
+> +> >enable it is so low (about 1-2 bytes per picture) that 
+> we decided to
+> +> >require it to be there all the time.
+> +> 
+> +> Thanks Gary for clarifying this. But there is some confusion 
+> +> where the
+> +> leading zero byte 0x00 before 3 byte start_code_prefix belongs to.
+> +> 
+> +> Example: 
+> +> 
+> +> 0x00000001................0x00000001.................0x00 
+> 0x00000001 
+> +> 
+> +> The extra 0x00 preceeding third 0x00000001 belongs to the 
+> second NALU
+> +> whereas 0x00000001 belongs to the third NALU.
+> +> Similarly in case of second appearance of 0x00000001, 
+> these 4 bytes
+> +> belong to second NALU.
+> +> 
+> +> Am I correct? Or is it only ture in case of SPS, PPS and 
+> +> first NALU of
+> +> an access unit / frame / picture?
+> +> 
+> +> Regards,
+> +> 
+> +> Luqman 
+> +> 
+> +> 
+> +> 
+> 
+> _______________________________________________
+> NOTE: Please use clear subject lines for your posts. Include 
+> [audio, [video], [systems], [general] or another 
+> apppropriate identifier to indicate the type of question you have.
+> 
+> Note: Conduct on the mailing list is subject to the 
+> Antitrust guidelines found at 
+> http://www.mpegif.org/public/documents/vault/mp-out-30042-Ant
+> itrust.php
+>