Quoting Devin Heitmueller (2023-06-19 15:14:38) > Hi Andreas, > > Thanks for the feedback. I put out an RFC back in March but got no comments. > > On Fri, Jun 16, 2023 at 6:01 PM Andreas Rheinhardt > <andreas.rheinha...@outlook.com> wrote: > > A timestamp without a timebase? Doesn't sound good to me. And it also > > seems quite hacky. > > Apart from that: It needs to specify that the data is a int64_t. > > So you're suggesting a struct that contains both the timestamp and a > timebase? I don't have any real objection to this. > > I agree it seems hacky, but don't have a better solution. I welcome > constructive suggestions. I had considered using an AVPacket metadata > field rather than a new side data type (as that won't necessarily lock > us into a new side data type that we would have to support),
This reasoning is backwards IMO. You'd be creating an implicit API while pretending not to. If anyone uses it, they would expect stability, otherwise what's the point. > functionality is really specific to one use case. However I figured > side data might be better since it avoids the conversion of the PTS to > a string and back. One one hand it does feel hacky, on the other I can see valid uses for it. Though 'orig' is rather vague, I'd call it something like 'transport timestamp' instead. A timebase should definitely be bundled with it. -- Anton Khirnov _______________________________________________ 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".
