[FFmpeg-devel] [PATCH] ALAC Encoder

[Michael Niedermayer]

On Fri, Aug 22, 2008 at 03:09:07AM +0200, Vitor Sessak wrote:
> 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.
> > 
> >> * regression tests, ive totally forgotten about them, but each new encoder
> >>   should be added to them, i think alac hasnt been yet ...
> > 
> > Jai, it would probably be good to use the 1st order prediction for the
> > regression test to avoid floating-point.
> 
> I'd like to protest against the idea of checking the md5sum of the 
> generated alac files. It has the following downfalls:
> 
> 1- Cannot check any code that uses floating-point

> 2- Breaks when a change that improves compression is made

that is a feature
The regression tests are there to detect changes, any changes
very minor changes can and _DID_ happen due to various bugs like
uinitialized varibles. I do not want to hide these

People have occasionally claimed that they would be working on a encoder
or decoder a lot and the many improvments they would do would be a PITA
because they would have to update the regression tests all the time.
In not a single case did these people do more than VERY few changes
that needed a change to the regression tests, the one i remember IIRC
was vorbis, iam still waiting for the improvments ...


> 3- Is of no use for the more subtle kind of regression: a change that is 
> supposed to improve compression (and hence change the md5sum) but 
> actually make it worse

did you actually read a single line of the regression tests?

here are the first 4 of  tests/rotozoom.regression.ref

73ca6f1deab02d1d67a0e8495c026a9e *./tests/data/a-mpeg1.mpg
192783 ./tests/data/a-mpeg1.mpg
56147e94b12f08df7213e610e177823d *./tests/data/mpeg.rotozoom.out.yuv
stddev:    4.95 PSNR: 34.21 bytes:  7603200/  7603200

We have there
MD5 of compressed file          file name
compressed file size
MD5 of decoder output
standard deviation and PSNR of the decoder output as well as the amount of bytes

If compression becomes worse the filesize and or PSNR values will reflect
that.

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

Frequently ignored awnser#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.
-------------- 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/f44bdb29/attachment.pgp>