| 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 <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. |
| |
| New Procedures and Functions |
| |
| None |
| |
| New Tokens |
| |
| 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 |
| |