[FFmpeg-devel] [RFC]] swscale modernization proposal

[Niklas Haas]

On Sat, 22 Jun 2024 15:23:22 +0100 Andrew Sayers <ffmpeg-devel at 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 at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".