[MPlayer-dev-eng] RGB vs. BGR

[Michael Niedermayer]

Hi

yes i know DOCS/tech/colorspace.txt, but IMHO we shouldnt refer to open gl and 
suggest to use -vo gl to check rgb vs bgr compliance as vo_gl.c only supports 
rgb24&rgb32 and there are many more formats around, and some developers (like 
me) dont really know open gl

i cant fix the recent reported bugs unless i know exactly how RGB&BGR is 
defined on big&little endian in mplayer, ok, well i could fix them but then 
someone who has a diferent interpretation of it would apply some fix to the 
swscaler because of some bug in a vo, or a fix in a vo cuz of a 100000l 
RGB/BGR bug/missunderstading in the swscaler

btw, the yuv2rgb (from libmpeg2) code names 16&32bit depending upon the order 
in a int / short when read without any byteswap and the byte order in memory 
for 24bit, libavcodec does the same, the swscaler has RGB<->BGR reversed 
bahvior which matches vo_gl.c on little endian at least

arpi, please fill the following tables :)
memory order:		name: (big/little endian if different)
RGBA			???32
ARGB			???32
BGRA			???32
ABGR			???32
RGB			???24
BGR			???24

order in an int		name: (big/little endian if different)
mostsignifant .. least significant bit
8A8R8G8B		???32
8A8B8G8R		???32
8R8G8B			???24
8B8G8R			???24
5R6G5B			???16
5B6G5R			???16
1A5R5G5B		???15
1A5B5G5R		???15

-- 
Michael
level[i]= get_vlc(); i+=get_vlc();		(violates patent EP0266049)
median(mv[y-1][x], mv[y][x-1], mv[y+1][x+1]);	(violates patent #5,905,535)
buf[i]= qp - buf[i-1];				(violates patent #?)
for more examples, see http://mplayerhq.hu/~michael/patent.html
stop it, see http://petition.eurolinux.org & http://petition.ffii.org/eubsa/en