On Fri, 15 Jan 2016 10:39:59 -0800
Richard Smith wrote:
> On Fri Jan 15 08:51:07 CET 2016 wm4 wrote;
> > On Thu, 14 Jan 2016 13:58:14 -0800 Richard Smith
> > wrote:
> > > libavutil/pixfmt.h defines a collection of endian-specific pixel formats
> > > as
> > > macros. These macro names can ca
On Fri Jan 15 08:51:07 CET 2016 wm4 wrote;
> On Thu, 14 Jan 2016 13:58:14 -0800 Richard Smith
> 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
On 15 January 2016 at 18:51, wm4 wrote:
> API users might check for the existence of such pixfmts with #ifdef,
> and I don't understand the reasoning behind your patch. Why would
> external projects redefine these macros?
All other pixfmts are already enums, why the discrepency ?
Having everythin
On Thu, Jan 14, 2016 at 10:58 PM, Richard Smith 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
On Thu, 14 Jan 2016 13:58:14 -0800
Richard Smith 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 aliase
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:
htt
