ImageVerifierCode 换一换
格式:PDF , 页数:25 ,大小:577.91KB ,
资源ID:591490      下载积分:10000 积分
快捷下载
登录下载
邮箱/手机:
温馨提示:
如需开发票,请勿充值!快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。
如填写123,账号就是123,密码也是123。
特别说明:
请自助下载,系统不会自动发送文件的哦; 如果您已付费,想二次下载,请登录后访问:我的下载记录
支付方式: 支付宝扫码支付 微信扫码支付   
注意:如需开发票,请勿充值!
验证码:   换一换

加入VIP,免费下载
 

温馨提示:由于个人手机设置不同,如果发现不能下载,请复制以下地址【http://www.mydoc123.com/d-591490.html】到电脑端继续下载(重复下载不扣费)。

已注册用户请登录:
账号:
密码:
验证码:   换一换
  忘记密码?
三方登录: 微信登录  

下载须知

1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。
2: 试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。
3: 文件的所有权益归上传用户所有。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 本站仅提供交流平台,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

版权提示 | 免责声明

本文(CEA-799-A-2006 On-Screen Display Specifications《屏幕视控系统规范》.pdf)为本站会员(lawfemale396)主动上传,麦多课文库仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知麦多课文库(发送邮件至master@mydoc123.com或直接QQ联系客服),我们立即给予删除!

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

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