[FFmpeg-cvslog] r14698 - in trunk/libavcodec: Makefile dsputil.h fft.c i386/fft_3dn.c i386/fft_3dn2.c i386/fft_mmx.asm i386/fft_sse.c

[Michael Niedermayer]

On Thu, Aug 14, 2008 at 12:40:57AM +0200, Michael Niedermayer wrote:
> On Wed, Aug 13, 2008 at 01:15:27AM -0600, Loren Merritt wrote:
> > On Tue, 12 Aug 2008, Mike Melanson wrote:
> > >> Author: lorenm
> > >> Date: Tue Aug 12 02:26:58 2008
> > >> New Revision: 14698
> > >>
> > >> Log:
> > >> split-radix FFT
> > >> c is 1.9x faster than previous c (on various x86 cpus), sse is 1.6x faster than previous sse.
> > >
> > > This change broke the WMA v1 encoding test on the following configurations:
> > >
> > > x86_32 / gcc 4.3.1
> > > x86_32 / gcc 4.4.0-SVN
> > >
> > > The failure looks like this:
> > >
> > > diff -u -w "/home/melanson/fate/source"/tests/ffmpeg.regression.ref
> > > tests/data/vsynth.regression
> > > --- /home/melanson/fate/source/tests/ffmpeg.regression.ref
> > > 2008-08-08 16:34:02.000000000 -0700
> > > +++ tests/data/vsynth.regression        2008-08-12 18:48:02.000000000
> > > -0700
> > > @@ -205,7 +205,7 @@
> > >  353368 ./tests/data/a-flac.flac
> > >  95e54b261530a1bcf6de6fe3b21dc5f6 *./tests/data/flac.vsynth.out.wav
> > >  stddev:    0.00 PSNR:999.99 bytes:  1058444/  1058444
> > > -4435d87463cd6c5407bd88cca241ca56 *./tests/data/a-wmav1.asf
> > > +6f7f3116b801ea641ce14f827de05cce *./tests/data/a-wmav1.asf
> > >  106004 ./tests/data/a-wmav1.asf
> > >  stddev:12251.38 PSNR: 14.56 bytes:  1056812/  1058444
> > >  stddev: 2105.96 PSNR: 29.85 bytes:  1048620/  1058444
> > > make: *** [codectest] Error 1
> > 
> > I have no idea what's special about those configurations. For that matter, 
> > why didn't all the other mdct codecs and all the other configurations 
> > change? 
> 
> > And how could anyone expect md5 matches for floating-point codecs?
> 
> wasnt expected, it just happened to work out by luck well enough to be
> useable as a regression test

replacing float functions like the fft/mdct by a identity function if
CODEC_FLAG_BITEXACT is set would be welcome.

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

If you really think that XML is the answer, then you definitly missunderstood
the question -- Attila Kinali
-------------- 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-cvslog/attachments/20080814/65ea9a94/attachment.pgp>