On Fri, 20 Dec 2024 08:37:40 -0500 "Ronald S. Bultje" <rsbul...@gmail.com> wrote: > Hi, > > On Thu, Dec 19, 2024 at 5:19 PM Michael Niedermayer <mich...@niedermayer.cc> > wrote: > > > Hi > > > > On Wed, Dec 18, 2024 at 12:48:03PM -0500, Ronald S. Bultje wrote: > > > Hi, > > > > > > On Wed, Dec 18, 2024 at 5:29 AM Niklas Haas <ffm...@haasn.xyz> wrote: > > > > > > > On Wed, 18 Dec 2024 02:32:07 +0100 Michael Niedermayer < > > > > mich...@niedermayer.cc> wrote: > > > > > Hi > > > > > > > > > > On Tue, Dec 17, 2024 at 10:31:42AM +0100, Niklas Haas wrote: > > > > > > On Tue, 17 Dec 2024 01:48:02 +0100 Michael Niedermayer < > > > > mich...@niedermayer.cc> wrote: > > > > > > > Hi > > > > > > > > > > > > > > On Mon, Dec 16, 2024 at 02:57:53PM +0100, Niklas Haas wrote: > > > > > > > > From: Niklas Haas <g...@haasn.dev> > > > > > > > > > > > > > > > > This is not a good way of generating a PAL8 output. > > > > > > > > > > > > > > of course not > > > > > > > > > > > > > > but this breaks fate and features > > > > > > > > > > > > It doesn't really break a feature because we have a better > > replacement > > > > already > > > > > > included in libavfilter, IMO. > > > > > > > > > > swscale could convert to pal8 before, it cant after the patch. > > > > > So it lost a feature and breaks users code unless iam missing > > > > > something ? > > > > > > > > It is worth pointing out that *libswscale* does not directly output > > PAL8; > > > > this rather is (and always was) handled by vf_scale. So in some sense, > > this > > > > functionality already depends on libavfilter. > > > > > > > > That said, I do agree that simply regressing existing use cases should > > not > > > > be done without some sort of mechanism for automatically invoking the > > > > proper > > > > replacement. > > > > > > > > I will retract this patch for now, then, and put the corresponding > > issue on > > > > hold. I think that a full discussion of how to handle this better will > > have > > > > to wait until we have a better dither handling inside swscale. > > > > > > > > > > I would commit it, but instead of failing, emit a warning (recommending > > to > > > use the palettegen filter instead) and continue the old behaviour (as a > > > fallback). > > > > A future libswscale could include palettegen. (which would fix this issue > > instead of requiring users to switch to a different filter that may not > > even be available in the software they are using) > > > > To start, you agree that the current swscale hack to support some form of > palette generation is inferior to palettegen, right? > > Assuming you agree with that - which is hard to argue with - don't you > agree that for now, we should at the very least inform users that - if this > is what they're doing - what they're doing is inferior > (sws-palette-generation) and that there's a superior solution in-place > already (palettegen). For commandline users, this will be a string change > in their invocation. For API users, it's a bit more work but nothing major. > I can integrate libavfilter in my application in a few minutes. I have > posted sample code on stackoverflow doing that. > > For now, this is just an informative message (at loglevel=warning) telling > our users about this superior experience. At some point in the future (this > is probably 2 years from now?), the warning turns into an error. That > provides a clear timeline for this hypothetical swscale feature to be > implemented - or not. Both would be a great improvement for the vast > majority of our users who don't read their messages from their commandline > invocations until they fail. > > I only see positives here. And the best is: all of this already exists - > right there in FFmpeg, the toolkit which we all love. We only have to > inform our users about all this greatness. You must be excited about this, > no?
It would also be fairly straightforward to expose the palettegen functionality internally inside libavfilter and then add it directly to vf_scale. This would improve the status quo without anybody having to be the wiser. While it would be nice to have better palette-based dithering directly in libswscale as well, there is some risk of unnecessarily duplicating code at best, and reinventing a worse version of libavfilter at worst. Either way, that is something to consider *after* the ongoing rewrite of the core scaling functionality. I can't help but wonder if the better long-term solution here isn't to just improve the way libavfilter auto-inserts conversion filters, such that it could automatically insert a paletteuse filter when downstream requires PAL8. > > Ronald > _______________________________________________ > 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".
