View Full Version : Emulation Prevention Question
videophool
26th September 2012, 20:57
Is it legal for a slice NALU to end with the bytes '00 00 03'? Our parser is choking on a stream because it is treating this as emulation prevention, and puts the next byte (the first 0 for the next NALU start code) with the current slice NALU. The NALU bytes are below. The last 4 bytes '00 00 00 01' is the start code for the next NALU. Also included the SPS and PPS.
00 00 00 01 65 88 80 00 40 01 96 ff fc 44 bc 0a
3b c4 c8 04 ec fd b8 d5 63 ff 9d 45 b4 80 00 00
03 00 00 03 00 00 03 00 08 d6 03 61 52 00 00 03
00 8d 80 01 3d 00 03 28 00 0b f0 00 3a c0 01 a7
00 00 03 00 00 03 00 00 03 00 00 03 00 00 03 00
00 03 00 00 03 00 00 03 00 00 03 00 00 03 00 00
03 00 00 03 00 00 03 00 00 03 00 00 03 00 00 03
00 00 03 00 00 03 00 00 03 00 00 03 00 00 03 00
00 03 00 00 03 00 00 03 00 00 03 00 00 03 00 00
03 00 00 03 00 00 03 00 00 03 00 00 03 00 00 03
00 00 03 00 00 03 00 00 00 01
00 00 00 01 67 80 00 1f ac 1b 29 00 50 05 bb 01
10 00 00 3e 90 00 0b b8 0e 06 00 03 37 f4 00 04
4a a3 f1 8e 30 30 00 19 bf a0 00 22 55 1f 8c 70
20 00
00 00 00 01 68 eb 73 52
MasterNobody
26th September 2012, 21:16
Why do you think this 0-byte is part of next NALU? It can be normal emulation prevention + "short" start code.
videophool
26th September 2012, 21:32
based on the comment in the spec below, I am guessing that the slice is legal, and that our parser is incorrect.
NOTE – The constraint on the maximum number of bins resulting from decoding the contents of the slice layer NAL units can be
met by inserting a number of cabac_zero_word syntax elements to increase the value of NumBytesInVclNALunits. Each
cabac_zero_word is represented in a NAL unit by the three-byte sequence 0x000003 (as a result of the constraints on NAL unit
contents that result in requiring inclusion of an emulation_prevention_three_byte for each cabac_zero_word).
videophool
26th September 2012, 22:19
Why do you think this 0-byte is part of next NALU? It can be normal emulation prevention + "short" start code.
From the spec: The last byte of the NAL unit shall not be equal to 0x00
Guest
26th September 2012, 23:07
That's an awfully short IDR NALU. Something looks wrong. Can you link us the full stream fragment?
videophool
27th September 2012, 00:10
That's an awfully short IDR NALU. Something looks wrong. Can you link us the full stream fragment?
It is the first frame of the stream and is just a black frame.
Guest
27th September 2012, 00:36
Hard to help without a stream fragment.
videophool
27th September 2012, 16:15
Hard to help without a stream fragment.
Thanks, for the help. I consider this issue resolved. The slice NALU is correct, and my parser logic around the emulation 3-byte prevention logic was not.
videophool
27th September 2012, 22:48
For anyone reading this thread, I will explain my logic error.
When parsing the last bytes of the NALU '00 00 03 00 00 00 01', looking for a start code, my parser saw the EP3B sequence '00 00 03', which was the last 3 bytes of the NALU, and assumed that the next byte was part of the same NALU. Thus it included a '00' with the slice NALU when it was actually part of the start code for the next NALU. This resulted in the last byte of the slice NALU being '00' which is a violation of the AVC spec (no NALU may end with '00').
The situation would have been worse with this sequence: '00 00 03 00 00 01', which would have resulted in the next NALU start being missed altogether.
My takeaway is that the EP3B sequence prevents the 00 00 to the left of the 03 from being part of a start code, but not the 00 to the right. Hope this makes sense.
Guest
27th September 2012, 23:58
Thanks for the analysis! I will check all my parsers to see if they are OK.
vBulletin® v3.8.11, Copyright ©2000-2025, vBulletin Solutions Inc.