1、 Copyright 2008 by THE SOCIETY OF MOTION PICTURE AND TELEVISION ENGINEERS 595 W. Hartsdale Ave., White Plains, NY 10607 (914) 761-1100 Approved April 25, 2008 Table of Contents Page Foreword . 2 1 Scope 3 2 Conformance Notation 3 3 Normative References 3 4 Definitions . 4 4.1 Acronyms and Abbreviati
2、ons 4 4.2 Definition of Terms 4 4.3 Section and Data Structure Syntax Notation 4 5 Physical Interface 4 5.1 9-Pin Connector 4 5.2 Inteface Parameters 5 6 Communications Protocol . 5 6.1 Closed-Caption Packet . 5 6.2 Encoder Requests and Responses 7 6.3 Determination of the Value x for SYNx (Informat
3、ive) . 8 6.4 Bite Rate Jitter to Reach Average Bit Rate (Normative) 9 6.5 Startup Case . 9 6.6 Normal Case . 9 6.7 Server Response (Informative) 10 6.8 Timeout . 10 6.9 Caption Services. 10 6.10 Protocol State Tables. 11 Annex A Bibliography (Informative) . 13 Annex B Related Standards (Informative)
4、 . 14 Page 1 of 14 pages SMPTE 333-2008Revision of SMPTE 333M-1999 SMPTE STANDARD DTV Closed-Caption Server to Encoder Interface SMPTE 333-2008 Page 2 of 14 pages Foreword SMPTE (the Society of Motion Picture and Television Engineers) is an internationally-recognized standards developing organizatio
5、n. Headquartered and incorporated in the United States of America, SMPTE has members in over 80 countries on six continents. SMPTEs Engineering Documents, including Standards, Recommended Practices and Engineering Guidelines, are prepared by SMPTEs Technology Committees. Participation in these Commi
6、ttees is open to all with a bona fide interest in their work. SMPTE cooperates closely with other standards-developing organizations, including ISO, IEC and ITU. SMPTE Engineering Documents are drafted in accordance with the rules given in Part XIII of its Administrative Practices. SMPTE Standard 33
7、3 was prepared by Technology Committee D27. SMPTE 333-2008 Page 3 of 14 pages 1 Scope This standard defines a serial interface for transmission of CEA-708 digital television closed caption data from a caption server to video encoder to be used for populating the closed-caption structure in the compr
8、essed video stream. 2 Conformance Notation Normative text is text that describes elements of the design that are indispensable or contains the conformance language keywords: “shall“, “should“, or “may“. Informative text is text that is potentially helpful to the user, but not indispensable, and can
9、be removed, changed, or added editorially without affecting interoperability. Informative text does not contain any conformance keywords. All text in this document is, by default, normative, except: the Introduction, any section explicitly labeled as “Informative“ or individual paragraphs that start
10、 with “Note:” The keywords “shall“ and “shall not“ indicate requirements strictly to be followed in order to conform to the document and from which no deviation is permitted. The keywords, “should“ and “should not“ indicate that, among several possibilities, one is recommended as particularly suitab
11、le, without mentioning or excluding others; or that a certain course of action is preferred but not necessarily required; or that (in the negative form) a certain possibility or course of action is deprecated but not prohibited. The keywords “may“ and “need not“ indicate courses of action permissibl
12、e within the limits of the document. The keyword “reserved” indicates a provision that is not defined at this time, shall not be used, and may be defined in the future. The keyword “forbidden” indicates “reserved” and in addition indicates that the provision will never be defined in the future. A co
13、nformant implementation according to this document is one that includes all mandatory provisions (“shall“) and, if implemented, all recommended provisions (“should“) as described. A conformant implementation need not implement optional provisions (“may“) and need not implement them as described. Unl
14、ess otherwise specified the order of precedence of the types of normative information in this document shall be as follows. Normative prose shall be the authoritative definition. Tables shall be next, followed by formal languages, then figures, and then any other language forms. 3 Normative Referenc
15、es The following standards contain provisions which, through reference in this text, constitute provisions of this standard. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this standard are encouraged to invest
16、igate the possibility of applying the most recent edition of the standards indicated below. SMPTE 334-2-2007, Caption Distribution Packet (CDP) Definition CEA-708-C (2007), Digital Television (DTV) Closed Captioning TIA 574 (2003), 9-Position Non-Synchronous Interface between Data Terminal Equipment
17、 and Data Circuit-Terminating Equipment Employing Serial Binary Data Interchange11TIA 574 is an extension of TIA-232 (2002) that specifies a 9-pin connector and speeds faster than 20 kb/s; i.e., an RS-232 port on a personal computer (TIA-232 specifies neither a 9-pin connector nor speeds faster than
18、 20 kb/s). SMPTE 333-2008 Page 4 of 14 pages 4 Definitions 4.1 Acronyms and Abbreviations The following acronyms and abbreviations are used within this specification: ATSC: Advanced Television Systems Committee. DTVCC: Digital Television Closed Captioning. 4.2 Definition of Terms The following terms
19、 are used throughout this standard: caption server: A device that delivers DTVCC formatted data for insertion in picture level user-data within an MPEG video elementary stream. cc_data triplet: A sequence of three 8-bit bytes which consists of an identifier/flag byte plus two data bytes. Normally ju
20、st referred to as a “triplet” in this standard. video encoder: A device that encodes video into a compressed format. 4.3 Section and Data Structure Syntax Notation This standard contains symbolic references to syntactic elements. These references are typographically distinguished by the use of a dif
21、ferent font (e.g., restricted), may contain the underscore character (e.g., sequence_end_code), and may consist of character strings that are not English words (e.g., dynrng). 4.3.1 Syntactic Notation The formats of sections and data structures in this standard are described using a C-like notationa
22、l method employed in ISO/IEC 13818-1. 4.3.2 Numeric Notation Within this standard, conventional numbers denote decimal values, numbers preceded by 0x are to be interpreted as hexadecimal values and numbers within single quotes (e.g., 10010100) are to be interpreted as a string of binary digits. 5 Ph
23、ysical Interface The physical interface between the caption server and the video encoder shall be an TIA 574 interface, with restrictions as specified in 5.2. 5.1 9-Pin Connector The encoder shall be DCE and provide a female 9-pin connector as described in TIA 574 with the pin-out described in Table
24、 1. SMPTE 333-2008 Page 5 of 14 pages Table 1 9-pin connector pin-out Pin Signal Signal source Description 1 NC N/A Not connected 2 TXD Video encoder Serial data transmit 3 RXD Caption server Serial data receive 4 NC N/A Not connected 5 GND N/A Signal ground6 NC N/A Not connected 7 RTS Caption serve
25、r Request to send. The video encoder shall ignore the state of this pin. 8 CTS Video encoder Clear to send. When asserted, the caption server may transmit data to the video encoder. 9 NC N/A Not connected 5.2 Interface Parameters The video encoder and caption server shall each provide an TIA-574 int
26、erface with the parameter settings from Table 2. Table 2 TIA 574 interface parameters Parameter Setting Baud rate 38,400 b/s Data bits 8 Parity None Stop bits 1 Start bits 1 6 Communications Protocol The caption server shall provide data to the video encoder as the video encoder requests it. The com
27、munications protocol is described below. 6.1 Closed-Caption Packet The caption server shall provide captioning data to the video encoder using the syntax described in Table 3. This data shall consist of one or more fields-worth of data. The data may arrive in any field order per CEA-708-C 4.4.2. SMP
28、TE 333-2008 Page 6 of 14 pages Table 3 Bit stream syntax for closed-caption packet Syntax Bits Format closed_caption_packet() SOH 8 0x01 cc service available 1 bslbf cc messagetype 7 uimsbf cc messagelength 8 uimsbf if (cc_message_type = 0x44) for (i = 0; i cc_message_length - 3; i += 3) one bits 5
29、11111 cc_valid 1 bslbf cc_type 2 bslbf data_byte_1 8 bslbf data_byte_2 8 bslbf else if (cc_message_type = 0x53) reserved 1 1 csn_size 1 uimsbf If (csn_size = 1) reserved 1 1 caption_service_number 5 uimsbf els caption_service_number 6 uimsbf service_data_byte_1 8 bslbf service_data_byte_2 8 bslbf se
30、rvice_data_byte_3 8 bslbf service_data_byte_4 8 bslbf service_data_byte_5 8 bslbf service_data_byte_6 8 bslbf else for (i = 0; i N; i+) filerbyte8 bslbf packet_checksum 8 uimsbf EOT 8 0x04 SOH ASCII SOH, fixed packet prefix. cc_service_available This 1-bit field is set to 1 to indicate that the capt
31、ion server has caption service information available for transfer. cc_message_type This 7-bit unsigned integer specifies the type of table, based on Table 4. SMPTE 333-2008 Page 7 of 14 pages Table 4 cc_message_type values cc_message_type Meaning 0x00 0x43 SMPTE reserved 0x44 DTVCC/NTSC data 0x45 0x
32、52 SMPTE reserved 0x53 Caption service data 0x54 0x6f SMPTE reserved 0x70 0x7f User reserved cc_message_length 8-bit field specifying the number of bytes in this packet, SOH through EOT inclusive. one_bits These fields shall be set to all 1s. cc_valid This 1-bit field indicates that the subsequent d
33、ata_byte_1 and data_byte_2 are valid. This field carries the same meaning as CEA-708-C, 4.4.1. cc_type This 2-bit field indicates the type of data carried in data_byte_1 and data_byte_2. This field carries the same meaning as CEA-708-C, 4.4.1. data_byte_1, data_byte_2 These fields carry DTVCC or NTS
34、C data. These fields carry the same meaning as CEA-708-C, 4.4.1 and 4.4.3. csn_size This 1-bit field signals the size of the caption_service_number field. The value of 1 shall indicate 5-bits, and the value of 0 shall indicate 6-bits. caption_service_number This field carries the caption service num
35、ber for the service delivered by the following 6 service data bytes. This field shall have a value of 0x00 when the service data applies to the line 21 (CEA-608) service. Otherwise, this field shall have a value between 0x01 - 0x10 inclusive, when csn_size = 1, and 0x01 - 0x3F inclusive when csn_siz
36、e = 0. Note that the least significant bits of this field are a duplication of the least significant bits of service_data_byte_4 (as specified in SMPTE 334-2) when the service data applies to one of the DTVCC services. service_data_byte_n These 6 fields carry caption service data for one service. Th
37、ese fields carry the same meaning as SMPTE 334-2, 5.5. filler_byte This 8-bit field carries reserved information when cc_message_type is marked “reserved” in Table 4. These bytes shall take the value of 0xFF. packet_checksum This 8-bit field shall contain the 8-bit value necessary to make the arithm
38、etic sum of the entire packet (SOH through EOT, inclusive) modulo 256 equal zero. EOT ASCII EOT, fixed packet postfix. 6.2 Encoder Requests and Responses The video encoder shall request caption data and indicate status from the closed-caption server via messages formatted according to the syntax def
39、ined in Table 5. These messages are also used by the video encoder to indicate the status of the last transfer from the closed-caption server. SMPTE 333-2008 Page 8 of 14 pages Table 5 Bit-stream syntax for encoder requests and responses Syntax Bits Format encoder_req_resp() service_data_inhibit 1 b
40、slbf req_or_resp 7 uimsbf service_data_inhibit When set to 1, the caption server shall not send a closed_caption_packet() with message_type = 0x53 in response(s) to this encoder_req_resp(). If req_or_resp = 0x06 or req_or_resp = 0x15, this field shall be ignored. req_or_resp This 7-bit field shall h
41、ave values from Table 6. Table 6 Encoder requests and responses Value Name Meaning 0x06 ACK Previous transfer acknowledged 0x15 NAK Previous transfer was not received, or was not completely received, or was received with an invalid checksum. 0x1a SYN01Transfer closed_caption_packet() with cc_message
42、_type = 0x44 and cc_message_length = 0x05. 0x1b SYN5 Transfer closed_caption_packet() with cc_message_type = 0x44 and cc_message_length = 0x14. 0x1c SYN10 Transfer closed_caption_packet() with cc_message_type = 0x44 and cc_message_length = 0x23. 0x1d SYN15 Transfer closed_caption_packet() with cc_me
43、ssage_type = 0x44 and cc_message_length = 0x32. 0x1e SYN20 Transfer closed_caption_packet() with cc_message_type = 0x44 and cc_message_length = 0x41. 0x1f SYN25 Transfer closed_caption_packet() with cc_message_type = 0x44 and cc_message_length = 0x50. 1Note that SYNx is used to refer to SYN0, SYN5,
44、SYN10, SYN15, SYN20, or SYN25. 6.3 Determination of the Value x for SYNx (Informative) A caption data stream compliant with CEA-708-C is required to be at 9600 bps regardless of the frame rate of the video signal to be compressed. This Standard is designed to allow an encoder to request the CEA-708-
45、C data one video frame at a time. The different SYNx commands support the different encoder video frame rates. For SYNx, the x indicates how many cc_data triplets are to be sent from the server to the encoder. A SMPTE 333-2008 Page 9 of 14 pages message typically is comprised of CEA-608-C triplets f
46、ollowed by CEA-708-C triplets and CEA-708-C filler triplets. The relationship between x and the video frame rate can be expressed as follows: ()()byteperbitstripletperbytesfpsbpsx829600= For example, at 60 fps, x is 10; 30 fps, x is 20. It is expected that the video encoder will reframe caption data
47、 when necessary to handle film-based material while pulldown repetitions are present and being removed to create 24 frames per second encoded output. It is noted that the video encoder must handle the resultant reframing when video material without pulldown is edited into film-based material breakin
48、g the pulldown cadence, per CEA-708-C, 4.4.2. The reader is referred to 4.4.1 and 4.4.2 of CEA-708-C for further information. 6.4 Bit Rate Jitter to Reach Average Bit Rate Implementers must remember that each component of this system (a video encoder and a closed caption server) are each synchronize
49、d independently to the same video source. As the caption server may be slaved via time code samples rather than direct video, the situation is even less deterministic. As a result, each component must expect some unexpected behavior from the other, especially when dealing with film material delivered via 29.97 fps video. 6.4.1 Video Encoder Required Jitter Although CEA
