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

Vladimir Voroshilov voroshil
Tue Apr 22 18:53:10 CEST 2008


Michael Niedermayer wrote: 
> 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:

[...]

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

ok

> 
> 
> [...]
> > +
> > +/**
> > + * 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

Fixed

> [...]
> > +/**
> > + * \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

ok

> > +    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?

While writing comments i've rechecked min/max return values and found possible
overflow. It doesn't triggers on any vectors but is theoretically possible.

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

Small note: original code uses 19 bit per fractional part of slope,
while this is uses only 15.
Didn't compare with float though.

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

This is rhetorical question :) ?

I prefer to keep bitexact code at least till commit into FFmpeg tree.
This makes developments much simple and safe in terms of breaking anything.
Of course i can keep bitexact routines in local tree only and commit more
precise math operations to tree.
Thus if new code gives acceptable results i'll not have anything against it.

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

Here is testing results.
REF - decoded by reference code.
ORIG - original pcm from ITU's test vectors collection
FFMPEG - decoded by FFmpeg code with your cos and exp2 routines

ORIG vs REF

ALGTHM  stddev:16583.11 PSNR:11.93 bytes:4096
FIXED   stddev:1506.05 PSNR:32.76 bytes:18432
LSP     stddev:751.20 PSNR:38.80 bytes:356352
PITCH   stddev:8111.08 PSNR:18.14 bytes:292864
SPEECH  stddev:3255.55 PSNR:26.07 bytes:598016
TAME    stddev:1934.38 PSNR:30.59 bytes:20480

ORIG vs FFMPEG

ALGTHM  stddev:16587.28 PSNR:11.92 bytes:4096
FIXED   stddev:1506.05 PSNR:32.76 bytes:18432
LSP     stddev:748.15 PSNR:38.84 bytes:356352
PITCH   stddev:8111.23 PSNR:18.14 bytes:292864
SPEECH  stddev:3256.37 PSNR:26.06 bytes:598016
TAME    stddev:1962.02 PSNR:30.47 bytes:20480

REF vs FFMPEG

ALGTHM  stddev:178.10 PSNR:51.31 bytes:4096
FIXED   stddev:  1.08 PSNR:95.64 bytes:18432
LSP     stddev: 24.93 PSNR:68.38 bytes:356352
PITCH   stddev: 30.30 PSNR:66.69 bytes:292864
SPEECH  stddev: 37.05 PSNR:64.94 bytes:598016
TAME    stddev:105.17 PSNR:55.88 bytes:20480

P.S. comparing with other routines new exp2 looks a bit complicated.

P.P.S. attaching new version as .c file (since not committed to local tree yet)

-- 
Regards,
Vladimir Voroshilov mailto:voroshil at gmail.com
Omsk State University
JID: voroshil at jabber.ru
ICQ: 95587719
-------------- next part --------------
A non-text attachment was scrubbed...
Name: acelp_math.c
Type: text/x-csrc
Size: 4343 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080422/f0ab7a8d/attachment.c>



More information about the ffmpeg-devel mailing list