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

[Paul B Mahol]

On 7/20/19, Ulf Zibis <Ulf.Zibis at cosoco.de> wrote:
>
> 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)?

That is good idea, also provide same function but with 3rd parameter
which will set likeness amount. This is rather trivial to code.

>
> -Ulf
>
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".