Microsoft Word - Rp2007-2007.doc

MOTION PICTURE AND TELEVISION ENGINEERS

595 W. Hartsdale Ave., White Plains, NY 10607

(914) 761-1100

Approved

July 27, 2007

Table of Contents

Page

Foreword ....................................................................................................................................................2

Introduction ................................................................................................................................................2

1 Scope .....................................................................................................................................................3

2 Conformance Notation ...........................................................................................................................3

3 Normative References ...........................................................................................................................3

4 Physical Interface...................................................................................................................................4

4.1 Interface Data Rate ......................................................................................................................... 4

5 Communications Protocol ......................................................................................................................5

5.1 Discussion (Informative) .................................................................................................................5

5.2 Operation of the CDP Serial Interface (Normative) ........................................................................5

Annex A "Grand Alliance" Protocol for Closed-Captioning Data (Informative) ........................................6

Annex B Bibliography (Informative) .........................................................................................................7

Page 1 of 7 pages

RP 2007-2007

SMPTE RECOMMENDED PRACTICE

Closed-Caption CDP and "Grand

Alliance" Serial Interfaces for DTV

RP 2007-2007

Page 2 of 7 pages

Foreword

SMPTE (the Society of Motion Picture and Television Engineers) is an internationally-recognized standards

developing organization. Headquartered and incorporated in the United States of America, SMPTE has

members in over 80 countries on six continents. SMPTE’s Engineering Documents, including Standards,

Recommended Practices and Engineering Guidelines, are prepared by SMPTE’s Technology Committees.

Participation in these Committees 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.

This SMPTE Engineering Document was prepared by Technology Committee D27 on Data Essence in

cooperation with the Consumer Electronics Association (CEA).

Introduction

This section is entirely informative and does not form an integral part of this Engineering Document. This

Recommended Practice defines two serial interfaces for carrying closed captioning data between DTV

devices. The CDP interface was originally specified by Section 11.3 of CEA-708-B with amendments

specified by CEB-10-A. CEA has transferred copyright on this material to SMPTE and it appears here on the

basis of that agreement.

RP 2007-2007

Page 3 of 7 pages

1 Scope

This document defines two serial interfaces which may be used to convey closed captioning streams.

The CDP Interface carries the CEA-708/SMPTE 334-2 Caption Distribution Packet (CDP). This is principally

intended for use in cases where there is a desire to provide some or all of the following information for

downstream use: caption data; caption service descriptors; and time codes. In one typical application, a

DTVCC caption server could use this interface to send CDPs to a 334M VANC encoder.

SMPTE 333M specifies an interface that is widely used for providing caption data and service information to

ATSC emission encoders. The older Grand Alliance interface can also be used for this same purpose. It is

included here as Annex B to document its use in this application.

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 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 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 suitable, 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 permissible 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.

Unless 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 References

The following standards contain provisions which, through reference in this text, constitute provisions of this

recommended practice. At the time of publication, the editions indicated were valid. All standards are subject

to revision, and parties to agreements based on this recommended practice are encouraged to investigate the

possibility of applying the most recent edition of the standards indicated below.

ATSC A/53, Part 4:2007, ATSC Digital Television Standard, Part 4 – MPEG-2 Video System Characteristics

CEA-708-C, Digital Television (DTV) Closed Captioning

SMPTE 334-2-2007, Caption Distribution Packet (CDP) Definition

RP 2007-2007

Page 4 of 7 pages

TIA-574 (2003), 9-Position Non-Synchronous Interface between Data Terminal Equipment and Data Circuit-

Terminating Equipment Employing Serial Binary Data Interchange

4 Physical Interface

The physical interface for a CDP stream shall be an TIA-574 interface. The source of the CDP stream shall be

DTE with a 9-pin "D" male connector, and the receiver of the CDP stream shall be DCE with a 9-pin "D"

female connector.

The physical interface shall only make use of the data connectors. No flow control (electrical or logical) is

used in this interface.

The devices at each end of the interface shall each provide for the parameter settings specified in Table 1.

The recommended baud rate is 38,400, but, if necessary, the interface may also be operated at 57,600 or

115,200 baud.

Table 1 – TIA 574 interface parameters

Parameter Setting

Baud rate

38,400 b/s, 57,600

b/s, or 115,200 b/s,

Data bits 8

Parity None

Stop bits 1

Start bits 1

4.1 Interface Data Rate

The data rate required to convey a CDP stream is dependent on the frame rate of the associated video as

well as the amount of service information included within each packet. The worst-case data rate would occur

at a 60 Hz frame rate, with caption service information for 15 services carried within each CDP packet. In this

case, the CDP packet size would be 159 bytes (assuming time code, caption data, and fully populated service

information, plus 4 null bytes as defined in 5.2), and require a transmission rate of 9,540 bytes per second, or

95,400 bps over a serial interface with 1 start bit and 1 stop bit. If the service information is limited to

describing only 1 service per CDP, then the CDP packet size would be 61 bytes and the maximum data rate

becomes 3,660 bytes per second, or 36,600 bps over the serial interface. It is therefore practical to carry the

CDP stream over a TIA-574 38,400 bps serial interface, although in some cases it is necessary to limit the

amount of service information included in each CDP packet.

Although 162 bytes is the longest packet that can be authored at the time of this writing, note that the actual

upper bound on CDP length is 255 bytes. Equipment manufacturers that buffer CDPs for processing should

reserve a buffer of 255 bytes to avoid possible upward compatibility issues.

TIA 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 an IBM-compatible personal computer (TIA-232 specifies neither a 9-pin connector nor speeds faster than 20

kb/s).

RP 2007-2007

Page 5 of 7 pages

5 Communications Protocol

This section describes the typical application of the CDP serial interface. Other applications are not

precluded.

5.1 Discussion (Informative)

In a typical application, captioning intentions are captured in a high level representation and then rendered

into CEA-708 captioning packets. SMPTE time code may be employed to provide means for synchronizing

the captioning intentions to the picture. With knowledge of the video frame rate and time code, the CEA-708

captioning packets may be formed into SMPTE 334-2 CDP packets, where one CDP packet corresponds to

each video frame.

During real-time streaming of pictures over a video interface and the corresponding CDP packets over the

CDP serial interface, all devices (such as VANC encoders and decoders) should process the CDP as quickly

as possible, in order to avoid accumulation of delay between the video and the captions. Specifically, a VANC

encoder should insert each complete CDP into the next available frame. Similarly, a VANC decoder should

present the complete CDP received with each video frame to its output serial interface before the beginning of

the next frame.

In systems where both the CDP packets and the individual pictures have time code values assigned, the

ATSC encoder might rely on these time code values to establish synchronization between the encoded

pictures and the captioning data that it inserts into the user data space of those coded pictures. In practice,

this is seldom done, since delays caused by transmission equipment are typically small and deterministic, and

can therefore be corrected easily without depending on time code.

5.2 Operation of the CDP Serial Interface (Normative)

When SMPTE 334-2 CDPs are conveyed by this serial interface, each CDP shall be preceded by four null

bytes (0x00). These null bytes, plus the cdp_identifier (0x9669), form a unique 48-bit sync code that allows

the serial receiver to synchronize to the CDP stream.

NOTE – These null bytes are not considered part of the CDP, and are not required when the CDP is carried by other

interfaces.

RP 2007-2007

Page 6 of 7 pages

Annex A (Informative)

"Grand Alliance" Protocol for Closed-Captioning Data

This protocol was originally developed in support of testing the DTVCC system with the “Grand Alliance”

prototype hardware; subsequently this same protocol has achieved a substantial degree of usage in fielded

systems. This system differs from SMPTE 333M in that there is no feedback from the ATSC (MPEG) encoder

to the caption generator; rather, the caption generator is driven by the timing of its input video and "pushes"

the captions towards the ATSC encoder.

The protocol operates over a standard TIA-574 type serial connection at 19200 baud, 8 bits, one stop bit, no

parity (8-N-1). The caption data is multiplexed into the DTV bitstream in approximate synchronization with the

video frames that arrive simultaneously. It is the responsibility of the sender to ensure that the amount of

captioning data that is sent to the ATSC (MPEG) encoder does not exceed the channel capacity allocated in

A/53. The behavior of the ATSC encoder in the case of too much captioning data is not specified.

No flow control is used or supported. If there is no data to send, it is most efficient to send no packets to the

ATSC encoder. In accordance with the A/53 and CEA-708 standards, the ATSC encoder will use the

cc_valid=0 method to maintain the captioning channel bandwidth in the case of underflow on this input.

The format of the packets on this interface is as follows (where each field is an 8-bit byte):

SOH TYPE COUNT Data_1 ...... Data_n Check EOT

where:

SOH 0x01, ASCII Start-of-Header character

TYPE ASCII '1' for NTSC field 1

ASCII '2' for NTSC field 2

ASCII ‘A’ for ATVCC (see Note 1)

COUNT Count of all packet bytes, including SOH and EOT

Data_# Data bytes

Check One-byte checksum that satisfies the following: the modulo-256 sum of all bytes in

the packet, including the SOH and EOT, is zero

EOT 0x04, ASCII End-of-Transmission character

Each packet contains exactly one CEA-708 packet, or an even number of characters of CEA-608 closed

caption data. Both field-1 and field-2 (XDS) 608 caption data are supported on this interface. The minimum

value of COUNT is 5 (no actual data bytes), the maximum value is 135 (see Note 2).

NOTES

1. In this protocol, the ‘A’ refers to captions for DTV, originally known as ATV (advanced television). At the time of

writing this Annex one caption encoder manufacturer has implemented a variant of this protocol using a TYPE code

‘D’ to indicate DTV captions. Designers of new equipment that will receive this interface signal are encouraged to

support packets of either type ‘A’ or ‘D’ in order to accommodate the widest variety of fielded equipment.

2. Maximum packet length accepted by receiving equipment is typically in the range of 128 to 150, with 135

bytes being the most interoperable value for current equipment at the time of writing this guideline.

Longer packets may be used successfully in some systems but system implementers are advised to

check with the manufacturers that the maximum packet length that may be generated by the caption

encoder is accepted by the ATSC (MPEG) encoder.

RP 2007-2007

Page 7 of 7 pages

Annex B (Informative)

Bibliography

ATSC A/65C, Program and System Information Protocol for Terrestrial Broadcast and Cable, Revision C

SMPTE 333M-1999, Television — DTV Closed-Caption Server to Encoder Interface