[FFmpeg-devel] [PATCH] ALAC Encoder

[Baptiste Coudurier]

Hi,

Michael Niedermayer wrote:
> 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
> 

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