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

Hendrik Leppkes h.leppkes at gmail.com
Sat Jul 20 01:37:12 EEST 2019


On Sat, Jul 20, 2019 at 12:06 AM Ulf Zibis <Ulf.Zibis at cosoco.de> wrote:
>
>
> Am 19.07.19 um 22:46 schrieb Hendrik Leppkes:
> > This has absolutely nothing to do with "rounding", since there is no
> > rounding being performed, but all to do with that floating point
> > arithmetic is just always inaccurate.
>
> Floating point representation and arithmetic *is* "aproximating
> (=rounding) a real (and here a rational, wich is a subset of real)
> value", see 1st paragraph here:
> https://en.wikipedia.org/wiki/Floating-point_arithmetic
>
>
> > What this comes down to is this:
> >
> > a) 130560 / 12800
> > b) 130560 * (1 / 12800)
> >
> > There is no rounding there, since everything is kept in full double
> > precision. But anyone working with doubles should know that they are
> > inherently inaccurate.
> > Instead of re-ordering the floating point math to somehow give you a
> > slightly more favorable result, maybe there should be actual rounding
> > to something reasonable when its evaluating the conditions, so that
> > such inaccuracies just don't matter in the first place?
> $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.

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.

- Hendrik


More information about the ffmpeg-devel mailing list