[FFmpeg-devel] [PATCH] ALAC Encoder

[Michael Niedermayer]

On Thu, Aug 21, 2008 at 08:45:01PM -0400, Justin Ruggles wrote:
> Hi,
> 
> Michael Niedermayer wrote:
> > 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 ...
> 
> That is really interesting.  Did this happen with a variety of samples
> with different types of audio?  I have never tried an asymmetric window.
>  I did test various symmetric windows, and welch had a good overall
> speed/compression trade-off.  I will be glad to run some tests.

I did not really test asymetric windows, i just used the following with a
single sample ...

Index: alacenc.c
===================================================================
--- alacenc.c	(revision 14883)
+++ alacenc.c	(working copy)
@@ -130,7 +130,7 @@
     int shift[MAX_LPC_ORDER];
     int opt_order;
 
-    opt_order = ff_lpc_calc_coefs(&s->dspctx, s->sample_buf[ch], s->avctx->frame_size, s->min_prediction_order, s->max_prediction_order,
+    opt_order = ff_lpc_calc_coefs(&s->dspctx, s->sample_buf[ch], s->avctx->frame_size/4, s->min_prediction_order, s->max_prediction_order,
                                    ALAC_MAX_LPC_PRECISION, coefs, shift, 1, ORDER_METHOD_EST, ALAC_MAX_LPC_SHIFT, 1);
 
     s->lpc[ch].lpc_order = opt_order;


[...]

> > * more decorrelation types could be tried at higher compression_level
> 
> Do you mean testing for more intervals between left, mid, and right?

yes, exactly


> That could be interesting.  I tried something to calculate the left
> weight on a scale of 0 to 1, but it was not as good as just testing the
> 4 types and comparing the sum of residual.  Maybe something better could
> be devised instead of (or in addition to) adding more types.

i think we could first try a really large number of points between
left, mid, and right, this would give us a reference point so we would
know what is achievable if we find the best point.
Then we could try some heuristics to see how close they get to that optimum


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Observe your enemies, for they first find out your faults. -- Antisthenes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080822/17b87854/attachment.pgp>