On Mon, Jun 19, 2023 at 10:32 AM Anton Khirnov <an...@khirnov.net> wrote: > 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.
My concern was that given right now it only has a single use case that we might not have thought of other ways it may be used in the future, so using a metadata field might allow us to keep it "semi-private" until others wanted the functionality. My fear was that we wouldn't be able to reach a consensus on a new public API definition that we would be willing to support indefinitely. > > 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. I don't feel strongly about the naming. My goal was to convey that this was the original input timestamp on arrival, and not something that has been transformed, and I worry that "transport" might be a bit vague as it isn't clear whether this was on input, output, or somewhere else in the workflow. That said, pick a name that will be considered acceptable to be merged upstream, and I'll adjust the patch accordingly. Devin -- Devin Heitmueller, Senior Software Engineer LTN Global Communications o: +1 (301) 363-1001 w: https://ltnglobal.com e: devin.heitmuel...@ltnglobal.com _______________________________________________ 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".
