[FFmpeg-devel] Understanding the CABAC decoder implementation (at least a bit)

[Michael Niedermayer]

On Wed, Jun 11, 2014 at 09:39:12AM +0200, Philipp B wrote:
> Hi,
> 
> I am doing some research about the h.264 format, and I am
> especially interested in the size of each macroblock in bits.
> 
> My idea is hacking some printf statement around the call to
> ff_h264_decode_mb_cabac in h264_slice.c and decoding files
> for analysis then.
> By looking at h->cabac.bytestream_start, I get a rough estimation
> of the used space, with 2 byte accuracy. However, I can't figure a
> way to get the exact read position in terms of bits from the
> CABACContext. In fact I have a pretty hard time understanding the
> implementation.
> 
> This is my current printf code:
> 
> >  int start_pos = h->cabac.bytestream-h->cabac.bytestream_start;
> >  int ret = ff_h264_decode_mb_cabac(h);
> >  printf(" MB size : %d \n", h->cabac.bytestream -
> h->cabac.bytestream_start-start_pos );
> 
> I understand the core idea of arithmetic coding allows even fractional
> bit sizes for coded symbols, but I guess theres a way to estimate the
> number of Symbols remaining in the CABACContext, presumably by
> interpreting the 'low' and 'range' fields.
> 
> So, how do I extend the code above to show the space used in bits?

see get_rac_count() for similar code to what you ask for.


>
> Also I would appreciate any link which helps to understand
> the CABAC implementation.

iam only aware of
the h264 spec, the reference implementation and the ffmpeg source code

but maybe there are some more elaborate and readable texts to be found
elsewhere like the jvt mailing list

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The worst form of inequality is to try to make unequal things equal.
-- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140615/4143b3bc/attachment.asc>