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

Hendrik Leppkes h.leppkes at gmail.com
Fri Jul 19 23:46:54 EEST 2019


On Fri, Jul 19, 2019 at 7:44 PM Ulf Zibis <Ulf.Zibis at cosoco.de> wrote:
>
>
> Am 19.07.19 um 19:23 schrieb Nicolas George:
> > Ulf Zibis (12019-07-19):
> >> So please give an alternative theory than a rounding issue, why I
> >> actually experience a different result.
> > Code with doubles is very fragile, changing anything in the structure of
> > your formula will give slightly different results. You were just lucky
> > that this change made your use case work.
>
> May be, but I believe single rounding over twice rounding is less fragile.
>
> If I see right, the expression evaluation in libavutil/eval.c only
> rounds once, so the chance of equal results against one rounding in
> filter select should be higher.
>
> >> In the current code there is a 1st rounding with "(double)(time_base.nom
> >> / time_base.den)" and then a 2nd with multipliying this value with
> >> "frame->pts". In my code there is only 1 rounding after division of
> >> (int64_t)(frame->pts * time_base.nom) with "(double)time_base.den".
> > There is no rounding, all is done in double.
> Try this:
>     printf("single rounding: %.40f\n", 130560LL * 1 / (double)12800);
>     printf("twice rounding:  %.40f\n", 130560LL * (double)(1 /
> (double)12800));
> Result:
> single rounding: 10.1999999999999992894572642398998141288757
> twice rounding:  10.2000000000000010658141036401502788066864


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.
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?

- Hendrik


More information about the ffmpeg-devel mailing list