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

[Niklas Haas]

On Mon, 24 Jun 2024 16:44:33 +0200 Vittorio Giovara <vittorio.giovara at gmail.com> wrote:
> On Sun, Jun 23, 2024 at 7:57 PM James Almer <jamrial at gmail.com> wrote:
> 
> > On 6/22/2024 7:19 PM, Vittorio Giovara wrote:
> > > Needless to say I support the plan of renaming the library so that it can
> > > be inline with the other libraries names, and the use of a separate
> > header
> > > since downstream applications will need to update a lot to use the new
> > > library (or the new apis in the existing library) and/or we could
> > provide a
> > > thin conversion layer when the new lib is finalized.
> >
> > I don't quite agree with renaming it. As Michael already pointed out,
> > the av prefix wouldn't fit a scaling library nor a resampling one, as
> > they only handle one or the other.
> >
> 
> by that reasoning we should ban all subtitles from all the libraries
> 
> av is a shorthand of multimedia and many people in the industry refer to
> ffmpeg libs as "libav*" so it feels a bit odd to push for preserving an
> alternative name
> 
> 
> > There's also the precedent of avresample, which was ultimately dropped
> > in favor of swresample, so trying to replace swscale with a new avscale
> > library will be both confusing and going against what was already
> > established.
> 
> 
> it's still 4 libraries vs 2... and swr/avr is shrouded in bad history that
> is not worth bringing up
> 
> I'd understand opposing a rename just for the sake of renaming, but this is
> essentially a new library, i see no value in preserving the old naming
> scheme, if not making downstream life worse :x

There is a strong motivating reason to keep <avscale.h> (or whatever
name we decide on) and <swscale.h> inside the same *library*, which is
that they both will need to access sws' internal implementation
(ff_sws_* functions).

After a bit of further planning, the current best approach seems to be
to build the new abstraction directly on top of ff_sws_init_scale() and
ff_sws_init_input/output_funcs(), with wholly new code for dispatching
the underlying operations in the correct order.

So I am currently no longer planning on directly wrapping SwsContext at
all. I am also seeing increasingly more hurdles and less benefits to the
idea of directly re-using sws_scale_frame() for the new API.

I think that, in the interest of my own sanity, for the initial
development phase I will go forward with defining a second header file
for the new API; and then only once we've tested it and are confident
that it works as intended, we can think about re-defining sws_scale()
etc. as a wrapper on top of this new API.

> -- 
> Vittorio
> _______________________________________________
> 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".