[FFmpeg-devel] [PATCH] ALAC Encoder
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.
More information about the ffmpeg-devel