On 2024-12-20 19:38 +0100, Michael Niedermayer wrote: > On Fri, Dec 20, 2024 at 02:56:54PM +0100, Niklas Haas wrote: > > On Fri, 20 Dec 2024 08:37:40 -0500 "Ronald S. Bultje" <rsbul...@gmail.com> > > wrote:
[...] > > > 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. > > yes > > > > > > 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. > > yes > I do think libswscale should do any image -> image convert (its kind of what > its > intended to do) > if pal8 is left out, that seems like drawing the seperation at the wrong place > to me. > also the code from libavfilter can be moved into libswscale while libavfilter > can then depend on it and continue to present it to the user as it did before > > > > > 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. > > PAL8 is tricky, encoders may benefit from similarities in palettes between > frames > for others it might not matter. So automatic insertion may require some > "intelligence" to make the best choice Adding an informative message about palettegen/paletteuse is fine IMHO. Depending on future development and decisions in sws the message can be removed *or* a deprecation added at some point in the future. Alexander _______________________________________________ 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".
