[FFmpeg-devel] [PATCH] E-AC-3 decoder, round 3
Justin Ruggles
justinruggles
Sat Aug 23 02:16:39 CEST 2008
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
More information about the ffmpeg-devel
mailing list