Re: [FFmpeg-devel] SWS cleanup / SPI Funding Suggestion

[Michael Niedermayer <michael@niedermayer.cc>]

[-- Attachment #1.1: Type: text/plain, Size: 3142 bytes --]

On Sat, Oct 14, 2023 at 03:19:49PM +0100, Kieran Kunhya wrote:
> On Sat, 14 Oct 2023 at 00:17, Cosmin Stejerean via ffmpeg-devel <
> ffmpeg-devel@ffmpeg.org> wrote:
> 
> >
> >
> > > On Oct 13, 2023, at 4:00 PM, Vittorio Giovara <
> > vittorio.giovara@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

randomly ?
code in general doesnt give you randomly something very different.

So, why do i complain? because swscale has real issues and needs
to be improved. And these comments point in the wrong direction


> and have no
> idea how to fix it.

If you dont know how to fix it yourself, sending me a bug report is
probably a good start.


> 
> It's probably easier to start from scratch than to try and understand and
> then fix swscale (years of work).

Well there are 2 further aspects with that.

The first one is bluntly put. If you dont understand the old code, then
you probably are not qualified to write better code.
People tend not to successfully improve things they dont understand.

The 2nd issue is, ATM, i maintain swscale. If iam involved in the new
effort and understand it either because of that or because it has some
similarity then i can continue to maintain swscale. If its totally
different and i was totally not involded then i also will not maintain
it obviously.
This is something to be especially aware of in case the cleanup/new
code would be done by someone who comes, does it and leaves. you
could end up with nicer code thats then unmaintained.

PS: whats the real issue with sws ?
it evolved out of a piece yuv->rgb converter from a video player.
It evolved from that and stuff was added into it.
This is a similar situation to why ffmpeg.c needed cleanup

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship: All citizens are under surveillance, all their steps and
actions recorded, for the politicians to enforce control.
Democracy: All politicians are under surveillance, all their steps and
actions recorded, for the citizens to enforce control.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".