[FFmpeg-cvslog] fate: only check stddev for acodec-ra144

Reimar Döffinger Reimar.Doeffinger at gmx.de
Fri Jun 1 18:40:31 CEST 2012


On Fri, Jun 01, 2012 at 06:26:13PM +0200, Michael Niedermayer wrote:
> On Fri, Jun 01, 2012 at 05:59:04PM +0200, Reimar Döffinger wrote:
> > On Fri, Jun 01, 2012 at 12:20:25PM +0200, Michael Niedermayer wrote:
> > > ffmpeg | branch: master | Michael Niedermayer <michaelni at gmx.at> | Thu May 31 03:08:56 2012 +0200| [e6866b1c6702aee5b696c5a49c20edb136e0427c] | committer: Michael Niedermayer
> > > 
> > > fate: only check stddev for acodec-ra144
> > > 
> > > ra144 uses floats so bitexactness cannot be guranteed
> > > This should fix a long standing issue with icc
> > 
> > Not to complain, but did you investigate?
> > The fact that all other compilers, and even ARM, x86, x86_64 using SSE,
> > PPC,... all give exactly the same result made me suspect that there
> > is actually something at least strange but possibly wrong either
> > with ICC or with the code.
> 
> the PSNR value stays the same with the printed precission
> the stddev value changes by 0.004% the MAXDIFF stayed the same
> and so did the length

Yes, I saw that before.

> and IIRC icc is able to do some advanced float optimizations which
> are enabled by default
> above feels like consistently pointing to a minor float optimization
> difference.

Or a big breakage in a case that didn't really matter much to the
encoder. It just seems strange that any of those "advanced float
optimizations" should make more of a difference than 80 bit x86 vs.
32 bit ARM float for example.
This is even more relevant since we don't use -ffast-math (not even
the less problematic sub-options of it) with gcc so there might be
a bit of a question how much of the code was written/tested to handle
that kind of optimization.
Though maybe we should just enable gcc options like -fno-trapping-math
-funsafe-math-optimizations and -fno-math-errno instead.


More information about the ffmpeg-cvslog mailing list