[Mp4-tech] On cabac_zero_word in H.264

[Shevach Riabtsev]

Hi Gary 
First of all thanks for documents. 
I think that the "evil bitstream" fear is exaggerated. Simple entropy calculation shows that the theoretical limit for bin/bit ratio is 8:1. 
Indeed, the minimal probability value for LPS (least-probable symbol) is p=0.01875 . 
If we assume that all bins in a picture are coded with probability of LPS equal 0.01875, then the entropy 
     H= -p log2(p) - (1-p) log2(1-p)  = 0.1341 bit/bin  
Hence the maximal bin/bit ratio is 8:1 .   
So, if a decoder gets an access unit with bit size N, then the maximal number of bins shall not exceed 8N. The 8N limit is not so overwhelming (in my opinion).
According to my experience I have never observed per single bin the bin/bit ratio exceeding 5:1 (5:1 bin/bit ratio can be observed on end_of_slice_flag syntax elements, since most time they are zero). Therefore the real bin/bit limit should be 5:1 or 6:1. 
Regards, Shevach
Broadcom
________________________________
From: Gary Sullivan [mailto:garysull windows.microsoft.com] 
Sent: Wednesday, May 09, 2024 9:47 PM
To: Shevach Riabtsev; mp4-tech lists.mpegif.org
Subject: RE: [Mp4-tech] On cabac_zero_word in H.264
Shevach et al,
It doesn't actually hurt the quality of the video per se, but it does decrease the degree of compression.  Indeed, that is sort of its purpose.  We were worried that the compression design might be too good and would threaten our future careers, so we put this feature in as a hidden way to protect ourselves.  Please keep that information hush-hush.  :-)
More seriously, the idea was that if there was no limit on the number of bins that a certain number of bits could generate, the decoder could be overwhelmed by an "evil bitstream" -- it was a fear of a sort of "drinking from a firehose" situation.  The belief is that the constraint will rarely have any impact when actually coding typical video.  But without the constraint, a decoder designer might have to consider worst-case scenarios where the effective incoming bin rate (due to an unlimited expansion from bits to bins) could become basically unlimited.
So this aspect of the design ought to be considered to be good news to companies like Broadcom that want to make decoders that can work properly for any conforming bitstream.
I believe this aspect evolved from proposal JVT-C038 by Frank Bossen, with subsequent contributions on the topic by Detlev Marpe, Gabi Blättermann, Thomas Wiegand, Ali Tabatabai, Toby Walker, and Eric Viscito, and perhaps others.  I think the final form was established at the Awaji "F" meeting in December 2002.  Relevant documents may include JVT-C038, JVT-D019, JVT-D088, JVT-D114, JVT-F039, and JVT-F054.
Best Regards,
Gary Sullivan
________________________________
From: mp4-tech-bounces lists.mpegif.org [mailto:mp4-tech-bounces lists.mpegif.org] On Behalf Of Shevach Riabtsev
Sent: Wednesday, May 09, 2024 2:12 AM
To: mp4-tech lists.mpegif.org
Subject: [Mp4-tech] On cabac_zero_word in H.264
Dear experts 
According to AVC standard (section 7.4.1), one or more cabac_zero_word 16-bit syntax elements equal to 0x0000 may be present in some RBSPs after the rbsp_trailing_bits( ). 
The section 7.4.2.10 says:
    When entropy_coding_mode_flag is equal to 1, BinCountsInNALunits shall not exceed    ( 32 ÷ 3 ) * NumBytesInVclNALunits+ ( RawMbBits * PicSizeInMbs )  ÷ 32. 
Here NumBytesInVclNALunits means the sum of the values of NumBytesInNALunit for all VCL NAL units of a coded picture and BinCountsInNALunits is the number of times that the parsing process function DecodeBin( ).
If the actual number of bins exceeds the value specified by the above formula, then cabac_zero_words should be added (in this way NumBytesInVclNALunits is incremented). 
I don't understand completely why BinCountsInNALunits is restricted ? 
Why additional stuffing should be added to bit-stream to result BinCountsInNALunits shall not exceed    ( 32 ÷ 3 ) * NumBytesInVclNALunits+ ( RawMbBits * PicSizeInMbs )  ÷ 32, it might hurt video quality?
Regards, Shevach
Broadcom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20070510/a81a2239/attachment-0001.html