[FFmpeg-devel] [PATCH] AAC decoder

[Ivan Kalvachev]

On 5/25/08, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Sun, May 25, 2008 at 02:55:07PM +0100, Robert Swain wrote:
>> 2008/5/24 Michael Niedermayer <michaelni at gmx.at>:
>> > On Sat, May 24, 2008 at 06:35:37PM +0100, Robert Swain wrote:
>> >> 2008/5/23 Michael Niedermayer <michaelni at gmx.at>:
>> >> > On Fri, May 23, 2008 at 01:59:41PM +0100, Robert Swain wrote:
>> >> >> Index: aac.c
>> >> >> ===================================================================
>> >> >> --- aac.c     (revision 2185)
>> >> >> +++ aac.c     (working copy)
>> >> >> @@ -366,7 +366,7 @@
>> >> >>      DECLARE_ALIGNED_16(float, sine_short_128[128]);
>> >> >>      DECLARE_ALIGNED_16(float, pow2sf_tab[256]);
>> >> >>      DECLARE_ALIGNED_16(float, intensity_tab[256]);
>> >> >> -    DECLARE_ALIGNED_16(float, ivquant_tab[256]);
>> >> >> +    DECLARE_ALIGNED_16(float, ivquant_tab[128]);
>> >> >>      MDCTContext mdct;
>> >> >>      MDCTContext mdct_small;
>> >> >>      MDCTContext *mdct_ltp;
>> >> >> @@ -890,8 +890,11 @@
>> >> >>      // BIAS method instead needs values -1<x<1
>> >> >>      for (i = 0; i < 256; i++)
>> >> >>          ac->intensity_tab[i] = pow(0.5, (i - 100) / 4.);
>> >> >> -    for (i = 0; i <
>> >> >> sizeof(ac->ivquant_tab)/sizeof(ac->ivquant_tab[0]); i++)
>> >> >> -        ac->ivquant_tab[i] = pow(i, 4./3);
>> >> >> +    for (i = 0; i <
>> >> >> sizeof(ac->ivquant_tab)/(sizeof(ac->ivquant_tab[0])<<1); i++) {
>> >> >> +        int idx = i<<1;
>> >> >> +        ac->ivquant_tab[idx]     =  pow(i, 4./3);
>> >> >> +        ac->ivquant_tab[idx + 1] = -ac->ivquant_tab[idx];
>> >> >> +    }
>> >> >>
>> >> >>      if(ac->dsp.float_to_int16 == ff_float_to_int16_c) {
>> >> >>          ac->add_bias = 385.0f;
>> >> >
>> >> >> @@ -1035,13 +1038,12 @@
>> >> >>  }
>> >> >>
>> >> >>  static inline float ivquant(AACContext * ac, int a) {
>> >> >
>> >> >> -    static const float sign[2] = { -1., 1. };
>> >> >>      int tmp = (a>>31);
>> >> >>      int abs_a = (a^tmp)-tmp;
>> >> >> -    if (abs_a < sizeof(ac->ivquant_tab)/sizeof(ac->ivquant_tab[0]))
>> >> >> -        return sign[tmp+1] * ac->ivquant_tab[abs_a];
>> >> >> +    if (abs_a <
>> >> >> sizeof(ac->ivquant_tab)/(sizeof(ac->ivquant_tab[0])<<1))
>> >> >> +        return ac->ivquant_tab[(abs_a<<1) + !!tmp];
>> >> >
>> >> > ehh... this should be:
>> >> >
>> >> > if(a + 127U < 255U)
>> >> >    return ivquant_tab[a + 127U];
>> >> >
>> >> > (or other constants depending on what table size is best ...)
>> >> >
>> >> >
>> >> >>      else
>> >> >> -        return sign[tmp+1] * pow(abs_a, 4./3);
>> >> >> +        return (2 * tmp + 1) * pow(abs_a, 4./3);
>> >> >
>> >> > pow(fabs(a), 1./3) * a;
>> >>
>> >> With those suggestions it is much faster. The alternating sign
>> >> construction for the table wasn't my idea, but I won't name names. :)
>> >> Anyway, see attached. Benchmarks on the same FAAC encoded South Park
>> >> episode:
>> >>
>> >> old size 256
>> > [...]
>> >> 3956 dezicycles in ivquant, 2096816 runs, 336 skipsup=0 drop=0
>> >>
>> >> new size 8
>> > [...]
>> >> 4840 dezicycles in ivquant, 2066668 runs, 30484 skips=0 drop=0
>> >>
>> >> new size 16
>> > [...]
>> >> 3650 dezicycles in ivquant, 2093424 runs, 3728 skipsp=0 drop=0
>> >>
>> >> new size 32
>> > [...]
>> >> 3438 dezicycles in ivquant, 2096888 runs, 264 skipsup=0 drop=0
>> >>
>> >> new size 64
>> > [...]
>> >> 3447 dezicycles in ivquant, 2096915 runs, 237 skipsup=0 drop=0
>> >>
>> >> new size 128
>> > [...]
>> >> 3431 dezicycles in ivquant, 2096918 runs, 234 skipsup=0 drop=0
>> >>
>> >> new size 256
>> > [...]
>> >> 3431 dezicycles in ivquant, 2096953 runs, 199 skipsup=0 drop=0
>> >>
>> >> new size 512
>> > [...]
>> >> 3438 dezicycles in ivquant, 2097093 runs, 59 skipsdup=0 drop=0
>> >>
>> >> It looks to me like there's little difference in performance when the
>> >> table is of size 32 or larger. Should I use size 32?
>> >
>> > From the numbers i see, yes 32 seems the best choice.
>> >
>> > What bitrate did your test file have? High bitrate files might be faster
>> > with larger tables, so if it was low bitrate then it might be worth
>> > retrying
>> > with some higher bitrate.
>>
>> Same audio source but encoded to 320kbps with QuickTime.
>
>> I included
>> the full listings as some table sizes seem to behave strangely based
>> on the number of calls.
>
> Effects of the skipping of (some) pow() i assume ...
>
>
>>
>> size 32
> [...]
>> 16429 dezicycles in ivquant, 4169262 runs, 25042 skips drop=0
>>
>> size 64
> [...]
>> 11718 dezicycles in ivquant, 4147408 runs, 46896 skips drop=0
>>
>> size 128
> [...]
>> 7687 dezicycles in ivquant, 4148129 runs, 46175 skips0 drop=0
>>
>> size 256
> [...]
>> 5174 dezicycles in ivquant, 4166995 runs, 27309 skips0 drop=0
>>
>> size 512
> [...]
>> 3826 dezicycles in ivquant, 4183674 runs, 10630 skips0 drop=0
>>
>> size 1024
> [...]
>> 3250 dezicycles in ivquant, 4191225 runs, 3079 skips=0 drop=0
>>
>> size 2048
> [...]
>> 3109 dezicycles in ivquant, 4193283 runs, 1021 skips=0 drop=0
>
> From these numbers a table size of 1024 seems to be the lowest acceptable.
> I guess the 4kb space wont matter compared to the speed loss a small table
> would cause with such files.
>
>
>>
>> > [...]
>> >> +    for (i = 1; i < IVQUANT_SIZE/2; i++) {
>> >> +        ac->ivquant_tab[IVQUANT_SIZE/2 - 1 + i] =  pow(i, 4./3);
>> >> +        ac->ivquant_tab[IVQUANT_SIZE/2 - 1 - i] =
>> >> -ac->ivquant_tab[IVQUANT_SIZE/2 - 1 + i];
>> >> +    }
>> >
>> > cant that be simplified with pow(fabs(i), 1./3) * i as well?

Isn't i^(1/3) actually  cube root? There is C99 math.h function cbrt()
that calculates it, it may be a little faster.

BTW, if results are floats, why function that operate on doubles are used.
(vs. fabsf, powf etc..).