FW: [Mp4-tech] Smallest Possible (Skipped) Frame?

Tue May 20 23:39:46 EDT 2008

Forward of email from non-subscribed address 
-----Original Message-----
From: Detlev Marpe [mailto:marpe hhi.de] 
Sent: Monday, 19 May, 2008 16:44
To: 'Gary Sullivan'; 'nick hunter'; Mp4-tech lists.mpegif.org
Subject: RE: [Mp4-tech] Smallest Possible (Skipped) Frame?
A few hints on that subject from my side:
1) The minimum probability estimate for adaptively coded bins 
in CABAC is 0.01875. Thus, the lower bound on coded bits per 
bin is -log2( 1.0-0.01875) = 0.0273... which means an upper 
bound of 36 bins per bit. 
2) In H.264/AVC, as you may know, we also have non-adaptively 
coded bins, one of which is the so-called end_of_slice_flag. 
The least probable symbol related to these events (e.g., the 
value of 1 for end_of_slice_flag) is represented with a fixed, 
minimum sub-interval range of 2, which corresponds to a model 
probability of 2/R with R denoting the given interval range 
of the CABAC coding engine. Since 256 <= R < 512, it follows 
that, e.g., end_of_slice_flag with a value of 1 always costs 
you at least 7 bits, whereas for a value of 0, i.e., the most 
probable symbol of the same flag, the number of bits is 
strictly greater than -log2(1-2/512).
With this information you should be able to compute the lower 
bit bound for the particular case you have in mind. But don't 
forget to take into account the bits for end_of_slice_flag in 
the CABAC case, since this information is required to be 
signaled for each MB (at least as long as MBAFF is not used) ...
Best Regards,
Detlev Marpe
--
Dr. Detlev Marpe
Senior Project Manager
Image Processing Department
Fraunhofer Institute HHI
Einsteinufer 37
D-10587 Berlin, Germany
phone: +49 30 31002 619
fax:   +49 30 392 72 00
http://iphome.hhi.de/marpe
> -----Original Message-----
> From: Gary Sullivan [mailto:garysull windows.microsoft.com] 
> Sent: Samstag, 17. Mai 2008 19:13
> To: nick hunter; Mp4-tech lists.mpegif.org
> Cc: detlev.marpe hhi.de
> Subject: RE: [Mp4-tech] Smallest Possible (Skipped) Frame?
> 
> Nick Hunter et al,
> 
> I am pretty sure that the phenomenon of always having at 
> least one non-skipped MB is not a limitation of the standard 
> -- it is just something happening from the way that 
> particular encoding software works.  If you figure out why 
> that is happening, let me know and I'll see if we can get it 
> changed (although it seems like a low priority issue).
> 
> I suppose that whether CABAC or CAVLC becomes more efficient 
> for such usage is likely to depend on the number of 
> macroblocks in the picture (and the value of cabac_init_idc).
> 
> CABAC has a minimum probability estimate that is assigned to 
> any possible event, so there will be some assymptotic limit 
> on the number of skipped macroblocks that can be represented 
> per encoded CABAC bit in a picture containing an infinite 
> number of skipped macroblocks.  But I don't remember what the 
> limit is.  Detlev Marpe would remember.  I copied him on this message.
> 
> Best Regards,
> 
> Gary Sullivan
> ________________________________________
> From: mp4-tech-bounces lists.mpegif.org 
> [mp4-tech-bounces lists.mpegif.org] On Behalf Of nick hunter 
> [doropantis gmail.com]
> Sent: Friday, May 16, 2024 12:33 PM
> To: Mp4-tech lists.mpegif.org
> Subject: [Mp4-tech] Smallest Possible (Skipped) Frame?
> 
> Hi,
> I would like to understand the size of the smallest possible 
> encoded frame and am not sure if I understand all parameters involved:
> - For CAVLC the skip_run entry could be set to the number of 
> macroblocks in the frame in order to skip all blocks.
> - For CABAC the mb_skip_flag is set for all block and the 
> CABAC encoding should aggregate several blocks to one bit, 
> depending on the cabac_init_idc, _not_ depending on previous 
> slices. The resulting size is a function of the frame size 
> and the CABAC coding. Is there an easy way to look up that value?
> 
> When using JM 13.0 code (VC6 or VC2005) on IDENTICAL frames, there is
> 1 MBlk that is not skipped (SD, more on HD).
> When I look at the encoder trace, the bitcounter marked with 
> @ in the start of the line indicate that there are only 10 
> cabac bits used to encode the skip_flags, while the B frame 
> is 200 bits in size according to the screen output.
> 
> Any hints for the following questions are appreciated:
> - Do the @ positions in the encoding trace really indicate 
> how many bits have been used at encoding?
> - How can I determine the theoretical minimum of the frame 
> for CABAC / CAVLC?
> - I assume there is a maximum number of skipped mb that can 
> be encoded with a single CABAC symbol / bit, where can I find that?
> - Is it a codec  limitation that there is a non skipped block 
> when an identical b frame is encoded or is it a JM imprecision?
> - Is the minimum frame size indeed smaller using CAVLC (using
> skip_run) than CABAC (skipping all blocks)?
> 
> Thank you!
> Nick
> _______________________________________________
> NOTE: Please use clear subject lines for your posts. Include 
> [audio, [video], [systems], [general] or another apppropriate 
> identifier to indicate the type of question you have.
> 
> Note: Conduct on the mailing list is subject to the Antitrust 
> guidelines found at 
> http://www.mpegif.org/public/documents/vault/mp-out-30042-Anti
> trust.php
> 

----
Visit us at
22. Treffpunkt Medizintechnik / Berlin, Germany / 22. May 2008
Lehrgebaeude der Charite Berlin
http://www.tsbmedici.de 
ANGA Cable 2008 / Cologne, Germany / 27-29 May 2008 / Hall 10.3, Booth G38
http://www.angacable.com