[FFmpeg-devel] [RFC] RGB32 pixfmts cleanup

[Stefano Sabatini]

On date Monday 2009-03-16 19:31:27 +0100, Michael Niedermayer encoded:
> On Mon, Mar 16, 2009 at 09:31:56AM +0100, Stefano Sabatini wrote:
> > On date Sunday 2009-03-15 20:39:08 +0100, Michael Niedermayer encoded:
> > > On Sun, Mar 15, 2009 at 06:25:35PM +0100, Stefano Sabatini wrote:
> > > > Hi all,
> > > > 
> > > > the attached (non-working) patch shows my idea for what regards a
> > > > RGB32 pixfmts cleanup, I think this should somehow simplify the way we
> > > > deal with such formats, also it delivers more meaningful names.
> > > > 
> > > > Main problem is that I'm duplicating the number of the RGB32 formats.
> > > > 
> > > > Comments on this are very welcome, if we decide to take this path I'd
> > > > like to commit this before the end of the next week, thus taking
> > > > advantage of the flux status of the API and avoiding to #ifversion.
> > > [...]
> > > > @@ -114,6 +110,15 @@
> > > >      PIX_FMT_BGR555BE,  ///< packed BGR 5:5:5, 16bpp, (msb)1A 5B 5G 5R(lsb), big-endian, most significant bit to 1
> > > >      PIX_FMT_BGR555LE,  ///< packed BGR 5:5:5, 16bpp, (msb)1A 5B 5G 5R(lsb), little-endian, most significant bit to 1
> > > >  
> > > > +    PIX_FMT_ARGB32BE,  ///< packed ARGB 8:8:8:8, 32bpp, (msb)8A 8R 8G 8B(lsb), big-endian
> > > > +    PIX_FMT_ARGB32LE,  ///< packed ARGB 8:8:8:8, 32bpp, (msb)8A 8R 8G 8B(lsb), little-endian
> > > > +    PIX_FMT_RGBA32BE,  ///< packed RGBA 8:8:8:8, 32bpp, (msb)8R 8G 8B 8A(lsb), big-endian
> > > > +    PIX_FMT_RGBA32LE,  ///< packed RGBA 8:8:8:8, 32bpp, (msb)8R 8G 8B 8A(lsb), little-endian
> > > > +    PIX_FMT_ABGR32BE,  ///< packed ABGR 8:8:8:8, 32bpp, (msb)8A 8B 8G 8R(lsb), big-endian
> > > > +    PIX_FMT_ABGR32LE,  ///< packed ABGR 8:8:8:8, 32bpp, (msb)8A 8B 8G 8R(lsb), little-endian
> > > > +    PIX_FMT_BGRA32BE,  ///< packed BGRA 8:8:8:8, 32bpp, (msb)8B 8G 8R 8A(lsb), big-endian
> > > > +    PIX_FMT_BGRA32LE,  ///< packed BGRA 8:8:8:8, 32bpp, (msb)8B 8G 8R 8A(lsb), little-endian
> > > > +
> > > 
> > > this is sick
> > 
> > Please expand, this is not obvious to me (are you referring to the
> > duplication?).
> 
> yes, the very same pixel format exists twice under 2 different enum
> values

I see. Just a random (and maybe bad) idea:

enum PixelFormat {
...
  PIX_FMT_RGBA32BE,
  PIX_FMT_BGRA32BE,
  PIX_FMT_ARGB32BE,
  PIX_FMT_ABGR32BE,
...
};

#define PIX_FMT_RGBA32LE PIX_FMT_ABGR32BE
#define PIX_FMT_BGRA32LE PIX_FMT_ARGB32BE
#define PIX_FMT_ARGB32LE PIX_FMT_BGRA32BE
#define PIX_FMT_ABGR32LE PIX_FMT_RGBA32BE

#define PIX_FMT_RGBA32 PIX_FMT_NE(RGBA32)
#define PIX_FMT_BGRA32 PIX_FMT_NE(BGRA32)
#define PIX_FMT_ARGB32 PIX_FMT_NE(ARGB32)
#define PIX_FMT_ABGR32 PIX_FMT_NE(ABGR32)

We could register for each one the PixFmtInfo/PixDesc using the
PIX_FMT_XXXX32 macro, unfortunately this can't work if we want to get
a pixel from a name (e.g. "rgba32le" -> PIX_FMT_????), also I'd like
something less ugly than RGB32 vs. RGB32_1, but cannot see anything
*much* better, as each possible solution has its own drawbacks.

As for the suffix "32", I think this may help in each case, since it
may avoid any possible collision/confusion with RGBA64 variants.

Regards.
-- 
FFmpeg = Fiendish & Faboulous Mythic Patchable Earthshaking Gem