[FFmpeg-devel] releases and stuff

Mike Melanson mike
Wed Feb 11 06:36:19 CET 2009


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?

-- 
     -Mike Melanson




More information about the ffmpeg-devel mailing list