[FFmpeg-devel] [PATCH] correct make test failure from 15261 release until now (15899)

[Vitor Sessak]

Michael Niedermayer wrote:
> On Fri, Nov 21, 2008 at 09:15:30PM +0100, Vitor Sessak wrote:
>> David Geldreich wrote:
>>> Hello Guillaume,
>>>
>>> Le 21 nov. 08 ? 17:25, Guillaume POIRIER a ?crit :
>>>
>>>> This is not the way to go. Reg tests pass on AMD64/Linux, so the code
>>>> must be fixed to work the same on any plateform. The md5sum should not
>>>> match X plateform results, but all plateforms result.
>>> That's why I made another post to tell to ignore my proposed patch.
>>>
>>> I found no way of making sin/sinf works the same way on all the  
>>> platform. In my case, OSX ppc and intel gives different results.
>>>
>>> So changes r15261 and r14982 are incomplete ... they correct the  
>>> problem for AMD64 but breaks in on Intel32.
>>>
>>> We must iterate to find a "stable" sine window generating function.
>> Even if we find a way to generate a sine window in an arch-independent 
>> way, the codec still uses floating points in other places, so if it ever 
>> is bit-identical across PPC and I32, I don't see any reason not to see a 
>> different output when testing on ARM or SH or GCC 6.4 or whatever we'll 
>> encounter in future. Unless someone tells me why it is supposed to work 
>> as is, I think that this test should be removed...
> 
> ratecontrol in video uses floats, and other parts do too, we arent seeing
> problems with these and arent disabling them
> 
> If you argue that the wma test should be disabled because it is not
> matching between some important systems, thats something i can understand
> 
> but, arguing that itz should be disabled because it might theoretically not
> work on some architecture or not yet existing compiler is well ...

Ok, I didn't made myself clear. It is not just that it might 
theoretically not work, but I see no reason it is more likely to work 
than not in a completely valid system, and I don't find this acceptable. 
The case of ratecontrol is different because it never gave us problem, 
and so it is more likely than not to remain this way.

-Vitor