On 02/04/2012 12:38 PM, Ronald S. Bultje wrote: > Well, let's just say that those macros have all sort of ill-defined > behaviour associated with them. For example, placing > PIX_FMT_MONOWHITE/BLACK under isGray() causes all kind of bad failures > (and used to cause crashes). This isn't because black/white aren't > gray, but because the uses of such generic macros are associated with > specific behaviours in some sort of a "but it works for me!" kind of > way. The same is true for the RGB macros...
Ugh... > Renaming the macros to isPackedRGB would be sufficient if it's just > consistency. Is there a specific case where we need a isRGB(GBRP) > test? Well, I guess it is a form of "future proofing". What if we add more planar RGB/GBR/BGR formats? (high bit depth?) There should be a way to test something similar to: > + if (isAnyRGB(srcFormat) && isPlanar(srcFormat) > + && isAnyRGB(dstFormat) && !isPlanar(dstFormat)) > + c->swScale = planarRgbToRgbWrapper; I don't really like the idea of hardcoding a pix_fmt for this test. So the question is, new macro, or no new macro? - Derek _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
