[FFmpeg-devel] releases and stuff

[Michael Niedermayer]

On Wed, Feb 11, 2009 at 09:52:00AM +0100, Benjamin Larsson wrote:
> 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.

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.


> 
> 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


> 
> 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.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I wish the Xiph folks would stop pretending they've got something they
do not.  Somehow I fear this will remain a wish. -- M?ns Rullg?rd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090211/786b9921/attachment.pgp>