[FFmpeg-devel] [PATCH v1] filter select - avoid 2 times rounding

[Ulf Zibis]

Am 20.07.19 um 00:37 schrieb Hendrik Leppkes:
>> $1 The captain is always right.
>>
>> $2 If the captain fails, see $1.
>>
>> 0 against 327 fails in 2500 frames is a "slightly more favorable
>> result". See my last post from 22:23 CEST.
>>
> The entire point is that your change is not a fix, its a bandaid at best.
I never have talked about a fix. What is the drawback of implementing
such a bandaid?

> The behavior will still depend on many outside factors, like the
> platform, if SSE or x87 FP math is being used, if fast or precise FP
> mode is used by the compiler, and who knows what - because you are
> expecting an equals comparison on a floating point value stemming from
> a division to be true, which will just fail sometimes if one doesn't
> round intentionally to get rid of the inaccuracy introduced by the
> calculation itself.
This is all correct. (the part about intentional rounding I don't
understand, may please give an example)

But keep in mind, that both calculations, the parsing from a string to a
double floating point and the transform oft an integer pts to a double
floating point value happen on the same machine with the same SSE and
x87 FP math and binaries from the same build with the same compiler
mode, so equality of both results is very very likely when doing only
exactly 1 approximation step on both sides.

The point is, that with e.g "10.2" the user is seeing a fixed point
value (= 10,200 ms) which is equivalent to an exact rational value, and
moreover FFmpeg claims to calculate with exact rationals where even
possible. So how should a user come to the idea, that "10.2" becomes
internally corrupted by "stupid" floating point
representation/conversion, and additionally in light of an exact time
base rational representation as e.g. 1/12800 s.
>From my point of view it was a half-baked or "lousy" idea to internally
base all values of the select filter on a common double float array
instead on a multityped struct, so honouring that, my patch is indeed a
bandaid, but IMHO really helpful.

If FFmpeg engineers still want to persevere on the "just always
inaccurate" FP representation, why don't they provide a convenient
like(x, y) expression besides eq(x, y)?

-Ulf