[FFmpeg-devel] [PATCH] ALAC Encoder
Sat Aug 23 18:42:05 CEST 2008
Michael Niedermayer wrote:
> On Fri, Aug 22, 2008 at 03:09:07AM +0200, Vitor Sessak wrote:
>> Justin Ruggles wrote:
>>> 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
Yes, btw it seems psnr is broken/not accurate for everything else than
yuv420p but that's another problem I was looking at.
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
Smartjog USA Inc. http://www.smartjog.com
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
More information about the ffmpeg-devel