[FFmpeg-devel] [PATCH] AAC decoder

[Michael Niedermayer]

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

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

It is not what we do, but why we do it that matters.
-------------- 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/20080528/35db1b3d/attachment.pgp>