[FFmpeg-devel] [PATCH] E-AC-3 decoder, round 3

[Justin Ruggles]

Michael Niedermayer wrote:
> On Fri, Aug 22, 2008 at 06:01:22PM -0400, Justin Ruggles wrote:
> [...]
>>>> +
>>>> +            for (blk = 0; blk < 6; blk++) {
>>>> +                int mant = get_sbits(gbc, gbits);
>>>> +                if (mant == -(1 << (gbits-1))) {
>>>> +                    /* large mantissa */
>>>> +                    int64_t b;
>>>> +                    mant = get_sbits(gbc, bits-2+log_gain) << (26-log_gain-bits);
>>>> +                    /* remap mantissa value to correct for asymmetric quantization */
>>>> +                    if (mant >= 0)
>>>> +                        b = 32768 >> log_gain;
>>>> +                    else
>>>> +                        b = ff_eac3_gaq_remap_2_4_b[hebap-8][log_gain-1];
>>>> +                    mant += ((int64_t)ff_eac3_gaq_remap_2_4_a[hebap-8][log_gain-1] * mant + b) >> 15;
>>> this can be done without a 64 bit multiple i think
>> I can see how it works for the other one, but not for this one.  In the
>> other case it works out well because mant will always have zeros for at
>> least the low 8 bits.  For this case, I don't see where avoiding the
>> 64-bit multiply is possible without loss of precision.
> 
> mant can have bits-2+log_gain bits
> bits has a max of 16, log_gain 2 or 3
> that makes it need of 16 + sign
> ff_eac3_gaq_remap_2_4_a has 14+ sign
> thus a product of them would need 30 + sign if no left shift is applied
> b has to be shifted right of course but no precission is lost that way as
> it would be shifted away anyway, its stil bitexact ...

ok, thanks for explaining.  I'll post a new patch soon with the changes.

-Justin