[FFmpeg-devel] releases and stuff
Benjamin Larsson
banan
Wed Feb 11 14:51:43 CET 2009
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
More information about the ffmpeg-devel
mailing list