On Sat, 22 Jun 2024 15:23:22 +0100 Andrew Sayers <ffmpeg-de...@pileofstuff.org> wrote: > On Sat, Jun 22, 2024 at 03:13:34PM +0200, Niklas Haas wrote: > [...] > > > > ## Comments / feedback? > > > > Does the above approach seem reasonable? How do people feel about > > introducing > > a new API vs. trying to hammer the existing API into the shape I want it to > > be? > > > > I've attached an example of what <avscale.h> could end up looking like. If > > there is broad agreement on this design, I will move on to an > > implementation. > > API users seem to have difficulty with this type of big change[[1], > and doing the interface before the implementation means there's less > reason for developers to switch while you're still looking for feedback. > > What's the plan to bring them along?
Since SwsContext is entirely internal, we can continue providing the current API on top of whatever internal abstractions we arrive at. As a trivial example, sws_scale() can construct a temporary AVFrame based on the provided information, and simply pass that to avscale_frame(). So I don't think legacy API users are at risk, or pressure to switch, unless they want access to *new* functionality. For that, the harder step is moving from sws_scale() to sws_scale_frame(). This is something API users can *already* do. By contrast, moving from sws_scale_frame() to avscale_frame() should hopefully be simple, since it just requires making sure the AVFrame is correctly tagged. Usually, the flow is in the opposite direction - users receive a correctly tagged AVFrame and manually forward this information to the SwsContext. So, most of the time, moving to a fully AVFrame-based API will result in deleting code, rather than adding it. If we wanted to maximize the transition comfort, we should consider re-using the sws_scale_frame() entrypoint directly. The main reason I am hesitant to do this is because sws_scale_frame() is currently tied to the stateful configuration of SwsContext, and mostly ignores the AVFrame metadata. While changing that is possible, it possibly presents a bigger API break than simply introducing a new function. > > [1] https://ffmpeg.org/pipermail/ffmpeg-devel/2024-June/328852.html > _______________________________________________ > 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". _______________________________________________ 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".
