Quoting Kieran Kunhya (2023-10-14 16:19:49) > 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 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 _______________________________________________ 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".
