[FFmpeg-devel] releases and stuff
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.
More information about the ffmpeg-devel