[FFmpeg-devel] releases and stuff

[Benjamin Larsson]

Mike Melanson wrote:
> Diego Biurrun wrote:
>   
>> On Tue, Feb 10, 2009 at 06:14:54PM +0100, Vitor Sessak wrote:
>>     
>>> Benjamin Larsson wrote:
>>>       
>>>> Diego Biurrun wrote:
>>>>         
>>>>> On Tue, Feb 10, 2009 at 03:56:47PM +0100, Diego Biurrun wrote:
>>>>>   
>>>>>           
>>>>>> On Tue, Feb 10, 2009 at 01:17:07PM +0100, Dominik 'Rathann' Mierzejewski wrote:
>>>>>>     
>>>>>>             
>>>>>>> On Tuesday, 10 February 2009 at 00:32, Carl Eugen Hoyos wrote:
>>>>>>>       
>>>>>>>               
>>>>>>>> Roman V. Shaposhnik <rvs <at> sun.com> writes:
>>>>>>>>
>>>>>>>>                 
>>>>>>>>> -4435d87463cd6c5407bd88cca241ca56 *./tests/data/a-wmav1.asf
>>>>>>>>> +6f7f3116b801ea641ce14f827de05cce *./tests/data/a-wmav1.asf
>>>>>>>>>           
>>>>>>>>>                   
>>>>>>>> I remember posting an incredibly beautiful patch to fix it, fortunately I can't
>>>>>>>> find it now;-)
>>>>>>>>         
>>>>>>>>                 
>>>>>>> This?
>>>>>>>
>>>>>>> Date: Sat, 22 Nov 2008 13:42:11 +0100
>>>>>>> Subject: Re: [FFmpeg-devel] [PATCH] correct make test failure from 15261
>>>>>>>  releaseuntil now (15899)
>>>>>>>       
>>>>>>>               
>>>>>> Here is the patch from Carl Eugen, it does indeed fix the WMA regression
>>>>>> tests on PPC.  Is this acceptable?  Acceptable minus the commented-out
>>>>>> code I mean.
>>>>>>             
>>>> I strongly object. Doing regressions tests on float code is bound to 
>>>> trigger these things.
>>>>         
>>> I don't like this either. It'll come back over and over again every time 
>>> someone ports ffmpeg to a new arch/compiler/gcc major ver. I think that 
>>> the only clean way to do it is to use some Makefile/configure machinery 
>>> to run this test only in the systems it is supposed to work.
>>>       
>> I'm currently tempted to disable the test in the release version.
>>     
>
> I'm apt to agree.
>
> What's the root of this problem? Classic floating point rounding error? 
> Can we come up with a clever approximation test that I might be able to 
> implement in FATE so I can automatically test this? I have been 
> designing ways to test non-exact data recently. Unfortunately, this only 
> applies so far to decoded data. This problem is tricky because it is 
> occurring on the encoding side.
>
> Can we dupe this algorithm with a fixed-point approximation somehow? A 
> scaled, fixed-point sine table?
>
>   

 From what I understood this is a wma encoder test. So what would be 
possible is to encode then decode to be able to use some fuzzy compare 
tool. Ie A->B->C and by verifying that A gives C you implicitly say that 
B is ok also.

Regarding fixed point tables and stuff, the fft routines might behave 
differently also. To be really sure a complete fixed point version would 
be needed.

And regarding the release I'm in favor of disabling the tests.

MvH
Benjamin Larsson