Name 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 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 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 . 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 ? 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. New Procedures and Functions None New Tokens Accepted by the 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 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 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 is in all ways the same and any other . Additions to the GLX Specification None GLX Protocol None Errors None New State None New Implementation Dependent State None Revision History None