[FFmpeg-devel] [PATCH] AAC decoder

[Robert Swain]

2008/5/29 Michael Niedermayer <michaelni at gmx.at>:
> On Thu, May 29, 2008 at 12:05:30AM +0100, Robert Swain wrote:
>> 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

Patch applied. Working on static tables.

>> OK but, why should pow2sf_tab be static and ivquant_tab not? And, I
>
> ivquant_tab should as well
>
>> assume by static you mean I should generate the values for the table
>> and put it into aactab.h, right?
>
> Well ...
> as you ask, the best thing is to have them hardcoded under
> CONFIG_HARDCODED_TABLES and have the generator code under
> !CONFIG_HARDCODED_TABLES. That way people can choose what they
> prefer ...

I'm considering what precision to use for the tables. Using printf()
%42.32f gives the first value as:

             0.00000000000000088817841970012523,

and the last as:

     451452825.35479241609573364257812500000000,

How does one decide such things? :)

Rob