[Mp4-tech] H.264: NumBytesInNALUnit andstart-code-emulation-prevention

[D.R.J.Manigandan]

H.264: NumBytesInNALUnit and start-code-emulation-preventionDear Mr.Shankar Moni,
    Please have a look on "emulation_prevention_three_byte" under section
7.4.1 in Prepublished Recommendation (05/2003).
When converting from SODB to RBSP for NAL unit packetization, the following
three-byte sequences are checked
0x000000, 0x000001 and 0x000002 and 0x03 is inserted after 0x0000 to avoid 
emulation of start code. 
With Regards,
D.R.J.Manigandan,
S.Manivel
  ----- Original Message ----- 
  From: Shankar Moni 
  To: mp4-tech lists.mpegif.org 
  Sent: Wednesday, May 05, 2024 5:32 AM
  Subject: [Mp4-tech] H.264: NumBytesInNALUnit andstart-code-emulation-prevention
  This is a question on NumBytesInNALUnit and start-code-emulation-prevention. 
  The written spec (JVT-J050.doc) expects an argument (NumBytesInNALUnit) to be provided to the byte_stream_nal_unit( ) function. However, the reference software computes this number by looking for the next start code (0x000001).
  Is it possible for the bitstream to generate this sequence of bits within the residual_block_cavlc( ) function? For example, if the encoder puts 
          - level_prefix = 15                                   (puts a code 0000 0000 0000 0001) 
          - level_suffix = 512, levelSuffixLength=12  ( puts a code 0001 0000 0000 ) 
          - level_prefix = 15                                   (puts a code 0000 0000 0000 0001) 
  the last two lines could emulate a start code, unless there is a mechanism to prevent it. 
  I'd appreciate some insight into this issue. If it has already been discussed, I'd appreciate a pointer to the discussion.
  Thanks, 
  --Shankar. 
------------------------------------------------------------------------------
  _______________________________________________
  Mp4-tech mailing list
  Mp4-tech lists.mpegif.org
  http://lists.mpegif.org/mailman/listinfo/mp4-tech
  Note: Conduct on the mailing list is subject to the Antitrust guidelines found at http://www.mpegif.org/public/documents/vault/mp-out-30042-Antitrust.php
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20040505/f0f02c09/attachment.html