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

[Ramiro Polla]

Hi,

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:
>> 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.

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.

Ramiro Polla