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

Gary Sullivan garysull windows.microsoft.com
Sat May 17 11:12:31 EDT 2008


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-Antitrust.php


More information about the Mp4-tech mailing list