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

[Justin Ruggles]

Michael Niedermayer wrote:
> 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 ...

ORDER_METHOD_EST was tuned for FLAC, so it may not be good for other codecs.

I think it might be cleaner to share quantize_lpc_coefs() separately.

ff_lpc_calc_coefs() would do either levinson-durbin or cholesky
depending on avctx->use_lpc, and it would output lpc and reflection
coeffs as doubles.

ff_lpc_quantize_coefs() could be a function which quantizes coeffs for a
range of orders.

estimate_best_order() could be shared separately as well if it proves
useful for other codecs.

This way codecs which just want the coeffs could do their own
quantization or order decision.  MP4-ALS, for example, quantizes the
reflection coeffs and has a bit-exact transformation in the spec to
convert to integer lpc coeffs.

Eventually I want to be able to share the other order estimation methods
which are still in flacenc.c.  There will probably need to be a function
pointer to calculate the number of bits needed to encode the frame with
a specific lpc order.  Right now that is FLAC-specific.  Jai is working
on a way to estimate it for ALAC.

-Justin