[FFmpeg-devel] [PATCH] avfilter/vf_scale: remove systematic PAL8 hack

[Alexander Strasser]

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" <rsbultje at 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