[FFmpeg-devel] [PATCH] Make ff_lpc_calc_coefs order estimation?flexible by passing parameters

[Michael Niedermayer]

On Sun, Aug 17, 2008 at 02:10:28AM +0530, Jai Menon wrote:
> Hi,
> 
> On Sunday 17 Aug 2008 1:38:51 am Michael Niedermayer wrote:
> > On Sun, Aug 17, 2008 at 01:21:52AM +0530, Jai Menon wrote:
> > > Hi,
> > >
> > > On Sunday 17 Aug 2008 12:42:33 am Jai Menon wrote:
> > > > Hi,
> > > >
> > > > On Sunday 17 Aug 2008 12:36:54 am Jai Menon wrote:
> > > > > Hi,
> > > > >
> > > > > Attached patch allows for order estimation to be varied based on
> > > > > external parameters.
> > > >
> > > > This will allow for order estimation between a specific range or
> > > > interval, particularly useful for the alac encoder.
> > >
> > > Again, based on Ramiro's advice, a more detailed incremental patchset.
> >
> > [...]
> >
> > > @@ -195,10 +195,20 @@ int ff_lpc_calc_coefs(DSPContext *s,
> > >          i = opt_order-1;
> > >          quantize_lpc_coefs(lpc[i], i+1, precision, coefs[i], &shift[i],
> > > max_shift, zero_shift); } else {
> > > +        if(omethod == ORDER_METHOD_RANGE) {
> > > +            int i = opt_order = param_list[0];
> > > +            while(i < param_list[1]) {
> > > +                if(ref[i] > ref[opt_order-1])
> > > +                    opt_order = i + 1;
> > > +                i++;
> > > +            }
> > > +            quantize_lpc_coefs(lpc[opt_order-1], opt_order, precision,
> > > coefs[opt_order-1], &shift[opt_order-1], max_shift, zero_shift); +       
> > > } else {
> > >          for(i=0; i<max_order; i++) {
> > >              quantize_lpc_coefs(lpc[i], i+1, precision, coefs[i],
> > > &shift[i], max_shift, zero_shift); }
> > >      }
> > > +    }
> > >
> > >      return opt_order;
> > >  }
> >
> > As the current omethods (If i understand the code correctly) are not
> > limiting their search range. This is a bug, and it can either be fixed or
> > left but i will not accept the addition of a new omethod because the
> > existing ones are buggy.
> >
> > Besides max_order is passed as parameter already and we do not need a
> > opaque parameter list, that is the addition of such list is rejected.
> >
> 
> So should I just hardcode the selection among 4th and 6th orders (based on 
> reflection coeffs) in a new order method solely for alac?

First please explain me again what exactly in lpc_calc_coefs is slowing your
code down when you use omethod != ORDER_METHOD_EST?

is it quantize_lpc_coefs() ?

if yes (and you really checked this instead of guessing) then
you can add a min_order and use ORDER_METHOD_2LEVEL with appropriate changes
to lpc_calc_coefs()
I just cannot belive that quantize_lpc_coefs() really makes a big difference ...

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

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle
-------------- 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/20080817/25006a35/attachment.pgp>