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

[Kieran Kunhya <kierank@obe.tv>]

On Sat, 14 Oct 2023, 18:00 Michael Niedermayer, <michael@niedermayer.cc>
wrote:

> 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.
>

Come on, there's no need to be facetious. Change the PIX_FMT to a the same
sampling but a different packing and you a get totally different codepath,
sometimes just decides to use C. Likewise with any of the lightly
documented flags, you can have drastic changes in speed and quality unless
you pre-test all the code paths.


> 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.
>

Covered in here: https://trac.ffmpeg.org/wiki/swscale

Yuv422p10 to yuv420p10 has forced and useless and CPU costly scaling of the
luma channel with 32 bit intermediates last time I looked. All to be
shifted back to the original values.



>
>
> >
> > 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.
>

I'm pretty sure you don't need to understand self-modifying code to write a
scaler.

The rest is covered here:
https://trac.ffmpeg.org/wiki/swscale


> 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.
>

Nicer code can be understood by more than one person.

Let's be honest you would block any attempt to even start removing cruft in
swscale like mmx, self-modifying code etc.


> 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
>

Hmmm, building a simple thing for something and then "stuff being added",
that sounds like the arguments a few of us have been making in another
thread.

Regards,
Kieran Kunhya



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