On 7/20/19, Ulf Zibis <ulf.zi...@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@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". _______________________________________________ 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".