[FFmpeg-devel] [PATCH] Common ACELP code & G.729 [6/7] - G.729 postfilter

Vladimir Voroshilov voroshil
Sat May 17 19:12:52 CEST 2008


2008/5/14 Michael Niedermayer <michaelni at gmx.at>:
> On Wed, May 14, 2008 at 12:25:24AM +0700, Vladimir Voroshilov wrote:
>> 2008/5/12 Michael Niedermayer <michaelni at gmx.at>:

[...]

> gain_num <<= sh_gain_num;
> gain_den <<= sh_gain_den;
> lt_filt_factor_a = FFMAX((gain_den << 15) / (gain_den + gain_num), 0x10000/3);
>
> with 64bit casts if needed.

Rejected :)

===cut===
       L64_temp0 = ((int64_t)gain_num) << sh_gain_num;
        L64_temp1 = ((int64_t)gain_den) << sh_gain_den;
        lt_filt_factor_a = FFMAX((L64_temp1 << 15) / (L64_temp1 +
L64_temp0), 0x10000/3);
===cut===

Decreases PSNR (ffmpeg<->reference) from bitexact to ~51.

===cut===
       L64_temp0 = ((int64_t)gain_num) << (sh_gain_num - 1);
        L64_temp1 = ((int64_t)gain_den) << sh_gain_den;
        lt_filt_factor_a = FFMAX((L64_temp1 << 15) / (L64_temp1 +
L64_temp0), 0x10000/3);
===cut==

Is better, but of course not bitexact.
Ok to put old code under G729_BITEXACT ?

> Also note that the explicit exp/mantisse split (X + sh_X) is completely
> unacceptable, use float or use fixed point integers but not this float
> emulation

I've tried several times to play with fixed point but with no luck yet
(bad PSNR in all cases).
And I'm sure that having one floating-point routine in fixed-point decoder
is not a good idea, even if fixed point implementation uses
exp/mantissa floating point
emulation.

If it is possible i want to ask to focus on common code and decoder core now,
because decoder can work even without postfilter (with worse quality,
of course),
what means it can be committed after all other patches.

-- 
Regards,
Vladimir Voroshilov mailto:voroshil at gmail.com
JID: voroshil at gmail.com, voroshil at jabber.ru
ICQ: 95587719




More information about the ffmpeg-devel mailing list