On Thu, Nov 21, 2024 at 01:06:20PM +0100, Niklas Haas wrote: > On Thu, 21 Nov 2024 01:26:36 +0100 Michael Niedermayer > <mich...@niedermayer.cc> wrote: > > Hi > > > > > > On Sat, Nov 16, 2024 at 12:25:01PM +0100, Niklas Haas wrote: > > > From: Niklas Haas <g...@haasn.dev> > > > > > > Group them into an enum rather than random #defines, and document their > > > behavior a bit more obviously. > > > > > > > > Of particular note, I discovered that SWS_DIRECT_BGR is not referenced > > > anywhere else in the code base. As such, I have moved it to the deprecated > > > section, alongside SWS_ERROR_DIFFUSION. > > > > The intend of SWS_DIRECT_BGR was to avoid a intermediate YUV > > for RGB -> RGB rescaling. It indeed probably makes no sense in a new API > > like that > > > > > > "#defines" and enums are not exactly equivalent and could break some user > > apps > > in theory > > > > I think its probably ok but maybe should be documented in APIChanges or > > something > > I can add a note in APIchanges, but it feels a bit silly to bump the ABI > version > for this, since it's just a compile-time change. I propose: > > 1) Add a note in APIchanges but without bumping the version > -or- > 2) Squash this commit in with the one adding the new API > > In either case, I imagine the concern is largely theoretical, since the only > realistic way I can imagine it breaking is if a user for some reason decided > to #ifdef to see if a flag is supported (instead of looking at the version).
Its probably theoretical, but people do all kinds of stuff. Like building wrapers around our API and I remember one of these once unexpectedly breaking with some change unrelated to this. So IMHO it should be documented, the details are less important thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB There will always be a question for which you do not know the correct answer.
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".
