[FFmpeg-devel] FATE breaks with latest pull

[Ganesh Ajjanagadde]

On Sat, Jan 23, 2016 at 5:44 PM, Michael Niedermayer
<michael at niedermayer.cc> wrote:
> On Sat, Jan 23, 2016 at 12:13:57PM +0530, Ganesh Ajjanagadde wrote:
>> On Sat, Jan 23, 2016 at 11:55 AM, Mats Peterson
>> <matsp888-at-yahoo.com at ffmpeg.org> wrote:
>> > +++ tests/data/fate/ffmpeg-filter_colorkey      2016-01-23
>> > 07:22:58.904430959 +0100
>> > @@ -1,16 +0,0 @@
>> > -#tb 0: 1/25
>> > -#tb 1: 1/48000
>> > -0,          0,          0,        1,   622080, 0x4e30accb
>> > -1,          0,          0,     1152,     4608, 0x00000000
>> > -1,       1152,       1152,     1152,     4608, 0xbca29063
>> > -0,          1,          1,        1,   622080, 0x7d941c14
>> > -1,       2304,       2304,     1152,     4608, 0x6e70df10
>> > -1,       3456,       3456,     1152,     4608, 0x95e6a535
>> > -0,          2,          2,        1,   622080, 0xf7451c5b
>> > -0,          3,          3,        1,   622080, 0xb2c74319
>> > -0,          4,          4,        1,   622080, 0xc9b80b79
>> > -0,          5,          5,        1,   622080, 0x92ce1194
>> > -0,          6,          6,        1,   622080, 0x43ae99ac
>> > -0,          7,          7,        1,   622080, 0x4ec3a554
>> > -0,          8,          8,        1,   622080, 0x3200250c
>> > -0,          9,          9,        1,   622080, 0x94ebb3f3
>> > Test ffmpeg-filter_colorkey failed. Look at
>> > tests/data/fate/ffmpeg-filter_colorkey.err for details.
>>
>> I was also not too happy with the message in the cvslog at a glance,
>> but let it slide as FATE still passed on my configs. The problem is
>> that it is very sensitive to libm differences, e.g the quality of the
>> sqrt. For example, I wanted to experiment with replacing sqrt by sqrtf
>> in lavfi/vf_colorkey, but it breaks the test on my machine.
>
> you can update the checksum if you change the implementation
> it just must produce the same value on each platform
> (which is desirable with or without fate test)
>
> also avoiding floats and doubles entirely would be better
>
> one use can trivially be removed:
> sqrt(whatever) > constant -> whatever > constant^2

The problem is the blend parameter, forcing fpu usage at some point AFAIK.

Regardless, less reliance on libm and sticking closer to raw floating
point operations is a good idea, since they tend to follow IEEE-754
semantics. Some time I will try fixing this cleanly, thanks.

>
> also the 255.0 stuff looks like it can be factored out
>
> [...]
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> It is what and why we do it that matters, not just one of them.
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>