[FFmpeg-devel] [PATCH] Common ACELP routines (2/3) - filters

[Michael Niedermayer]

On Sun, Apr 27, 2008 at 12:02:01PM +0700, Vladimir Voroshilov wrote:
> On Sun, Apr 27, 2008 at 5:08 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
> >
> > On Sun, Apr 27, 2008 at 03:12:39AM +0700, Vladimir Voroshilov wrote:
> 
> [...]
> 
> >  > +void ff_acelp_convolve_circ(
> >  > +        int16_t* fc_out,
> >  > +        const int16_t* fc_in,
> >  > +        const int16_t* filter,
> >
> > > +        int subframe_size)
> >  > +{
> >  > +    int i, k;
> >  > +
> >  > +    memset(fc_out, 0, subframe_size * sizeof(int16_t));
> >  > +
> >  > +    for(i=0; i<subframe_size; i++)
> >  > +    {
> >  > +        if(fc_in[i])
> >  > +        {
> >  > +            for(k=0; k<i; k++)
> >  > +                fc_out[k] += (fc_in[i] * filter[subframe_size + k - i]) >> 15;
> >  > +
> >  > +            for(k=i; k<subframe_size; k++)
> >  > +                fc_out[k] += (fc_in[i] * filter[k - i]) >> 15;
> >  > +        }
> >  > +    }
> >  > +}
> >
> >  where is this used? I cant find it in g729dec_18.diff
> 
> You already asked me few mails ago.
> This routines is used for AMR and G.729D
> You agreed to keep it here.

Id like to see the code using it. Its hard to comment code which is
"incomplete"


[...]
> >  [...]
> >  > +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) -> (3.12) with rounding
> >
> >  please write the comment in the same order as the calculation:
> >  (3.12) = (0.15) * (3.12) or whatever
> 
> Here and in another places (like recently committed lsp.c) such comment
> describes right side of expression only and  "->" in it means change of the
>  fixed-point base (right shift in this particular case)
> Comment should be read as "multiply (0.15) by (3.12) and then scale
> result to (3.12)"
> 
> Thus comment and calculation order corresponds each other, imho.

a= b * c
b * c -> a
no they are ordered differently a,b,c vs. b,c,a

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

I hate to see young programmers poisoned by the kind of thinking
Ulrich Drepper puts forward since it is simply too narrow -- Roman Shaposhnik
-------------- 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/20080427/5b94c05d/attachment.pgp>