On Mon, May 4, 2020 at 3:39 PM Michael Niedermayer <mich...@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 > <mich...@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. _______________________________________________ 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".
