[FFmpeg-devel] [PATCH] Common fixed-point ACELP routines (1/3) - math

[Michael Niedermayer]

On Tue, Apr 22, 2008 at 09:12:16AM +0700, Vladimir Voroshilov wrote:
> On Tue, Apr 22, 2008 at 6:05 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
[...]> >  > + * \brief Calculates log2(x)
> >  > + * \param value function argument (>0)
> >  > + *
> >  > + * \return (Q15) result of log2(value)
> >  > + */
> >
> >  > +int ff_acelp_log2(int value)
> >
> >  These functions have nothing to do with acelp. log,cos,
> >  exp2 (yes please name it exp2 not pow2) have been known before acelp.
> 
> ff_acelp_pow2_14_x renamed to ff_acelp_exp2.
> 
> Do you want to say that i have choosen wrong file to place them in (as
> long as their prefix) ?
> Please suggest proper place and prefix and i'll fix it immediately.

I cant think of a good name ATM, i guess we can always rename it later
after its in svn ...


[...]
> +
> +/**
> + * Cosine table: ff_acelp_base_cos[i] = (1<<15) * cos(i*PI/64)
> + */

> +static const int16_t ff_acelp_base_cos[64] =

Because its static, base_cos should be fine. Same for the other tables

[...]
> +/**
> + * \brief fixed-point implementation of cosine in [0; PI) domain
> + * \param arg fixed-point cosine argument, 0 <= arg < 0x4000
> + *
> + * \return value of (1<<15) * cos(arg * PI / (1<<14)), -0x8000 <= result <= 0x7fff
> + */
> +int16_t ff_acelp_cos(uint16_t arg)
> +{

> +    uint8_t offset= arg & 0xff;

the & 0xff is uneeded


> +    uint8_t ind = arg >> 8;
> +
> +    assert(arg < 0x4000);
> +
> +    return FFMAX(ff_acelp_base_cos[ind] + ((ff_acelp_slope_cos[ind] * offset) >> 12), -0x8000);
> +}

The FFMAX is new i think, why is it needed now?

Also:
    uint8_t offset= arg;
    uint8_t ind   = arg >> 8;

    return base_cos[ind] + (((base_cos[ind+1] - base_cos[ind]) * offset) >> 8);

is slightly more accurate and needs just half the tables (add a -32768
at the end of base_cos)
Sadly this is not bitexact.
The question here is, is it possible at all to maintain bitexactness with
common code? 
I assume the other acelp codecs use slightly different integer
implementations?
Also what effect do such minor change have on the reference bitstreams,
that is by how much does the output differ?
And more important if you encode some test signal by how much do the
(refernce decoder vs. original wave) and (your decoder vs. original wave)
differ?


and
static const int16_t base_cos2[65] = {
  32767,  32738,  32617,  32421,  32145,  31793,  31364,  30860,
  30280,  29629,  28905,  28113,  27252,  26326,  25336,  24285,
  23176,  22011,  20793,  19525,  18210,  16851,  15451,  14014,
  12543,  11043,   9515,   7965,   6395,   4810,   3214,   1609,
      1,  -1607,  -3211,  -4808,  -6393,  -7962,  -9513, -11040,
 -12541, -14012, -15449, -16848, -18207, -19523, -20791, -22009,
 -23174, -24283, -25334, -26324, -27250, -28111, -28904, -29627,
 -30279, -30858, -31363, -31792, -32144, -32419, -32616, -32736, -32768,
};

leads to a more accurate approximation than the table used.


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

Republics decline into democracies and democracies degenerate into
despotisms. -- 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/20080422/a535cd1c/attachment.pgp>