[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