[FFmpeg-devel] [PATCH] ALAC Encoder

Michael Niedermayer michaelni
Fri Aug 22 03:12:23 CEST 2008

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>

More information about the ffmpeg-devel mailing list