[FFmpeg-devel] [PATCH] Common ACELP routines (2/3) - filters
Vladimir Voroshilov
voroshil
Sun Apr 27 20:02:32 CEST 2008
On Sun, Apr 27, 2008 at 10:57 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
>
> On Sun, Apr 27, 2008 at 08:39:15PM +0700, Vladimir Voroshilov wrote:
[...]
> > Here is latest version.
>
> [...]
> > +void ff_acelp_interpolate_excitation(
> > + int16_t* ac_v,
> > + int pitch_delay_int,
> > + int pitch_delay_frac,
>
> > + int subframe_size)
> > +{
> > + int n, i;
> > + int v;
> > +
> > + /* The lookup table contain values corresponding
> > + to -2/6 -1/6 0 1/6 2/6 3/6 fraction order.
>
> > + The filtering process uses a negative pitch lag offset, but
> > + a negative offset should not be used in then table. To avoid
> > + a negative offset in the table dimension corresponding to
> > + fractional delay the following conversion applies:
> > +
>
> trailing whitespace
Fixed.
> > + -pitch_delay = -(6*pitch_delay_int+pitch_delay_frac) =
> > +
> > + = -6*pitch_delay_int - pitch_delay_frac =
> > +
> > + / -6*(pitch_delay_int) - pitch_delay_frac, pitch_delay_frac < 0
> > + =<
> > + \ -6*(pitch_delay_int+1) + (6-pitch_delay_frac), pitch_delay_frac >= 0
> > + */
> > +
> > + /* Compute negative value of fractional delay */
> > + pitch_delay_frac = - pitch_delay_frac;
> > +
>
> > + /* Now make sure that pitch_delay_frac will always be positive */
>
> > + if(pitch_delay_frac < 0)
> > + {
> > + pitch_delay_frac += 6;
> > + pitch_delay_int++;
> > + }
>
> Can it really be >= 0 and <0 ?
Didn't understand you.
According to current pitch delay decode routine pitch_delay_frac
belongs to [-2; 3]
-pitch_delay_frac belongs to [-3; 2]
> > +void ff_acelp_weighted_filter(
> > + int16_t *out,
> > + const int16_t* in,
> > + int16_t weight,
> > + int filter_length)
> > +{
> > + int weight_pow = 1 << 15;
> > + int n;
> > +
> > + for(n=0; n<filter_length; n++)
> > + {
> > + /* (0.15) * (3.12) and (3.27) -> (3.12) with rounding */
> > + out[n] = (in[n] * weight_pow + 0x4000) >> 15;
> > + /* (0.15) * (3.12) and (3.27) -> (3.12) with rounding */
> > + weight_pow = (weight_pow * weight + 0x4000) >> 15;
> > + }
> > +}
>
> as weight is a constant weight_pow is as well and half of the computations
> are unneeded
Now routine accepts array of constants.
> > +void ff_acelp_high_pass_filter(
> > + int16_t* out,
>
> > + int16_t* hpf_z,
> > + int* hpf_f,
> > + const int16_t* in,
>
> > + int length)
> > +{
> > + int i;
> > +
> > + for(i=0; i<length; i++)
> > + {
> > + memmove(hpf_z + 1, hpf_z, 2 * sizeof(hpf_z[0]));
> > + hpf_z[0] = in[i];
>
> > +
> > + hpf_f[0] = MULL(hpf_f[1], 15836);
> > + hpf_f[0] += MULL(hpf_f[2], -7667);
> > +
> > + hpf_f[0] += 7699 * (hpf_z[0] - 2*hpf_z[1] + hpf_z[2]);
> > +
> > + /* Clippin is required to pass G.729 OVERFLOW test */
>
> > + if(hpf_f[0] >= 0xfffffff)
> > + {
> > + out[i] = SHRT_MAX;
>
> > + hpf_f[0] = 0x3fffffff;
> > + }
> > + else if (hpf_f[0] <= -0x10000000)
> > + {
> > + out[i] = SHRT_MIN;
>
> > + hpf_f[0] = -0x40000000;
> > + }
> > + else
> > + {
>
> > + hpf_f[0] <<= 2;
>
> The shift is avoidable i think as already said
Changed and added comment about bitexactness.
There is also some not clear thing for me..
ff_acelp_interpolate_excitation (according to math) is just an low-pass filter.
But it is intended to build adaptive-codebook (pitch) vector from
previous speech data.
I wonder should it be moved to something like acelp_vectors.c (along
with fixed codebook (innovation) vector decoding, fixed vector
updating and building excitation signal from pitch and innovation
vectors) ?
--
Regards,
Vladimir Voroshilov mailto:voroshil at gmail.com
JID: voroshil at gmail.com, voroshil at jabber.ru
ICQ: 95587719
-------------- next part --------------
A non-text attachment was scrubbed...
Name: acelp_filt_39.diff
Type: text/x-diff
Size: 12687 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080428/974a3af4/attachment.diff>
More information about the ffmpeg-devel
mailing list