[FFmpeg-devel] [PATCH] Split huffman_tables into codes and bits in mlpdec
Wed Aug 13 01:17:19 CEST 2008
On Tue, Aug 12, 2008 at 5:37 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> 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.
Thanks... I changed the code to what it was before and changed offset instead.
But I kept the checks for the shifted values though
(codebook_extremes). I think it's simpler this way.
More information about the ffmpeg-devel