On Fri Jan 15 08:51:07 CET 2016 wm4 <nfxjfg at googlemail.com> wrote;
> On Thu, 14 Jan 2016 13:58:14 -0800 Richard Smith <richard at metafoo.co.uk>
> wrote:
> > libavutil/pixfmt.h defines a collection of endian-specific pixel formats as
> > macros. These macro names can cause conflicts with external projects that
> > use those identifiers for their own purposes. Here's a patch to define
> > these aliases as enumerators instead of macros, please consider merging:
> >
> >
> > https://github.com/zygoloid/FFmpeg/commit/c20a0e2e66e52c45b9193bc750165b7ecf7f3ca4
> >
> > (Note that AV_PIX_FMT_Y400A was already defined as an enumerator in the
> > PixelFormat enumeration, so I deleted its (no-op) macro entirely.)
>
> API users might check for the existence of such pixfmts with #ifdef,
That would be a very odd thing for them to do, as most pixfmts do not
have #defines.
> and I don't understand the reasoning behind your patch. Why would
> external projects redefine these macros?
The project in question has its own enumeration:
namespace MyProject {
enum PixelFormatToUse {
// ... some other values ...
AV_PIX_FMT_RGB32, // use ffmpeg's AV_PIX_FMT_RGB32
// ...
};
}
The names are intentionally chosen to be in 1-1 correspondence with
ffmpeg's names. But ffmpeg's macro sometimes renames this project's
enumerator, depending on whether its header is included before that
file.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
