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). Upon the next major bump, the warning will become an error and the fallback is removed. Ronald _______________________________________________ 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".
