On Sat, 14 Oct 2023, 18:00 Michael Niedermayer, <mich...@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.giov...@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-requ...@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-requ...@ffmpeg.org with subject "unsubscribe".
