[FFmpeg-devel] releases and stuff

[Benjamin Larsson]

Michael Niedermayer wrote:
>
>>>>    
>>>>         
>>> 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.
>>     
>
> I wish you would read the 5 lines of the regression diff
> before suggesting solution to it
>
> your suggestion here of decoding and then doing a fuzzy compare
> ... we do decode and we do a compare and its result does not change
> its ONLY the encoder result that does, that is very clear from the diff
> that started this thread.
> We can disable the test yes but we cant fuzzily test the encoder easily.
>   

Ok, didn't know/understand that from reading the regression code. Then 
it's just a matter of interpretation. And the only sane way to pass or 
fail on this test is to match it to a platform(and cpu maybe) and 
compiler. Complex solution with unknown gain.

>
>   
>> 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.
>>     
>
> how hard is it to write a fixed point fourier transform? and i mean fourier
> not fast fourier
>
>
>   

The ac3 encoder already have a fixedpoint fft and mdct. We could use 
those where needed. Fixed point generation of the mdct tables should be 
easy to implement also. Would a solution with a -regtest parameter be 
acceptable ? Ie let the wma encoder init generate a sine window of 
lesser accuracy based on the command line arguments. I can send a dummy 
patch to show what I mean if it is unclear.

>> And regarding the release I'm in favor of disabling the tests.
>>     
>
> for the release adding the second checksum is the most obvious quick fix
> if the #ifdef hacks dont work ...
> this of course doesnt help svn where people without a ppc should be able to
> work on wma and update the checksums
> but if all else fails we could have 2 checksums in svn as well, its at least
> better than loosing the test or adding fuzzy race condition and uninitialized
> variable stealth bugs.
>   


MvH
Benjamin Larsson