[FFmpeg-devel] [PATCH] Common ACELP code & G.729 [1/7] - filters

Michael Niedermayer michaelni
Wed May 7 19:49:26 CEST 2008


On Wed, May 07, 2008 at 10:23:50AM +0700, Vladimir Voroshilov wrote:
[...]
> >  > 2. During process these two pulses are smoothed over all subframe and
> >  > written to "output" (!) buffer. "in" buffer remains the same.
> >  > 3. When used formula from doxygen comments, filter will make 40*40
> >  > multiplications (regardless of values in "in" buffer).
> >  > 4. When two loops are swapped (comparing to formula in doxygen
> >  > comment) and check for non-zero is added, filter will make only 2*40
> >  > multiplications (since input buffer is never touched).
> >  >
> >  > This is why i asked for phrase correctness (i meant not english, but
> >  > phrase meaning).
> >  >
> >  > >  > +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);                     /* (14.13) = (13.13) * (1.13) */
> >  > >  > +        hpf_f[0] += MULL(hpf_f[2], -7667);                     /* (13.13) = (13.13) * (0.13) */
> >  > >  > +        hpf_f[0] += 7699 * (hpf_z[0] - 2*hpf_z[1] + hpf_z[2]); /* (14.13) =  (0.13) * (14.0) */
> >  > >
> >  > > > +
> >  > >  > +        /* Multiplication by 2 with rounding can cause short type
> >  > >  > +           overflow, thus clipping is required. */
> >  > >  > +
> >  > >  > +        out[i] = av_clip_int16((hpf_f[0] + 0x800) >> 12);      /* (15.0) = 2 * (13.13) = (14.13) */
> >  > >  > +
> >  > >  > +        memmove(hpf_f + 1, hpf_f, 2 * sizeof(hpf_f[0]));
> >  > >  > +    }
> >  > >
> >  > >
> >  > >  t =  MULL(hpf_f[0], 15836);                     /* (14.13) = (13.13) * (1.13) */
> >  > >    + MULL(hpf_f[1], -7667);                     /* (13.13) = (13.13) * (0.13) */
> >  > >    + 7699 * (in[i] - 2*in[i-1] + in[i-2]);      /* (14.13) =  (0.13) * (14.0) */
> >  > >
> >  > >  out[i] = av_clip_int16((t + 0x800) >> 12);      /* (15.0) = 2 * (13.13) = (14.13) */
> >  > >
> >  > >  hpf_f[1]= hpf_f[0];
> >  > >  hpf_f[0]= t;
> >  >
> >  > This will require either two samples before start in "in" buffer, copied from
> >  > the previous subframe or
> >  
> >  yes, i thought that would be just something like
> >  memcpy(in-2, in+len-2, 2*sizeof(*in))
> >  
> >  ?
> >  
> >  If so that should be simpler than it is currently
> >  
> Current code work as following:
> 
> context
> {
>   syn_filter_data
>   post_filter_data
>   hpf_z
>   hpf_z
> }
> 
> mainloop
>   {
>    ...
> 1  syn_filter(syn_filter_data+10)
> 2  memcpy(syn_filter_dta+10, syn_filter_data+subframe_size,10)
> 3  postfilter(syn_filter_data+10, postfilter_data) 
> 6  high_pass_filter(out_data,syn_filter_data+10,hpf_z,hpf_f)
> 7 }
> 
> syn_filter requires first 10 items of previous data saved just after call to it.
> 
> postfilter does not requires previous data (it uses post_filter_data as such),
> but it changes contents of syn_filter data (from 10 to the end of buffer).
> 
> high_pass_filter (in your suggestion) requires previous data in buffer,
> but buffer does not contains it already (were overwritten in line 2)
> 
> The problem is in fact that syn_filter requires unfiltered past data, while
> high_pass_filter requires them filtered with postfilter.
> 
> Moreover, since top of buffer already contains data saved for future
> syn_filter call, i cant save there
> copy of hpf_z (can't do memcpy(in,hpf_z) inside filter).

If postfilter would be writing in a "new" buffer that problem should disapear.

also one can easily chain filters so each has previous samples with few
memcpy() and little buffer space:

caAAAA
db....

c....A
dbBBBB

cCCCCA
d....B

....CA
dDDDDB

....CA
....DB

CA....
DB....


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Observe your enemies, for they first find out your faults. -- Antisthenes
-------------- 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/20080507/804243e2/attachment.pgp>



More information about the ffmpeg-devel mailing list