[Ffmpeg-devel] libswscale RGB32 colorspace chaos

[Luca Abeni]

Hi Reimar,

On Fri, 2006-10-13 at 23:26 +0200, Reimar D?ffinger wrote:
> Hello,
> On Fri, Oct 13, 2006 at 11:23:06PM +0200, Reimar D?ffinger wrote:
> > According to rgb2rgb.c, line 470 rgb32 format is b << 16 + g << 8 + r.
> > On the other hand yuv2rgb.c, line 699 looks to me like it's
> > r << 16 + g << 8 + b.
> > So which one is correct? Or am I missing something??
This confused me a lot when I tried to understand the code some time
ago...
I think the authoritative source of information is avutil.h:
 * PIX_FMT_RGB32 is handled in an endian-specific manner. A RGBA
 * color is put together as:
 *  (A << 24) | (R << 16) | (G << 8) | B
 * This is stored as BGRA on little endian CPU architectures and ARGB on
 * big endian CPUs.
 *
PIX_FMT_RGBA and friends are the "endian independent" names (see
avutil.h, lines 111 and following).

> Obviously I missed this great line:
> const int isRgb = isBGR(c->dstFormat);
> Maybe there is some sense to be found in all this, but I sure can't see
> it...
The problem is that mplayer and ffmpeg use different naming conventions
(mplayer calls RGB what ffmpeg calls BGR, and vice-versa). This caused
the confusion you are seeing (this confusing "isRgb = isBGR()" thing is
the simplest way to make things work, simply because an ffmpeg's rgb
format is an mplayer's bgr format, and vice versa)...

At least, this is my understanding... I hope it is correct. I did a lot
of tests, and everything seems to show that the current code works ok,
even if it is very confusing :)
(of course I might have missed some important test case... If anyone
sees some strange behaviour, please let me know)


				Luca