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

[Luqman]

Hi John,
> John Cox wanted us to know:

>My guess as to why those have NALUs have extra zeros is that it allows
>the decoder to find the start of the unit even if the bitstream is
>presented without knowledge of byte-alignment.

Byte alignment sounds reasonable but I think these zeros belong to the
following NALU....
>
>It is always legal to pack the end of a nal_unit with extra zeros
>(trailing_zero_8bits) so a non-start-of-AU NALU may appear to have
>three
>leading seros but in fact that is one zero on the end of the previous
>unit and two leading zeros on this unit.  This detail is important if
>you are trying to determine the exact byte on which a unit starts (e.g.
>when encapsulated in PES the PTS applies to the first unit which starts
>in that PES packet).

This is part of Byte stream NAL unit syntax in the standard:
...
while( more_data_in_byte_stream( ) &&
	next_bits( 24 ) !=3D 0x000001 &&
	next_bits( 32 ) !=3D 0x00000001 )
trailing_zero_8bits /* equal to 0x00 */
Well, it means 4 bytes (0x00000001) at the border of an NALU are considered 
to be start_code_prefix and NOT trailing_zero_8bits.  If there are more than 
3 zero bytes in the end ONLY then are these preceeding zero bytes part of the 
last NALU, i.e. are trailing_zero_8bits.
Example:
0x00000001...............0x00000001...............0x00 0x00000001
In this case second NALU has trailing_zero_8bits whereas first NALU hasn't.
At least this is my understanding and that is how I dropped NALU with my program. 
Can anybody confirm or refute that?
Regards,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: Digital signature
Url : /pipermail/mp4-tech/attachments/20061021/c6a2d630/attachment.bin