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

[Ronald S. Bultje]

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).

Upon the next major bump, the warning will become an error and the fallback
is removed.

Ronald