[FFmpeg-devel] SWS cleanup / SPI Funding Suggestion

[Anton Khirnov]

Quoting Kieran Kunhya (2023-10-14 16:19:49)
> On Sat, 14 Oct 2023 at 00:17, Cosmin Stejerean via ffmpeg-devel <
> ffmpeg-devel at ffmpeg.org> wrote:
> 
> >
> >
> > > On Oct 13, 2023, at 4:00 PM, Vittorio Giovara <
> > vittorio.giovara at gmail.com> wrote:
> > >
> > > TBF this is in part why i was suggesting a new library - I feel like sws
> > is
> > > affected by bad brading because of these caching issues and imprecise
> > > conversion, and a new clean api in a new library would make a lot of
> > sense
> > > in my opinion.
> >
> > I think the branding issue would solve itself in short order if the actual
> > implementation of swscale started to be good. My concern with adding a new
> > library is that we'd end up in a situation where we have both swscale and a
> > new library side by side for some extended period of time.
> >
> > By comparison adding cleaner APIs to swscale and then slowly strangling
> > the old APIs (along the lines of Niklas' proposal) would allow for a more
> > gradual transition that has a higher likelihood of success compared to a
> > full rewrite IMO.
> >
> 
> The issue is not the API, the issue is that swscale is astonishingly
> complex and difficult to understand internally, there are lots of different
> codepaths and randomly you'll end up with a buggy or slow one and have no
> idea how to fix it.
> 
> It's probably easier to start from scratch than to try and understand and
> then fix swscale (years of work).

I've seen more than one attempt to do that over the years, all failed.
While I do agree that sws code is atrociously bad, I think that
* an attempt to reinvent it from scratch is quite likely to fail and
  produce nothing of value
* sws can be incrementally improved

-- 
Anton Khirnov