[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