CEA-799-A-2006 On-Screen Display Specifications《屏幕视控系统规范》.pdf

上传人:lawfemale396 文档编号:591490 上传时间:2018-12-16 格式:PDF 页数:25 大小:577.91KB
下载 相关 举报
CEA-799-A-2006 On-Screen Display Specifications《屏幕视控系统规范》.pdf_第1页
第1页 / 共25页
CEA-799-A-2006 On-Screen Display Specifications《屏幕视控系统规范》.pdf_第2页
第2页 / 共25页
CEA-799-A-2006 On-Screen Display Specifications《屏幕视控系统规范》.pdf_第3页
第3页 / 共25页
CEA-799-A-2006 On-Screen Display Specifications《屏幕视控系统规范》.pdf_第4页
第4页 / 共25页
CEA-799-A-2006 On-Screen Display Specifications《屏幕视控系统规范》.pdf_第5页
第5页 / 共25页
亲,该文档总共25页,到这儿已超出免费预览范围,如果喜欢就下载吧!
资源描述

1、 CEA Standard On-Screen Display Specification CEA-799-A R-2012 July 2006 NOTICE Consumer Electronics Association (CEA) Standards, Bulletins and other technical publications are designed to serve the public interest through eliminating misunderstandings between manufacturers and purchasers, facilitat

2、ing interchangeability and improvement of products, and assisting the purchaser in selecting and obtaining with minimum delay the proper product for his particular need. Existence of such Standards, Bulletins and other technical publications shall not in any respect preclude any member or nonmember

3、of CEA from manufacturing or selling products not conforming to such Standards, Bulletins or other technical publications, nor shall the existence of such Standards, Bulletins and other technical publications preclude their voluntary use by those other than CEA members, whether the standard is to be

4、 used either domestically or internationally. Standards, Bulletins and other technical publications are adopted by CEA in accordance with the American National Standards Institute (ANSI) patent policy. By such action, CEA does not assume any liability to any patent owner, nor does it assume any obli

5、gation whatever to parties adopting the Standard, Bulletin or other technical publication. This document does not purport to address all safety problems associated with its use or all applicable regulatory requirements. It is the responsibility of the user of this document to establish appropriate s

6、afety and health practices and to determine the applicability of regulatory limitations before its use. This document is copyrighted by the Consumer Electronics Association (CEA) and may not be reproduced, in whole or part, without written permission. Federal copyright law prohibits unauthorized rep

7、roduction of this document by any means. Organizations may obtain permission to reproduce a limited number of copies by entering into a license agreement. Requests to reproduce text, data, charts, figures or other material should be made to CEA. (Formulated under the cognizance of the CEA R4.8 DTV I

8、nterface Subcommittee.) Published by CONSUMER ELECTRONICS ASSOCIATION 2012 Technology Phone +41 22 730 6141; Fax +41 22 730 5194; Internet http:/www.itu.org; Email salesitu.int 2.3 Definitions For the purposes of this document, the following definitions apply. Byte 8 bits of data Quadlet Four bytes

9、of data A number with a subscript of “16” indicates that the number is hexadecimal. 2.4 Symbols and Abbreviations bslbf Bit string, left bit first CLUT Color Look-up Table ILUT Image Look-up Table lsb least significant bit msb most significant bit OSD On-Screen Display RLE Run Length Encoding RF RLE

10、_Flag uimsbf Unsigned integer, most significant bit first 2.5 Compliance Notation As used in CEA-761-B, “shall” denotes a mandatory provision. “Should” denotes a provision that is recommended but not mandatory. “May” denotes a feature whose presence does not preclude compliance, that may or may not

11、be present at the option of the implementor. “Optional” denotes items that may or may not be present in a compliant implementation. The 00 parameter denotes unused bits. Unused bits denoted by the 00 parameter shall be set to zero, and reserved for future use until defined. 1CEA-799-A 3 Format of OS

12、D Data 3.1 Subframe Types The defined subframe types are: set_OSD_pixel_format: Establishes the format of the basic 16-bit pixels that make up the data definition to follow, and the size and color depth of the OSD grid. For OSD grid formats with either 4- or 8-bit color depths, the subframe shall co

13、ntain either a 4- or 8-bit Color Lookup Table (CLUT). 4_bit_OSD_data: Defines 4-bit pixels in a rectangular region. Each 4-bit pixel represents a color/alpha blend value derived by indirection through the 4- bit CLUT. 8_bit_OSD_data: Defines 8-bit pixels in a rectangular region. Each 8-bit pixel rep

14、resents a color/alpha blend value derived by indirection through the 8- bit CLUT. uncompressed_16_bit_data: Defines raw uncompressed 16-bit OSD data in a rectangular region. Each 16-bit pixel represents a color/alpha blend value. fill_region_with_constant: Defines a rectangular region to fill with a

15、 16-bit constant with a format defined by pixel_format. clear_OSD: Loads the complete OSD with a transparent value. RLE_8_bit_OSD_data: Defines 8-bit pixels (compressed using RLE) in a rectangular region. Each 8-bit pixel represents a color/alpha blend value derived by indirection through the 8-bit

16、CLUT. RLE_16_bit_OSD_data: Defines 16-bit pixels (compressed using RLE) in a rectangular region. Each 16-bit pixel represents a color/alpha blend value. set_image_look_up_table: Transfers an Image Lookup Table from the OSD Producer to the OSD Consumer. draw_image: Requests the OSD Consumer to render

17、 the specified images from the Image Lookup Table. 3.2 Subframe typeCode The type of each subframe is identified by a typeCode field, as defined in Table 1. All subframes in this protocol, as well as ones defined in future extensions, are formatted with the 8-bit typeCode and 24-bit dataLength in th

18、e first quadlet. An OSD Consumer that encounters a subframe with an unknown typeCode shall use the dataLength to skip that subframe. typeCode Meaning 0 Reserved 1 set_OSD_pixel_format2 4_bit_OSD_data3 8_bit_OSD_data4 uncompressed_16_bit_data5 fill_region_with_constant 6 clear_OSD7 RLE_8_bit_OSD_data

19、 8 RLE_16_bit_OSD_data9 set_image_look_up_table10 draw_image 11-255 Reserved for future use Table 1 typeCode Coding 2CEA-799-A 3.3 Subframe Processing The OSD Consumer shall process subframes in the order received. An OSD Consumer may not have buffer space sufficient to hold a complete frame of OSD

20、data; if that is the case, processing of subframes as they arrive will be necessary. In any case, the OSD Consumer should process each subframe as it arrives. 3.4 Subframe Syntax and Definition 3.4.1 set_OSD_pixel_format Subframe The OSD Producer device shall use the set_OSD_pixel_format subframe to

21、 set the pixel format, color depth, and CLUT (if applicable) for subsequent delivery of OSD data. The set_OSD_pixel_format subframe shall be formatted as shown in Figure 1 when OSD_layout specifies a 16-bit color depth. typeCode dataLengthOSD_layoutfill_valuereservedoverlay_format pixel_format 0 mix

22、msb (first) lsbcsswbufFigure 1 set_OSD_pixel_format Subframe, 16-bit Color Depth The set_OSD_pixel_format subframe shall be formatted as shown in Figure 2 when OSD_layout specifies a 4-bit color depth. typeCode dataLengthOSD_layoutfill_valuereservedoverlay_format pixel_format 0.CLUT14 CLUT15CLUT0 CL

23、UT1mixmsb (first) lsbcs swbufFigure 2 set_OSD_pixel_format Subframe, 4-bit Color Depth The set_OSD_pixel_format subframe shall be formatted as shown in Figure 3 when OSD_layout specifies an 8-bit color depth. 3CEA-799-A typeCode dataLengthOSD_layoutfill_valuereservedoverlay_format pixel_format 0.CLU

24、T254 CLUT255CLUT0 CLUT1mixmsb (first) lsbcs swbufFigure 3 set_OSD_pixel_format Subframe, 8-bit Color Depth The source shall send the set_OSD_pixel_format subframe prior to the initial delivery of OSD data to establish the format for the data to follow. The subframe shall also be sent prior to delive

25、ry of OSD data in a different pixel format. Note that it is not possible to define one OSD image as a mixture of different pixel formats (pixel_format 0 and 1, for example). The set_OSD_pixel_format subframe also selects one of possibly several OSD buffer formats offered by the OSD Consumer. typeCod

26、e for the set_OSD_pixel_format subframe is 0116.dataLength shall reflect the number of bytes in the subframe following the dataLength field itself, either 8, 40, or 520, depending upon the color depth defined in OSD_layout. OSD_layout specifies the OSD frame buffer dimensions and color depth and sha

27、ll be as specified in Table 2. OSD_layout Meaning 0 640 x 480 x 4 1 640 x 480 x 8 2 640 x 480 x 16 3 1280 x 720 x 8 4 1280 x 720 x 16 5 1920 x 1080 x 8 6 1920 x 1080 x 16 7 960 x 540 x 8 8 960 x 540 x 16 9-255 Reserved for future use Table 2 OSD Layout Coding overlay_format specifies the way the OSD

28、 Consumer should overlay the selected grid format over decoded video. Table 3 defines coding for overlay_format. Support for formats 1 and 2 is optional. All devices shall support format 0. 4CEA-799-A overlay_format Meaning 0 no stretch requested 1 Stretch horizontally to 14:9 2 Stretch horizontally

29、 to 16:9 3-255 Reserved for future use Table 3 Overlay Format Coding pixel_format shall be as specified in Table 4. The format for the 16 bit pixel for each pixel format is as shown in Figure 4. pixel_format Meaning 0 Y:Cb:Cr= 6:5:5 1 :Y:Cb:Cr= 2:6:4:4 2 :Y:Cb:Cr= 4:6:3:3 3-255 Reserved for future u

30、se Table 4 Pixel Format Coding A zero value for Y indicates lowest luminance (most black). A maximum value for Y (all ones) indicates highest luminance level. Y is related to primary color signals (R, G, B) in accordance with the colorimetry sections of ITU-R BT.709-5, the standard for DTV, or ITU-R

31、 BT.601-5, the standard for NTSC. An OSD consumer may only support one of these standards; as the complexity of requiring support for both was deemed excessive for the improvement in quality that would result. Cr and Cbare chrominance vectors related to primary color signals (R, G, B) in accordance

32、with ITU-R BT.709-5 or ITU-R BT.601-5. For pixel_format 0 only, any pixel with a Y value of zero shall be transparent. Pixels with non-zero values of Y shall be opaque. pixel_format 0msb lsbmsb lsbmsb lsbpixel_format 1pixel_format 2Y CrCbYCrCbYCbCrFigure 4 Pixel Format Bit Fields is an alpha level a

33、ssociated with pixels in pixel_format 1 or 2. values for pixel_format 1 are defined in Table 5. For pixel_format 2, values in between 0 and all-ones indicate the mix weight between the OSD pixel and decoded video for each pixel. A zero value for indicates transparent. The all-ones value indicates op

34、aque. The interpolation between zero and all ones should be approximately linear. 5CEA-799-A The mix parameter in the set_OSD_pixel_format subframe is used with pixel_format 1 to specify the alpha-blend value to use for pixels that are neither transparent nor opaque. A value of zero for mix indicate

35、s transparent. An all-ones value indicates opaque. The interpolation between zero and all ones should be approximately linear. The mix parameter shall be ignored in an OSD Consumer for pixel_format 0 and pixel_format 2. Table 5 defines the interpretation of the 2-bit alpha field in pixels formatted

36、as pixel_format 1. pixel Meaning 0 Opaque 1 Mix with video using mix parameter in the set_OSD_pixel_format subframe 2 Transparent3 Reserved for future use Table 5 Field Interpretation for pixel_format 1 cs defines the chrominance standard used in the OSD Producer, and acts to notify the OSD Consumer

37、 that it should interpret YCbCr data in accordance with the referenced standard, if possible. cs is defined in Table 6. cs Color Standard 0 ITU-R BT.709-5 1 ITU-R BT.601-5Table 6 Colorimetry Standards buf indicates whether data is placed into the buffer currently being used for output (buf=0) or int

38、o a buffer that is not currently being used for output (buf=1). The buf and sw bits together specify how the data update will take place as shown in Table 7. When double buffering is not supported in the OSD consumer, buf=1 has no meaning. In this case, the OSD consumer may ignore subframes with buf

39、=1. buf sw Rule 0 0 Shall put data into the active buffer immediately 0 1 Should start to put data into the active buffer synchronized with the start of the next vertical retrace 1 0 Shall put data into an off-screen buffer 1 1 Shall put data into an off-screen buffer and then swap with the active b

40、uffer, synchronized with the start of the next vertical retrace Table 7 buf/sw Coding sw indicates when the data update will take place. fill_value is formatted according to OSD_Layout as shown in Table 8. OSD_layout fill_value Format 0 4 bits (right justified) 1, 3, 5, 7 8 bits (right justified) 2,

41、 4, 6, 8 as defined by pixel_format Coding 9-255 Reserved Table 8 fill_value Coding 6CEA-799-A Processing within the OSD Consumer of the set_OSD_pixel_format subframe shall conditionally cause the OSD frame buffers to be initialized to the fill_value value provided. Processing the first set_OSD_pixe

42、l_format subframe after establishing the OSD connection shall have the effect of setting the OSD frame buffers to the fill pixel value provided in the command. Processing a subsequent set_OSD_pixel_format subframe that changes the pixel_format or OSD_layout, the OSD Consumer shall initialize the OSD

43、 buffers to the fill pixel value provided. When processing a subsequent set_OSD_pixel_format subframe that changes only the mix field or CLUT data, previously defined pixel data values do not change. The new CLUT data applies only to the OSD Images (4 bit or 8 bit) received subsequent to the recepti

44、on of set_OSD_pixel_format. OSD Images rendered using previous CLUT data may be changed or may be left unchanged. CLUTN is a color-lookup table entry. CLUT entries are 16-bits, formatted according to the pixel format defined in pixel_format. 3.4.2 4-bit OSD Data Subframe Figure 5 defines the format

45、of the 4_bit_OSD_data subframe, used to deliver 4-bit pixels from OSD Producer to OSD Consumer. typeCode dataLengthX_locwidth heightpixel0pixelN zeroPad1zeroPad2.0016buf0swpixel1 pixel2 pixel3 . . . .Y_locmsb (first)lsbFigure 5 4-bit OSD Data Subframe Format typeCode shall be set to value 0216, indi

46、cating the 4_bit_OSD_data subframe format. The 24-bit dataLength field shall be set to indicate the number of data bytes in the remainder of the subframe. The subframe shall be padded so that the next subframe address is quadlet aligned. Based on the height and width parameters (if both are odd numb

47、ers), the least significant 4 bits in the last data byte may be unused. X_loc is the 12-bit X-coordinate (column number) within the image buffer in the buffer indicated by buf. The coordinate system is defined with 0,0 in the upper left corner. Y_loc is the 12-bit Y-coordinate (row number) within th

48、e image buffer in the buffer indicated by buf. 7CEA-799-A PPPPPPPPPPPPPPPPPPPPPPPPY_locX_locwidthheight012345678910112 13 14 15 16 1718 19 20 21 22 23Figure 6 Pixel Data Display Order buf and sw are the same as defined in Section 3.4.1. width is a 16-bit unsigned integer number representing the widt

49、h, in pixels, of the OSD region being defined. Value zero is undefined. height is a 16-bit unsigned integer number representing the height, in pixels, of the OSD region being defined. Value zero is undefined. pixel0 through pixelN are 4-bit pixel values. The pixels shall be listed in a scan order that is left to right and top to bottom. An illustration of the order is shown in Figure 6. In this particular example, width has a value of 6 and height has a value of 4. The display values for each shall be expanded through the 4-bit to 16-bit C

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 标准规范 > 国际标准 > 其他

copyright@ 2008-2019 麦多课文库(www.mydoc123.com)网站版权所有
备案/许可证编号:苏ICP备17064731号-1