[FFmpeg-devel] [PATCH] ALAC Encoder

Jai Menon realityman
Thu Aug 21 16:53:09 CEST 2008


On Thursday 21 Aug 2008 7:46:57 pm Michael Niedermayer wrote:
> On Tue, Aug 19, 2008 at 10:41:17PM +0530, Jai Menon wrote:
> > Hi,
> >
> > On Tuesday 19 Aug 2008 9:45:41 pm Michael Niedermayer wrote:
> [...]
> > > patch ok
> >
> > And applied...
> >
> >
> > Thanks for the reviews!
> no problem
> anyway, some further ideas:
> * as ALAC dynamically adapts the LPC coeffs its not optimal to calculate
>   the best ones for the whole block with equal weighting for each sample.
>   for example if i simply just calculate them based on the first 1/4 of
>   the block, compression (and speed) improves.
>   That surely is an area that should be investigated, maybe using some
>   asymetric and at the right side exponentially decaying window instead
>   of the welch window ...

Infact, one of the first things I discussed with Justin was on some of the 
other windowing approaches which could be tried out. I'll definitely look 
into this after some other stuff I've planned (see below :-) )

> * regression tests, ive totally forgotten about them, but each new encoder
>   should be added to them, i think alac hasnt been yet ...

Will do in a short while.

> * more decorrelation types could be tried at higher compression_level
> * rice_modifier
>   ive missed this parameter totally because it is not used in the encoder
>   but instead just replaced by a litteral number where its used.
>   This should also be fine tuned for each frame

The first improvement I'm working on is some approach to predict or estimate 
entropy coded data size. This should allow for better compression compared to 
the reflection coefficient thing.

Next up, we should have some strategy to adapt the rice params. Currently, we 
are following the crowd by using those hardcoded params. Maybe we could 
analyze the first few frames using some heuristic and compute these in an 
optimal manner. Then again, these should be present in the extradata...

When most of this stuff is done, we could play around with the rice_modifier 
but at this point I'm not sure exactly what we could expect.

Apologies if I'm being vague with some of the later points. My current focus 
is to have an optimal order selection based on estimating the coded size in 
some way. Hopefully, this should happen within this weekend.


Jai Menon

More information about the ffmpeg-devel mailing list