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)

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.

Attachment: signature.asc
Description: PGP signature

_______________________________________________
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".

Reply via email to