[FFmpeg-cvslog] r14692 - in trunk: libavcodec/pcm.c tests/regression.sh

[Mike Melanson]

pross at xvid.org wrote:
> On Mon, Aug 11, 2008 at 06:58:23AM -0700, Mike Melanson wrote:
>> pross wrote:
>>> Author: pross
>>> Date: Mon Aug 11 11:52:17 2008
>>> New Revision: 14692
>>>
>>> Log:
>>> Apply PCM ENCODE/DECODE() macros to the S/U,8/24/32,LE/BE PCM codecs.
>>>
>>>
>>> Modified:
>>>    trunk/libavcodec/pcm.c
>>>    trunk/tests/regression.sh
>> This altered the results of 5 different FATE test specs. Is that expected?
> 
> If you are using 'crc' or 'frame' crc to validate the output, then Yes, the
> calculated CRC will be different for PCM U,U,8/24/32,LE,BE PCM codecs. The
> reason: libavcodec now stores audio samples in the optimal immediate format
> (8-bit,16-bit,32-bit,float), whereas previously it just used shorts.
> 
> The crc and framecrc work on the intermediate samples, hence the FATE results.
> If your test cases were 'md5sum a transcoded wave file' then the md5sums
> would be identical.

This explanation does not match what I am seeing. Not all of the 
unsigned PCM tests broke. E.g., qt-rawpcm-8bit-mono-unsigned broke:

   http://fate.multimedia.cx/index.php?test_spec=64

But for some reason, qt-rawpcm-8bit-stereo-unsigned is still the same:

   http://fate.multimedia.cx/index.php?test_spec=74

These are both of the 'md5sum a transcoded wave file' variety.

-- 
	-Mike Melanson