[FFmpeg-devel] [PATCH] Split huffman_tables into codes and bits in mlpdec
Tue Aug 12 22:37:28 CEST 2008
On Tue, Aug 12, 2008 at 04:32:18PM -0300, Ramiro Polla wrote:
> 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
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel