Quoting Niklas Haas (2024-01-24 13:45:33) > On Tue, 23 Jan 2024 20:22:41 +0100 Michael Niedermayer > <mich...@niedermayer.cc> wrote: > > Hi all > > > > As it was a little difficult for me to not loose track of what is > > blocking a release. I suggest that for all release blocking issues > > open a ticket and set Blocking to 7.0 > > that way this: > > https://trac.ffmpeg.org/query?blocking=~7.0 > > > > or for the ones not closed: > > https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&blocking=~7.0 > > > > will list all blocking issues > > > > Ive added one, for testing that, i intend to add more if i see something > > > > What is blocking? (IMHO) > > * regressions (unless its non possible to fix before release) > > * crashes > > * security issues > > * data loss > > * privacy issues > > * anything the commuity agrees should be in the release > > I'd like to discuss YUVJ deprecation/removal. To what extent do we need to put > an additional deprecation warning on these? libswscale already prints a > warning > on every use, informing the user that they need to set metadata correctly. > > Is it feasible to replace YUVJ pixfmts by #define for their non-YUV equivalent > analogs in 7.0? 7.1?
What would then happens to current lavc and lavfi callers that still use them? AFAIU you cannot avoid them until your patchset goes in, right? -- Anton Khirnov _______________________________________________ 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".
