Файл: Audio and Radio Engineering.pdf

8-28 Audio Networking

Mbits/s of payload capacity on 270-Mbits/s links and 270 Mbits/s of payload capacity on 360-
Mbits/s links.

A 53-word header data packet is inserted in the ancillary data space. The rest of the ancillary

data space is left free to carry other ancillary data. The 53-word SDTI header data structure is in
accordance with the SMPTE 291M ancillary data specification, shown in Figure 8.2.10. The
specification contains an ancillary data flag (ADF), a data ID (DID) specified as code 140h for
SDTI, secondary data ID (SDID) specified as code 101h for SDTI, and 46 words for header data.
A checksum for data integrity checking also is included.

The 46 words of header data define source and destination addresses and the formatting of the

payload (Figure 8.2.11). Line number and line number CRC bits are used to ensure data continu-
ity. The code identifies the size of the payload to be either 1440 words or 1920 words long. An
authorized address identifier (AAI) defines the addressing method utilized.

Currently, the Internet Protocol (IP) addressing scheme is defined for SDTI. The source and

destination addresses are 128 bits long, allowing essentially a limitless number of addressable
devices to be supported.

The bock type identifies whether data is arranged in fixed-sized data blocks—with or without

error correction code (ECC)—or variable-sized data blocks. In the case of fixed-sized blocks, the
block type also defines the number of blocks that are transported in one video line. The block
type depends on the data type of the payload. 

Between SAV and EAV, the payload itself is inserted. The payload can be of any valid data

type registered with SMPTE. The data structure of the payload includes a data type code preced-
ing the data block, shown in Figure 8.2.12a. In addition, separator, word count, and end code are
required for data types that feature variable-sized blocks (Figure 8.2.12b).

SMPTE 305M does not specify the data structure inside the data block, which is left to the

registrant of the particular data type.

A significant revision of SMPTE 305M was undertaken in March 2000. The document, pro-

posed at this writing, updated normative references and provided additional detail on the opera-
tion elements of the SDTI system. The revision was intended to keep the standard in
conformance with related documents and to address certain implementation issues.

Figure 8.2.9

 SMPTE 259M prin-

cipal video timing parameters.
(

From [12]. Used with permis-

sion.)

Downloaded from Digital Engineering Library @ McGraw-Hill (www.digitalengineeringlibrary.com)

Copyright © 2004 The McGraw-Hill Companies. All rights reserved.

Any use is subject to the Terms of Use as given at the website.

Serial Digital Video/Audio Systems

Serial Digital Video/Audio Systems 8-29

8.2.4b

SDTI in Computer-Based Systems

Transferring material to and from computer-based nonlinear editing (NLE)/compositing systems
and video servers is one of the primary uses of SDTI [12]. Computers can interface with other
SDTI devices through the use of an adapter. Typically, an SDTI-enabled computer-based NLE
system will contain the following components:

•

A CPU motherboard

•

A/V storage and a controller to store the digital audio and compressed video material

•

Editing board with audio/video I/O, frame buffer, digital video codecs, and processors

•

Network and console display adapters

•

SDI/SDTI adapter

Figure 8.2.10

 Header data packet

structure. (

From  [12].  Used with per-

mission.)

Figure 8.2.11

 SDTI header data structure. (

From [9]. Used with permission.)

Downloaded from Digital Engineering Library @ McGraw-Hill (www.digitalengineeringlibrary.com)

Copyright © 2004 The McGraw-Hill Companies. All rights reserved.

Any use is subject to the Terms of Use as given at the website.

Serial Digital Video/Audio Systems

8-30 Audio Networking

As an example of a typical SDI/SDTI hardware adapter, consider the PCI-bus implementation

illustrated in Figure 8.2.13. With the PCI adapter installed, the computer can share and move SDI
and SDTI streams with and among other devices and terminals. Such a configuration also can be
used to transcode from SDI to SDTI, and vice-versa.

8.2.4c

SDTI Content Package Format

The SDTI content package format (SDTI-CP) is an extension of the basic SDTI system that
allows for package-based delivery of data signals. The SMPTE developed a collection of stan-
dards that define the technology and protocol of SDTI-CP. The applicable documents include the
following:

•

SMPTE 326M: SDTI Content Package Format

•

SMPTE 331M: Element and Metadata Definitions for the SDTI-CP

•

SMPTE 332M: Encapsulation of Data Packet Streams over SDTI

•

Recommended Practice RP 204: SDTI-CP MPEG Decoder Templates

The general parameters of these documents are described in the following sections.

SMPTE 326M

The SDTI-CP standard specifies the format for the transport of content packages (CP) over the
serial digital transport interface [13]. Known as SDTI-CP, this format is a packaging structure for
the assembly of system, picture, audio, and auxiliary data items in a specified manner. SMPTE
326M defines the structure of the content package mapped onto the SDTI transport; element and
metadata formats are defined by SMPTE 331M [14].

(

a)

(

b)

Figure 8.2.12 

SDTI data structure: (

a) fixed block size, (b) variable block size. (From [12]. Used

with permission.)

Downloaded from Digital Engineering Library @ McGraw-Hill (www.digitalengineeringlibrary.com)

Copyright © 2004 The McGraw-Hill Companies. All rights reserved.

Any use is subject to the Terms of Use as given at the website.

Serial Digital Video/Audio Systems

Serial Digital Video/Audio Systems 8-31

The baseline operation of the SDTI-CP standard is defined by the transport of content pack-

ages locked to the SDTI transport frame rate. The standard additionally defines format extension
capabilities that include:

•

Content package transfers at higher and lower than the specified rate through isochronous and
asynchronous transfer modes

•

Provision of a timing mode to reduce delay and provision for two content packages in each
SDTI transport frame

•

Carriage of content packages in a low-latency mode

•

Multiplexing of content packages from different sources onto one SDTI transport

Figure 8.2.13

 SDI/SDTI implementation for a computer-based editing/compositing system. (

From

[12]. 

Used with permission.)

Downloaded from Digital Engineering Library @ McGraw-Hill (www.digitalengineeringlibrary.com)

Copyright © 2004 The McGraw-Hill Companies. All rights reserved.

Any use is subject to the Terms of Use as given at the website.

Serial Digital Video/Audio Systems

8-32 Audio Networking

The SMPTE 326M standard is limited to SDTI systems operating at a bit rate of 270 Mbits/s and
360 Mbits/s as defined by SMPTE 305M.

An SDTI-CP compliant receiver must be capable of receiving and parsing the structure of the

SDTI-CP format. An SDTI-CP compliant decoder is defined by the ability to both receive and
decode a defined set of elements and metadata according to an associated decoder template doc-
ument. The MPEG decoder template is detailed in RP 204 [15]. Other decoder template recom-
mended practices can be defined as required for other applications of the SDTI-CP.

Figure 8.2.14 shows the basic layered structure of a content package. It is constructed of up to

four items, where each item is constructed of one or more elements, which include:

•

System item—carries content package metadata and may contain a control element. The sys-
tem item also carries metadata that is related to elements in the other items.

•

Picture item—can consist of up to 255 picture stream elements.

•

Audio item—can consist of up to 255 audio stream elements.

•

Auxiliary item—can consist of up to 255 auxiliary data elements.

A content package contains the associated contents of one content package frame period starting
with a system item and optionally containing picture, audio, and auxiliary items.

Data Packet Encapsulation

SMPTE 332M specifies an open framework for encapsulating data packet streams and associ-
ated control metadata over the SDTI transport (SMPTE 305M) [16]. Encapsulating data packet
streams on SDTI allows them to be routed through conventional SDI (SMPTE 259M) equip-
ment. The standard specifies a range of packet types that can be carried over SDTI, which may
be expanded as requirements develop.

The standard does not attempt to specify the payload contained in any packet. It offers options

to add specific information to each individual packet including localized user data space, for-
ward error correction (FEC), and a mechanism for accurate packet retiming at the decoder.

Figure 8.2.14

 The basic content package structure of SMPTE 326M. (

From [13]. Used with per-

mission.)

Downloaded from Digital Engineering Library @ McGraw-Hill (www.digitalengineeringlibrary.com)

Copyright © 2004 The McGraw-Hill Companies. All rights reserved.

Any use is subject to the Terms of Use as given at the website.

Serial Digital Video/Audio Systems