[Bug 25807] Cant convert from WINED3DFMT_YV12 to WINED3DFMT_B8G8R8X8_UNORM

wine-bugs at winehq.org wine-bugs at winehq.org
Sun Jan 30 21:28:24 CST 2011


--- Comment #6 from Ludio <ljerabek at cox.net> 2011-01-30 21:28:22 CST ---
Great information for RGB->YV12

Multimedia Technology Basics: FourCCs, AVI Codecs, ASF Codecs, WAV Codecs, 
MOV Codecs, RM Codecs, YUV Codecs, RGB Codecs, Lossy and Lossless Codecs 
and More
by Mike Melanson (mike at multimedia.cx)
v1.1: September 25, 2005

  Copyright (c) 2003-2005 Mike Melanson
  Permission is granted to copy, distribute and/or modify this document
  under the terms of the GNU Free Documentation License, Version 1.2
  or any later version published by the Free Software Foundation;
  with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
  A copy of the license is included in the section entitled "GNU
  Free Documentation License".

 * Introduction
 * Codecs
 * FourCCs
 * Multimedia Files
 * What Application Can "Play" This File?
 * RGB and YUV Colorspaces
 * References
 * Acknowledgements
 * Changelog
 * GNU Free Documentation License

This document is intended as a very brief overview of assorted technical
topics that will help a developer begin to understand computer
multimedia technology. There are many other references for the verbose
theory underlying certain of the presented concepts, particularly YUV
colorspaces; this document is long on technical explanation and short on
abstract concepts.

I run a technical multimedia website. Occasionally, I browse my ISP's web 
server logs which contain information about search engine queries that 
brought visitors to my site. I am curious to know if people are actually 
finding what they are looking for.

I often see web log records that indicate visitors looking for "asf codec" 
or "mov codec" or "yuv codec". With any luck, the search engines will 
index this document and point visitors to more useful information.

"Codec" is an abbreviation for COder/DECoder. Briefly, this refers to any
algorithm that codes data into another form and then decodes the coded
data in order to recover the original data (more or less). In the context
of multimedia technology, this means taking raw audio or video data, which
tends to be enormous, and sending it through a coder algorithm to 
compress it to a considerably smaller size. Then it is stored on disk,
transmitted over the network, etc. until it is time to play it back. At
such time, the compressed data is sent through the decoder portion of the
decoder algorithm which reconstructs the original audio or video data for 

Actually, a large majority of multimedia codecs do not reconstruct the
original audio or video data upon decompression. These codecs fall into
the category "lossy". Codecs that reconstruct the original data exactly
upon decompression are categorized as "lossless". Why would it be okay to
lose information during encoding? Many multimedia codecs throw away subtle
pieces of information which, according to empirical research, have little
impact on human perception. As a very simple example, 2 adjacent pixels
might be so close in color that the coder declares them to be the same
color and codes them together as "2 x color1" instead of "1 x color1, 1 x
color2". The decoded data will not be exactly the same as the original
data, but the goal is to be able to reconstruct a picture that will be
"good enough".

A FourCC is short for "four-character code". FourCCs are very commonly 
seen in multimedia files in order to identify audio or video codecs, as 
well as to mark boundaries within the file.

A FourCC is generally comprised of 4 ASCII range characters which, when 
examined as a hex dump, form a human-readable, four-character string. For 

   08 77 73 74  62 6C 00 00  00 7F 73 74  73 64 00 00  .wstbl....stsd..
   00 00 00 00  00 01 00 00  00 6F 53 56  51 33 00 00  .........oSVQ3..

This is taken from an Apple QuickTime file. There is at least one FourCC
('stsd') and two more ('stbl' and 'SVQ3') which are not immediately 
discernible since the 'w' and 'o' characters preceding them are valid
ASCII characters.

Since a FourCC is made up of 4 ASCII bytes and each byte is 8 bits, a 
FourCC is 32 bits long. This works well with modern 32-bit CPUs. As seen 
in the above example, 'SVQ3' is also represented as 0x53565133 in 
big-endian hexadecimal notation, or 0x33515653 in little-endian hex 
notation. Such knowledge alleviates the need for memcmp() and strncmp() 
functions when scanning for FourCCs.

It is important to note that FourCCs do not necessarily need to contain 
4 valid alphanumeric ASCII characters. For example, there are a variety of 
FourCCs in the QuickTime format which are well outside the range.

Multimedia Files
Many multimedia files that carry both audio and video bear extensions 
such as .avi (Microsoft AVI files), .asf (a.k.a., .wmv and .wma, 
collectively known as Microsoft ASF files), .mov (Apple QuickTime files),
and .rm (RealMedia files). Confusion often arises as one wonders what 
application can, for example, "play .mov files". That is a very difficult 
question to answer and here is why:

All of the formats mentioned in the preceding paragraph are also
referred to as multimedia container formats. All they do is pack chunks
of audio and video data together, interleaved, along with some
instructions to inform a playback application how the data is to be
decoded and presented to the user. This is the typical layout of many
multimedia file formats:

    file header
      title, creator, other meta-info
      video header
        video codec FourCC
        width, height, colorspace, playback framerate
      audio header
        audio codec FourCC
        bits/sample, playback frequency, channel count
    file data
      encoded audio chunk #0
      encoded video chunk #0
      encoded audio chunk #1
      encoded video chunk #1
      encoded audio chunk #2
      encoded video chunk #2
      encoded audio chunk #3
      encoded video chunk #3

Those audio and video chunks can be encoded with any number of audio or 
video codecs, the FourCCs of which are specified in the file header.

See The Almost Definitive FourCC Definition List listed in the reference 
for more information on the jungle of FourCCs out there, and where they 
commonly appear.

What Application Can "Play" This File?
Here comes the big question. You have some random Apple QuickTime file.
Perhaps you are running some non-Microsoft, non-Apple operating system and 
there is no official Apple QuickTime application available. Is there a
program that can "play" the QT file?

Since a QuickTime file can contain many different types of audio or video
data, it is not enough to be able to simply decode the QuickTime container
format; the audio and video codec formats must be supported as well.

This is why there is no simple answer to whether or not a particular 
multimedia application can "play" a type of multimedia container file 
format. A player application needs to be able to decode the container
format and decode the audio and video codec formats inside.

Interleaving is the process of storing alternating audio and video chunks 
in the data section of a multimedia file:

      encoded audio chunk #0
      encoded video chunk #0
      encoded audio chunk #1
      encoded video chunk #1
      encoded audio chunk #2
      encoded video chunk #2
      encoded audio chunk #n
      encoded video chunk #n

Why is this done? Why not just place all of the video data in the file, 
followed by all of the audio data? For example:

      encoded video chunk #0
      encoded video chunk #1
      encoded video chunk #2
      encoded video chunk #n
      encoded audio chunk #0
      encoded audio chunk #1
      encoded audio chunk #2
      encoded audio chunk #n

Conceptually, this appears to be a valid solution. In practice, however, 
it falls over. Assuming these audio and video streams are part of the same 
file on the same disk (almost always the case), there is a physical 
mechanism called the disk read head which has to constantly make a leap 
between two different positions on the disk. When the chunks are 
interleaved, the read head does not need to seek at all; it can read all 
the data off in a contiguous fashion.

RGB and YUV Colorspaces

There are two general families of colorspaces for video: RGB and YUV. If
you have any experience with computer graphics at all, you have probably
been exposed to the red-green-blue (RGB) colorspace. More specifically,
you have probably seen packed RGB colorspaces. A packed colorspace has
all of the elements interleaved. For example, a packed RGB24 colorspace
with 8 bits for each R, G, or B element, is laid out in memory as:

  R G B R G B R G B ...

Sometimes, the opposite ordering is required. This would be expressed as 

  B G R B G R B G R ...

24 bits is awkward for many CPUs; 32 bits is far more conducive. 
Therefore, packed 32-bit RGB formats are often used for video output in 
the interest of speed. When this is done, a fourth component, usually 
labeled 'A', is added.

  ARGB: A R G B  A R G B  A R G B
  BGRA: B G R A  B G R A  B G R A

Sometimes, the 'A' component actually represents an alpha transparency
value, used for blending RGB images together. For video playback, it is
generally ignored.

There are also many variations of 15- and 16-bit packed RGB formats. For 
example, a RGB15 format may pack 5 bits for each component into the lower 
15 bits of a 2-byte word and leave the top bit for some other use:

   byte 0   byte 1
  Xrrrrrgg gggbbbbb

Of course, how those 2 bytes are stored in memory (high or low byte
first) is dependent upon the application. BGR15 may also be seen. RGB16
formats typically allocate an extra bit for green:

   byte 0   byte 1
  rrrrrggg gggbbbbb

Many older video codecs rely on packed RGB colorspaces since that is
what the hardware was capable of displaying natively. Certain modern
codecs still used RGB colorspaces if the source material is conducive,
i.e., if it is non-photorealistic or just plain simple.

However, many modern video codecs rely on a YUV colorspace. 'YUV' is a
frustrating acronym since it is so difficult to guess what the letters
could possibly stand for. The colorspace was originally known as YCbCr,
with the 'b' and 'r' characters written as subscripts. This is what the
components break down as:

  Y = luminance, or intensity
  U = Cb = blue chrominance value
  V = Cr = red chrominance value

Where is green represented? Green can be derived from the Y, U, and V 
values. See the references for more information on converting YUV to RGB 
and back.

Note that with RGB colorspaces, every single pixel has a different R, G,
and B sample. The same is not true with YUV colorspaces. YUV operates on
the empirical evidence that the human eye is more sensitive to variations
in the intensity of a pixel rather than variations in color.  Thus, every
pixel in a YUV image has an associated Y sample, but groups of pixels
share U and V samples.

For example, examine the YUY2 colorspace, a.k.a., YUV 4:2:2 or just
YUV422. This is a packed YUV colorspace, which means that the Y, U, and V
samples are interleaved. The YUV data is laid out in memory as follows
(each sample is one byte):

  Y0 U Y1 V   Y0 U Y1 V  Y0 U Y1 V

Each group of 4 bytes represents 2 pixels. The first pixel is represented 
by (Y0, U, V) and the second by (Y1, U, V). So each pixel gets a Y sample 
but has to share a U and a V sample.

Perhaps the most common YUV format is I420, a.k.a. YUV 4:2:0 or just
YUV420. This is the format used in JPEG, MPEG, and many other modern video
codecs. The most notable difference between this colorspace and any other
discussed up to this point is that it is a planar format, not a packed
format. This means that when the data is stored in memory-- all of the Y
data is stored first, then all of the U data, then all of the V data.

In I420 data, pixels are grouped in 2x2 blocks:

  p0 p1
  p2 p3

For each 2x2 block, each pixel is presented by a Y sample. But each pixel 
in the block shares a U and a V sample:

  Y0 Y1  U  V
  Y2 Y3

As a highly contrived example, consider a I420 image that is 6x2 pixels.

   p0  p1  p2  p3  p4  p5
   p6  p7  p8  p9 p10 p11 

The image will be broken up into 3 2x2 blocks for the purpose of 
representing it as I420:

   p0  p1 |  Y0  Y1  U0 V0
   p6  p7 |  Y6  Y7
   p2  p3 |  Y2  Y3  U1 V1
   p8  p9 |  Y8  Y9
   p4  p5 |  Y4  Y5  U2 V2
  p10 p11 | Y10 Y11

The planes of data will be stored in memory as:

  Y0 Y1 Y2 Y3 Y4 Y5 Y6 Y7 Y8 Y9 Y10 Y11 U0 U1 U2 V0 V1 V2

Another common planar format is YV12. This is precisely the same as I420 
except that U and V data planes are reversed.

Another planar YUV format occasionally seen is YUV9, a.k.a. YUV 4:1:0 or 
just YUV410. This is equivalent to I420 except that an image is broken 
into 4x4 pixel blocks. Each pixel gets its own Y sample while each block 
shares one U and one V sample over the entire block.

Of course, there is also non-subsampled planar YUV available, YUV 4:4:4. 
In other words, every pixel is represented by a Y, U, and V sample.

Notice that YUY2, I420, and YUV9 are all valid FourCCs. Where do these
FourCCs come from? I strongly suspect it is related to how many bits or
bytes are required to store a single pixel, on average. For YUY2 data, 4
bytes represent 2 pixels, so 2 bytes on average are required to
represent 1 pixel. In I420 data:

  4 + 1 + 1 = 6 bytes * 8 bits/byte = 48 bits / 4 pixels = 12 bits/pixel

And for YUV9 data:

  (16 + 1 + 1) * 8 = 144 bits / 16 pixels = 9 bits/pixel

Note that it is conceptually possible for RGB data to be stored in a
planar manner rather than packed. In practice, this is rarely done.

Torben Nielsen (torben at Hawaii.Edu) for correcting 

Diego Biurrun (diego at biurrun.de) for cosmetic English composition 

v1.1: September 25, 2005
- replaced YV12 with I420 (correct FourCC) and noted what YV12 really 
- English composition fixes

v1.0: June 14, 2003
- initial release

GNU Free Documentation License
see http://www.gnu.org/licenses/fdl.html

Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.

More information about the wine-bugs mailing list