[FFmpeg-devel] [PATCH] AAC decoder

[Michael Niedermayer]

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

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The worst form of inequality is to try to make unequal things equal.
-- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080529/ff69ccd7/attachment.pgp>