Rename DOCS/tech/ to DOCS/OUTATED-tech/

While DOCS/tech/ contains lots of documentation about mplayer's
internals, most of it seems outdated, and hasn't been touched in many
years. On the other hand, there still might be useful things in there,
but it's hard to tell which parts.

Instead of deleting all it, rename the directory to "warn" potential
developers that the documentation is completely outdated.

1 files changed, 158 insertions, 0 deletions

diff --git a/DOCS/OUTDATED-tech/colorspaces.txt b/DOCS/OUTDATED-tech/colorspaces.txt
new file mode 100644
index 0000000000..eaf9d221e4
--- /dev/null
+++ b/DOCS/OUTDATED-tech/colorspaces.txt
@@ -0,0 +1,158 @@
+In general
+==========
+
+There are planar and packed modes.
+- Planar mode means: You have 3 separate images, one for each component,
+each image 8 bits/pixel. To get the real colored pixel, you have to
+mix the components from all planes. The resolution of planes may differ!
+- Packed mode means: you have all components mixed/interleaved together,
+so you have small "packs" of components in a single, big image.
+
+There are RGB and YUV colorspaces.
+- RGB: Red, Green and Blue components. Used by analog VGA monitors.
+- YUV: Luminance (Y) and Chrominance (U,V) components. Used by some
+  video systems, like PAL. Also most M(J)PEG/DCT based codecs use this.
+
+With YUV, they used to reduce the resolution of U,V planes:
+The most common YUV formats:
+FOURCC:    bpp: IEEE:      plane sizes: (w=width h=height of original image)
+444P       24   YUV 4:4:4  Y: w * h  U,V: w * h
+YUY2,UYVY  16   YUV 4:2:2  Y: w * h  U,V: (w/2) * h      [MJPEG]
+YV12,I420  12   YUV 4:2:0  Y: w * h  U,V: (w/2) * (h/2)  [MPEG, H.263]
+411P       12   YUV 4:1:1  Y: w * h  U,V: (w/4) * h      [DV-NTSC, CYUV]
+YVU9,IF09   9   YUV 4:1:0  Y: w * h  U,V: (w/4) * (h/4)  [Sorenson, Indeo]
+
+The YUV a:b:c naming style means: for <a> samples of Y there are <b> samples
+of UV in odd lines and <c> samples of UV in even lines.
+
+conversion: (some cut'n'paste from www and maillist)
+
+RGB to YUV Conversion:
+    Y  =      (0.257 * R) + (0.504 * G) + (0.098 * B) + 16
+    Cr = V =  (0.439 * R) - (0.368 * G) - (0.071 * B) + 128
+    Cb = U = -(0.148 * R) - (0.291 * G) + (0.439 * B) + 128
+YUV to RGB Conversion:
+    B = 1.164(Y - 16)                  + 2.018(U - 128)
+    G = 1.164(Y - 16) - 0.813(V - 128) - 0.391(U - 128)
+    R = 1.164(Y - 16) + 1.596(V - 128)
+
+In both these cases, you have to clamp the output values to keep them in
+the [0-255] range. Rumour has it that the valid range is actually a subset
+of [0-255] (I've seen an RGB range of [16-235] mentioned) but clamping the
+values into [0-255] seems to produce acceptable results to me.
+
+Julien (sorry, I can't recall his surname) suggests that there are
+problems with the above formula and proposes the following instead:
+    Y  = 0.299R + 0.587G + 0.114B
+    Cb = U'= (B-Y)*0.565
+    Cr = V'= (R-Y)*0.713
+with reciprocal versions:
+    R = Y + 1.403V'
+    G = Y - 0.344U' - 0.714V'
+    B = Y + 1.770U'
+Note: This formula doesn't contain the +128 offsets of U,V values!
+
+Conclusion:
+Y = luminance, the weighted average of R G B components. (0=black 255=white)
+U = Cb = blue component (0=green 128=grey 255=blue)
+V = Cr = red component  (0=green 128=grey 255=red)
+
+
+Huh. The planar YUV modes.
+==========================
+
+The most misunderstood thingie...
+
+In MPlayer, we usually have 3 pointers to the Y, U and V planes, so it
+doesn't matter what the order of the planes in the memory is:
+    for mp_image_t and libvo's draw_slice():
+        planes[0] = Y = luminance
+        planes[1] = U = Cb = blue
+        planes[2] = V = Cr = red
+    Note: planes[1] is ALWAYS U, and planes[2] is V, the FOURCC
+    (YV12 vs. I420) doesn't matter here! So, every codec using 3 pointers
+    (not only the first one) normally supports YV12 and I420 (=IYUV), too!
+
+But there are some codecs (VfW, dshow) and vo drivers (xv) ignoring the 2nd
+and 3rd pointer that use only a single pointer to the planar YUV image. In
+this case we must know the right order and alignment of planes in the memory!
+
+from the webartz fourcc list:
+YV12:  12 bpp, full sized Y plane followed by 2x2 subsampled V and U planes
+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 misunderstood thingie...
+
+You know, there are Intel and Motorola, and they use different byteorder.
+There are also others, like MIPS or Alpha, but all follow either Intel
+or Motorola byteorder.
+Unfortunately, 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.
+Unfortunately, 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 chosen OpenGL, as it's a wide-spreaded standard, and it well
+defines what RGB is and what BGR is. So, MPlayer's RGB is compatible with
+OpenGL's GL_RGB on all platforms, and the same goes for BGR - GL_BGR.
+Unfortunately, most of the x86 codecs call our BGR RGB, so it sometimes
+confuses developers.
+
+memory order:           name
+lowest address .. highest address
+RGBA                    IMGFMT_RGBA
+ARGB                    IMGFMT_ARGB
+BGRA                    IMGFMT_BGRA
+ABGR                    IMGFMT_ABGR
+RGB                     IMGFMT_RGB24
+BGR                     IMGFMT_BGR24
+
+order in an int         name
+most significant .. least significant bit
+8A8R8G8B                IMGFMT_BGR32
+8A8B8G8R                IMGFMT_RGB32
+5R6G5B                  IMGFMT_BGR16
+5B6G5R                  IMGFMT_RGB16
+1A5R5G5B                IMGFMT_BGR15
+1A5B5G5R                IMGFMT_RGB15
+
+The following are palettized formats, the palette is in the second plane.
+When they come out of the swscaler (this can be different when they
+come from a codec!), their palette is organized in such a way
+that you actually get:
+
+3R3G2B                  IMGFMT_BGR8
+2B3G3R                  IMGFMT_RGB8
+1R2G1B                  IMGFMT_BGR4_CHAR
+1B2G1R                  IMGFMT_RGB4_CHAR
+1R2G1B1R2G1B            IMGFMT_BGR4
+1B2G1R1B2G1R            IMGFMT_RGB4
+
+Depending upon the CPU being little- or big-endian, different 'in memory' and
+'in register' formats will be equal (LE -> BGRA == BGR32 / BE -> ARGB == BGR32)
+
+Practical coding guide:
+
+The 4, 8, 15, and 16 bit formats are defined so that the portable way to
+access them is to load the pixel into an integer and use bitmasks.
+
+The 24 bit formats are defined so that the portable way to access them is
+to address the 3 components as separate bytes, as in ((uint8_t *)pixel)[0],
+((uint8_t *)pixel)[1], ((uint8_t *)pixel)[2].
+
+When a 32-bit format is identified by the four characters A, R, G, and B in
+some order, the portable way to access it is by addressing the 4 components
+as separate bytes.
+
+When a 32-bit format is identified by the 3 characters R, G, and B in some
+order followed by the number 32, the portable way to access it is to load
+the pixel into an integer and use bitmasks.
+
+When the above portable access methods are not used, you will need to write
+2 versions of your code, and use #if HAVE_BIGENDIAN to choose the correct
+one.