[Mp4-tech] On restriction on the total number of bits of data per MB

[Gary Sullivan]

Shevach et al,
You seem to have forgotten about I_PCM mode.
I think what most people would do is that if they discover that a MB uses too many bits, they would give up and just send the raw sample values using I_PCM mode.  An I_PCM macroblock should never exceed the limit (and can represent the sample values perfectly).  Of course, increasing QP and coding the MB again, as you suggested, is another possibility.
Best Regards,
Gary Sullivan
________________________________
	From: mp4-tech-bounces lists.mpegif.org [mailto:mp4-tech-bounces lists.mpegif.org] On Behalf Of Shevach Riabtsev
	Sent: Tuesday, June 26, 2023 9:33 PM
	To: mp4-tech lists.mpegif.org
	Subject: [Mp4-tech] On restriction on the total number of bits of data per MB
	Dear experts
	According to A.3.1 (item "n") and A.3.2 (item "j") sections, there is a restriction on the total number of bits of data per MB for both Main and High profiles. 
	Indeed, for Main Profile the following restriction is present:
	    Number of bits of macroblock_layer( ) data for any macroblock is not greater than 3200.
	For High Profile the analogous statement is present:
	     Number of bits of macroblock_layer( ) data for any macroblock is not greater than 128 + RawMbBits.
	e.g. for 4:2:0 case,  RawMbBits = 3072. 
	How RT encoder's designer can gurantee that the size of a MB will not exceed 3200 bits?  
	Indeed, the only available mechanism effectively impacting on MB length is the QP adjustment. For instance, one can estimate bit-size (or bin-size for CABAC case) of a given MB basing on the variance and the mean of the given MB. This estimation is true with some (may be very high) significance level, but in my opinion this method can't gurantee that the size would not exceed 3200. So, if the actual size of an "evil" MB exceeds 3200 limit, what to do  - adjust QP and start again with the same MB!!!
	 Regards,  Shevach
	Broadcom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20070627/c796c3fe/attachment-0001.html