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

[Ronald S. Bultje]

Hi,

On Thu, Dec 19, 2024 at 5:19 PM Michael Niedermayer <michael at 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 <ffmpeg at haasn.xyz> wrote:
> >
> > > On Wed, 18 Dec 2024 02:32:07 +0100 Michael Niedermayer <
> > > michael at 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 <
> > > michael at niedermayer.cc> wrote:
> > > > > > Hi
> > > > > >
> > > > > > On Mon, Dec 16, 2024 at 02:57:53PM +0100, Niklas Haas wrote:
> > > > > > > From: Niklas Haas <git at 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?

Ronald