Quoting Vittorio Giovara (2015-09-07 14:20:20) > On Mon, Sep 7, 2015 at 2:06 PM, Anton Khirnov <[email protected]> wrote: > > Quoting Vittorio Giovara (2015-09-07 13:54:02) > >> On Mon, Sep 7, 2015 at 1:12 PM, Hendrik Leppkes <[email protected]> > >> wrote: > >> >> by that reasoning we should drop AV_PIX_FMT_FLAG_RGB and just do > >> >> > >> >> if (strstr(pix_fmt, "rgb") || strstr(pix_fmt, "bgr")) > >> >> > >> >> sometimes you need redundant data for consistency and for simpler > >> >> interfaces, without having N different ways to access the same kind of > >> >> information, in my opinion > >> > > >> > Now you're just being silly. > >> > >> I was rather being sarcastic, it's silly to discuss over a simple 1bit > >> flag. > >> > >> I can see the point that macros are "useful" to hide the complexity of > >> the test, but an interface to check for this kind of thing already > >> exists (flags) and the downside of public macros is that you need to > >> document, maintain and make sure the new interfaces work. > >> > >> I insist that a single bitwise check is simpler to understand, use and > >> support for users and devs alike. > > > > The argument is not over one bit, but whether we want to store redundant > > information in the descriptor. Having the bit there introduces the > > possibility of doing it wrong, by someone adding a new format, but > > forgetting to set the flag. So I'd say a function (not a macro, because > > that inlines the logic in the caller and that is better avoided) is > > preferable. > > Yes, but my point is that having a single function to only check for a > single color space (gray) is not ideal either. >
In the current pixfmt model, gray is not a special colorspace, but just YUV with U and V missing. I am not at all against having av_pix_fmt_is_yuv()/av_pix_fmt_is_rgb() functions. Ideally though we would transition to something like Kostya's pixformaton thing, with an explicit descriptor field that would tell you whether the colorspace is YUV, RGB or whatever. -- Anton Khirnov _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
