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

[Justin Ruggles]

Justin Ruggles wrote:
> 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.

patch attached implementing the above.

Although there is not an "all-in-one" function, I think this is a
cleaner and more flexible solution.

-Justin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: split_lpc_functions.diff
Type: text/x-patch
Size: 6561 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080816/cb4e46c3/attachment.bin>