Back to the OpenGL extension cross reference
GL_APPLE_ycbcr_422
APPLE_ycbcr_422
Name Strings
GL_APPLE_ycbcr_422
Contact
Geoff Stahl, Apple (gstahl 'at' apple.com)
Status
Shipping as of August 24, 2002 (Mac OS X v10.2)
Version
$Date: 2002/09/19 00:01:25 $ $Revision: 1.6 $
Number
275
Dependencies
OpenGL 1.1 is required
APPLE_packed_pixels or OpenGL 1.2 is required
Written against OpenGL 1.2.1
Overview
This extension provides a method for GL to read, store and optionally
process textures that are defined in Y'CbCr 422 video formats. This
extension supports the two common Y'CbCr 422 video formats (known by
QuickTime FourCC as '2vuy' and 'yuvs'). These formats represent one of the
most common 16 bit Y'CbCr formats in both standard and reverse byte
ordering. From a client stand point these can be assumed to be decoded
immediately (even though the implementation is free to optimize the data
storage and keep it in the native format) and otherwise function as any
other texture format. The texture command <internalformat> parameter
normally be should be specified as RGB, since Y'CbCr is just a form of RGB
data. This extension can be supported with either hardware or software
decoding and it is up to the specific implementation to determine which is
used.
A new <format> is added, YCBCR_422_APPLE. Additionally, to handle the
difference in pixel size and byte ordering for 422 video, the pixel storage
operations treat YCBCR_422_APPLE as a 2 component format using
the UNSIGNED_SHORT_8_8_APPLE or UNSIGNED_SHORT_8_8_REV_APPLE <type>.
The '2vuy' or k2vuyPixelFormat pixel format is an 8-bit 4:2:2 Component
Y'CbCr format. Each 16 bit pixel is represented by an unsigned eight bit
luminance component and two unsigned eight bit chroma components. Each pair
of pixels shares a common set of chroma values. The components are ordered
in memory; Cb, Y0, Cr, Y1. The luminance components have a range of [16,
235], while the chroma value has a range of [16, 240]. This is consistent
with the CCIR601 spec. This format is fairly prevalent on both Mac and Win32
platforms. The equivalent Microsoft fourCC is ÔUYVYÕ. This format is
supported with the UNSIGNED_SHORT_8_8_REV_APPLE type for pixel storage
operations.
The 'yuvs' or kYUVSPixelFormat is an 8-bit 4:2:2 Component Y'CbCr format.
Identical to the k2vuyPixelFormat except each 16 bit word has been byte
swapped. This results in a component ordering of; Y0, Cb, Y1, Cr. This is
most prevalent yuv 4:2:2 format on both Mac and Win32 platforms. The
equivalent Microsoft fourCC is 'YUY2'. This format is supported with the
UNSIGNED_SHORT_8_8_APPLE type for pixel storage operations.
Issues
Why is YCRCR_422 not provided as an <internalformat>?
The internalFormat parameter passes two distinct pieces of information:
which one of the six texEnv equations to use *and* what the desired
internal storage format is. All of the existing internal format enums
have one of {RGBA, RGB, L, LA, A, I} embedded in the name to specify
which of the six texEnv equations. Since the YUV data contains RGB
information, only the RGB texEnv setting is meaningful. Thus, if we did
provide a new internal format enum it would have to be something of the
form GL_RGB_YCRCR422 (weird, but has the right meaning). Using
YCRCR_422 as an internalFormat setting would be incorrect with respect
to the texEnv equations.
None
Accepted by the <format> parameter of DrawPixels, ReadPixels, TexImage1D,
TexImage2D, GetTexImage, TexImage3D, TexSubImage1D, TexSubImage2D,
TexSubImage3D, GetHistogram, GetMinmax, ConvolutionFilter1D,
ConvolutionFilter2D, ConvolutionFilter3D, GetConvolutionFilter,
SeparableFilter2D, SeparableFilter3D, GetSeparableFilter, ColorTable,
GetColorTable:
YCBCR_422_APPLE 0x85B9
Accepted by the <type> parameter of DrawPixels, ReadPixels, TexImage1D,
TexImage2D, GetTexImage, TexImage3D, TexSubImage1D, TexSubImage2D,
TexSubImage3D, GetHistogram, GetMinmax, ConvolutionFilter1D,
ConvolutionFilter2D, ConvolutionFilter3D, GetConvolutionFilter,
SeparableFilter2D, SeparableFilter3D, GetSeparableFilter, ColorTable,
GetColorTable:
UNSIGNED_SHORT_8_8_APPLE 0x85BA
UNSIGNED_SHORT_8_8_REV_APPLE 0x85BB
Additions to Chapter 3 of the OpenGL 1.2.1 Specification (Rasterization)
Two entries are added to table 3.5 (DrawPixels and ReadPixels type parameter
values and the corresponding OpenGL data types):
type Parameter Corresponding Special
Token Name GL Data Type Interpretation
-------------- ------------- --------------
UNSIGNED_SHORT_8_8_APPLE ushort Yes
UNSIGNED_SHORT_8_8_REV_APPLE ushort Yes
One entry is added to table 3.6 (DrawPixels and ReadPixels formats):
Format Name Element Meaning and Order Target Buffer
----------- ------------------------- -------------
YCBCR_422_APPLE Y luminance value, Color
[Cb,Cr] chroma value
Two entries are added to table 3.8 (Packed pixel formats):
type Parameter GL Data Number of Matching
Token Name Type Components Pixel Formats
-------------- ------- ---------- -------------
UNSIGNED_SHORT_8_8_APPLE ushort 3 YCBCR_422_APPLE
UNSIGNED_SHORT_8_8_REV_APPLE ushort 3 YCBCR_422_APPLE
Two entries are added to table 3.10 (UNSIGNED SHORT formats):
UNSIGNED_SHORT_8_8_APPLE:
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+-------------------------------+-------------------------------+
| 1st | 2nd |
+-------------------------------+-------------------------------+
UNSIGNED_SHORT_8_8_REV_APPLE:
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+-------------------------------+-------------------------------+
| 2nd | 1st |
+-------------------------------+-------------------------------+
One entry is added to table 3.12 (Packed pixel field assignments):
First Second Third Fourth
Format Element Element Element Element
------ ------- ------- ------- -------
YCBCR_422_APPLE luminance chroma
The new format YCBCR_422_APPLE is added to the discussion of Conversion to
RGB:
If the format is YCBCR_422_APPLE, the chroma and luminance values in each
group are converted to R, G, and B values using an undefined algorithm. This
conversion does not necessarily occur immediately as implementations are
free to pass Y'CbCr 422 formated pixels directly to hardware that is capable
of processing it. From a client stand point it can be assumed any
optimization will be transparently applied and not affect rendering results.
Pixel transfer operations will likely force conversion to RGB and will
likely negate hardware Y'CbCr acceleration. Additionally, if the format is
YCBCR_422_APPLE, the conversion algorithm may produce undefined RGB values
for final pixel of any row where the row length is not a multiple of 2.
Additions to Chapter 4 of the OpenGL 1.2.1 Specification (Per-Fragment Operations
and the Framebuffer)
Add after last paragraph of Final Conversion:
For an RGBA color and if the <type> is UNSIGNED_SHORT_8_8_APPLE or
UNSIGNED_SHORT_8_8_REV_APPLE, the conversion to Y'CbCr occurs via an
undefined reverse component conversion. The actual equation used may vary
per implementation. If the row length is odd the final pixel maybe defined
otherwise the conversion to the requested Y'CbCr output <type> is in all
ways the same and any other <type>.
Additions to the GLX Specification
None
GLX Protocol
None
Errors
None
New State
None
New Implementation Dependent State
None
Revision History
None
Implementation Support
List of OpenGL implementations supporting the GL_APPLE_ycbcr_422 extension
Original File
Original text file for the GL_APPLE_ycbcr_422 extension
Page generated on Sun Nov 20 18:39:02 2005