[FFmpeg-devel] [PATCH] Split huffman_tables into codes and bits in mlpdec

[Michael Niedermayer]

On Tue, Aug 12, 2008 at 04:32:18PM -0300, Ramiro Polla wrote:
> Hello,
> 
> On Tue, Aug 12, 2008 at 3:17 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> > On Tue, Aug 12, 2008 at 02:49:46PM -0300, Ramiro Polla wrote:
> >> Hello,
> >>
> >> Attached patch splits huffman_tables into codes and bits tables in
> >> mlpdec.c. This will be shared with the encoder. This makes it easier
> >> for the encoder to reuse two out of three huffman_bits tables and a
> >> third custom table.
> >
> > why does it make it easier?
> > iam not against this patch but i like to understand it first
> 
> Hmmm, let me see if I can manage to explain it.
> 
> MLP encodes residuals using a codebook for the higher bits, and then
> encodes the rest from that as verbatim. It has 3 codebooks. The vlc
> code 0 equals -7 for all of them. But MLP also does a sign shift,
> which is different depending on the codebook. For codebook 1 it's -2
> (so vlc code 0 is effectively -9), for codebook 2 it's -1 (so vlc code
> 0 is effectively -8), and for codebook 3 it's not on the vlc code, but
> on the last bit of the residual from the vlc. For example:
> 
> codebook 1:
> 000 111 + sign_shift = 010 111
> vlc code 7 + 2 (010) = 9
> residual = 111
> 
> codebook 3:
> 000 111 + sign_shift = 001 011
> vlc code 7 + 1 (001) = 8
> residual = 011
> 
> To simplify the bitcount code, codebooks 1 and 2 only check the higher
> bits against the huffman_bits array, since their value doesn't depend
> on the rest that will be encoded verbatim. But for codebook 3, it
> depends on one more bit. So I made one more array for codebook 3 that
> takes that into account, and so has double the size (for the extra bit
> being 0 and 1).
> 
> For the same explanation in C, look at huffman_bitcount2,
> huffman_bitcount, codebook_extremes, and codebook_bits_offset() from
> mlpenc.c in the SoC repo.

hmm, if a slightly different value was used for offset (in the code) then the
shift (if it where +1) would make the codebook 3 case work out fine with
the same table.
Its a little bit like pretending that codebook 3 had an entry more that just
has no valid vlc associated with it.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080812/ae99a4a6/attachment.pgp>