[FFmpeg-devel] [PATCH] Move lpc utility code from flacenc.c to lpc.{c|h}

Ramiro Polla ramiro.polla
Fri Aug 15 14:08:37 CEST 2008


Hi,

On Fri, Aug 15, 2008 at 8:26 AM, Jai Menon <realityman at gmx.net> wrote:
> Hi,
>
> On Friday 15 Aug 2008 4:44:35 pm Michael Niedermayer wrote:
>> On Fri, Aug 15, 2008 at 03:07:12PM +0530, Jai Menon wrote:
>> > Hi,
>> >
>> > On Friday 15 Aug 2008 2:58:15 pm Ramiro Polla wrote:
>> > > Hi,
>> > >
>> > > On Fri, Aug 15, 2008 at 3:14 AM, Jai Menon <realityman at gmx.net> wrote:
>> > > > Attached patch moves a few functions from the flac encoder so that it
>> > > > can be shared by the alac encoder.
>> > >
>> > > For MLP I used the entire lpc_calc_coefs(). Is that not ok for alac?
>> >
>> > No, currently the order estimation does not require such extensive code.
>> > It doesn't really help with compression or speed. A simpler approach is
>> > used instead.
>>
>> please also use lpc_calc_coefs()
>>
>
> Its just that for the first iteration of the encoder which I hope will end up
> in FFmpeg-svn, I'm planning to keep the order selection simple. The
> approach(in so-svn) gives pretty good compression (better than dbpoweramp
> always, slightly lesser than itunes). We just need to quantize either 4th or
> 6th order lpc coeffs. If I use the stock lpc_calc_coeffs, I'll have to make
> use of the EST method which will quantize all coeffs upto 6th order.

You "have to", as in there's no possible way around?

> This
> ends up being suboptimal. I didn't reuse lpc_calc_coefs because the speed
> tradeoff is significant.

Wouldn't it be best to change lpc_calc_coefs() to take this into account?

Ramiro Polla




More information about the ffmpeg-devel mailing list