[FFmpeg-devel] [PATCH] AAC decoder

[Robert Swain]

2008/5/28 Michael Niedermayer <michaelni at gmx.at>:
> On Wed, May 28, 2008 at 05:21:16PM +0100, Robert Swain wrote:
>> 2008/5/28 Robert Swain <robert.swain at gmail.com>:
>> > 2008/5/28 Michael Niedermayer <michaelni at gmx.at>:
>> >> On Wed, May 28, 2008 at 12:37:04PM +0100, Robert Swain wrote:
>> >>> 2008/5/26 Michael Niedermayer <michaelni at gmx.at>:
>> >>> > On Mon, May 26, 2008 at 12:42:37PM +0100, Robert Swain wrote:
>> >>> >> The tables are still different as intensity uses pow(0.5, (i-100)/4.)
>> >>> >> and the other cases use pow(2.0, (i-100)/4.).
>> >>> >
>> >>> > pow(0.5, (i-100)/4.) == pow(2.0, (100-i)/4.)
>> >>> >
>> >>> > and
>> >>> >
>> >>> > pow(2.0, (100-i)/4.) / 1024 == pow(2.0, (100-i)/4.-10) ==pow(2.0, (100-i-40)/4.)
>> >>> >
>> >>> > possibly these allow the 2 tables to be merged, i mean
>> >>> >
>> >>> > pow2sf_tab[i] and intensity_tab[i]
>> >>> > to
>> >>> > pow2sf_tab[i+C] and pow2sf_tab[-i]
>> >>>
>> >>> OK, I've thought about this a bit more. I think either sf_scale should
>> >>> be 'applied' just before downmixing/float_to_int16 conversion as in
>> >>> ac3dec.c or sf_scale can effectively be merged into this table almost
>> >>> entirely thanks to being representable as a power of 2 in either the C
>> >>> or SIMD float_to_int16 case.
>> >>>
>> >>> >From what I see there are 3 cases.
>> >>>
>> >>> - intensity table:
>> >>>   pow(0.5, (i-100)/4) = pow(2, (100-i)/4)
>> >>>   which would have indices [100-255, 100-0] = [-155, 100]
>> >>>
>> >>> - sf table when sf_scale is -1/1024:
>> >>>   pow(2, (i-100)/4) * -pow(2, -10) = -pow(2, (i-140)/4)
>> >>>   ignoring the sign issue, it would have indices [0-140, 255-140] = [-140, 115]
>> >>>
>> >>> - sf table when sf_scale is -1/(1024*32768):
>> >>>   pow(2, (i-100)/4) * -pow(2, -25) = -pow(2, (i-200)/4)
>> >>>   [0-200, 255-200] = [-200, 55]
>> >>>
>> >>> So, the range of indices into the table should be [-200, 115],
>> >>> sf_scale can be replaced by a constant integer offset into the table
>> >>> and we handle the signs with a little branching or something. Does
>> >>> that sound like a good idea? Any suggestions for alterations before I
>> >>> implement it?
>> >>
>> >> yes that was my idea (note ive not checked if the ranges are correct)
>> >
>> > Patch attached.
>>
>> Oops, I tried to be clever and save calculations for the indices into
>> pow2sf_tab by adding the 'static' offsets in the offset[] array but I
>> forgot about the offset[index] > 255 check. Corrected patch attached.
> [...]
>>      }
>> -    for (i = 0; i < 256; i++)
>> -        ac->pow2sf_tab[i] = pow(2, (i - 100)/4.) * ac->sf_scale;
>> +    /* [ 0, 255] scale factor decoding when using C dsp.float_to_int16
>> +     * [60, 315] scale factor decoding when using SIMD dsp.float_to_int16
>> +     * [45, 300] intensity stereo position decoding mapped in reverse order i.e. 0->300, 1->299, ..., 254->46, 255->45
>> +     */
>> +    for (i = 0; i < 316; i++)
>> +        ac->pow2sf_tab[i] = pow(2, (i - 200)/4.);
>
> this could be a static table instead of being duplicated in each context
>
> patch ok except that

OK but, why should pow2sf_tab be static and ivquant_tab not? And, I
assume by static you mean I should generate the values for the table
and put it into aactab.h, right?

Rob