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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
