From 96da430d08f40e8e42088a15ea4fa5c779524db3 Mon Sep 17 00:00:00 2001 From: arpi Date: Sat, 13 Apr 2002 02:17:43 +0000 Subject: RGBvsBGR added git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@5588 b3059339-0415-0410-9bf9-f77b7e298cf2 --- DOCS/tech/colorspaces.txt | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) (limited to 'DOCS') diff --git a/DOCS/tech/colorspaces.txt b/DOCS/tech/colorspaces.txt index 4fb8875098..8dcdcb2f90 100644 --- a/DOCS/tech/colorspaces.txt +++ b/DOCS/tech/colorspaces.txt @@ -79,3 +79,26 @@ I420: 12 bpp, full sized Y plane followed by 2x2 subsampled U and V planes IYUV: the same as I420 YVU9: 9 bpp, full sized Y plane followed by 4x4 subsampled V and U planes +Huh 2. RGB vs. BGR ? +==================== + +The 2nd most missunderstood thingie... + +You know, there are Intel and Motorola, and they use different byteorder. +There are also others, like MIPS or Alpha, they all follow either Intel +or Motorola byteorder. +Unfortunatelly, the packed colorspaces depend on CPU byteorder. So, RGB +on Intel and Motorola means different order of bytes. + +In MPlayer, we have constants IMGFMT_RGBxx and IMGFMT_BGRxx. +Unfortunatelly, some codecs and vo drivers follow Intel, some follow Motorola +byteorder, so they are incompatible. We had to find a stable base, so long +time ago I've choose OpenGL, as it's a wide-spreaded standard, and it well +defines what is RGB and what is BGR. So, MPlayer's RGB is compatible with +OpenGL's GL_RGB on all platforms, and the same stay for BGR - GL_BGR. +Unfortunatelly, most of the x86 codecs call our BGR to RGB, so it sometimes +confuse developers. + +If you are unsure, try the OpenGL driver (-vo gl). There is at least software +OpenGL implementation for all major platforms and OSes. + -- cgit v1.2.3