On Wed, May 6, 2020 at 7:03 AM Michael Niedermayer <mich...@niedermayer.cc> wrote:
> On Mon, May 04, 2020 at 04:06:56PM -0700, Dale Curtis wrote: > > 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, > > yes because it was messed up from linebreaks which made both variants > unreadable > Sorry, here's it in pastebin: https://pastebin.com/raw/p1VyuktF > > > > 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. > > yes, i didnt mean to ask you to implement that > in fact iam happy to implement it, it just seems recently i always have > more > things i want to work on than what i actually succeed finding time for > so i ended up throwing the idea onto the mailing list, and if noone does > implement > it before i find time, then ill probably do it > I understand completely :) Thanks for clarifying. > > > > > > 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 > > yes > sgtm then. _______________________________________________ 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".
