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

[Michael Niedermayer]

On Sun, Apr 27, 2008 at 01:05:32AM +0700, Vladimir Voroshilov wrote:
> On Sun, Apr 27, 2008 at 12:41 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
> > On Sat, Apr 26, 2008 at 11:11:56PM +0700, Vladimir Voroshilov wrote:
> >
> > > On Fri, Apr 25, 2008 at 6:16 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> >  >
> >  > [...]
> >  >
> >  > >  Yes thats also what i thought at first but vladimirs insistance made
> >  > >  me belive that the output of this function would be the final audio
> >  > >  samples returned from "decode_audio". In which cases one of course
> >  > >  cannot have 10 samples before it.
> >  > >  Now after looking at the actual code its clear that there are always
> >  > >  some other filters applied afterwards. So i agree, none of this makes
> >  > >  sense, no double writing, no special case for the first "10" samples
> >  > >  nor a memcpy() should be needed. Except a memcpy to move the first
> >  > >  "10" samples to the buffer start.
> >  >
> >  > To tell the truth i didn't understand should i fix patch somehow or
> >  > not according to above.
> >
> >  ff_acelp_lp_synthesis_filter_inplace() is exactly what we need,
> >  ff_acelp_lp_synthesis_filter() is unneeded, please remove it.
> >
> >
> >
> >  >
> >  > After splitting ff_acelp_lp_synthesis_filter, one of routines still
> >  > requires additional 10 items in filter data. It is possible to avoid
> >  > such requirement in cost of additional 20 bytes long memcpy.
> >  > But i don't know will this improve something or not.
> >
> >  Only a single memcpy() of 10 elements is needed.
> >
> >  memcpy(buf, buf+N, 10);
> >  overflow= acelp_lp_synthesis_filter(buf+10, input, N);
> >  if(overflow){
> >     for(i=0; i<N; i++)
> >         input[i]>>=123;
> >     acelp_lp_synthesis_filter(buf+10, input, N);
> >  }
> 
> buf is subframe_size+10 long as i see.
> And this will require copy from buf to output_data
> (explicit via memcpy or implicit, e.g. high-pass filter should put
> data directly to output_data instead of it's input buffer)
> Second is preferred, right?

yes


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

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- 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/20080426/9d744ae9/attachment.pgp>