[FFmpeg-devel] [PATCH] [libavutil] Add saturated add/sub operations for int64_t.

[Dale Curtis]

On Mon, May 4, 2020 at 3:39 PM Michael Niedermayer <michael at niedermayer.cc>
wrote:

> On Mon, May 04, 2020 at 02:19:47PM -0700, Dale Curtis wrote:
> > On Mon, May 4, 2020 at 1:48 PM Michael Niedermayer
> <michael at niedermayer.cc>
> [...]
>

You snipped out the example I provided, but did you have an opinion on
which approach looked best there? I think the concept of an "eint" type is
interesting, but is a project wide change that's a bit beyond what I can
commit to.

> Are you just proposing sentinel values for those extensions? E.g., +inf =
> > INT64_MAX, -inf=-INT64_MAX, nan=INT64_MIN?
>
> yes
>

Okay. Having an "eint" type for timestamps seems reasonable. Some sort of
"AVTimestamp" type perhaps with a new class of arithmetic to handle
operations to it. This would be similar to how we handle time in Chromium:
https://source.chromium.org/chromium/chromium/src/+/master:base/time/time.h;l=119



> That all said, this leaves many question open. which may be interresting
> to awnser.
> A. how much time in % do we actually spend in timestamp computations which
>    would need checks, saturation or other ?
> B. how much actual performance difference is there for the different
>    possible options
> C. in the cases which affect performance most, can we avoid the
> computations
>    alltogether ?
>    very very small constant sized audio packets come to mind, the obvious
> idea would be
>    to group them in bigger chunks. That would likely gain more than any
>    difference between anything done by these checks
>
> not saying you should awnser any of these questions, these are more meant
> in
> a general sense related to the subject
>

Sorry I didn't mean to derail into a performance discussion. I agree,
generally I don't think performance will change much. Timestamp
calculations are probably not on any critical paths.