by Alain Legault and Janet Matey

Serial Data Transport Interface (SDTI) is emerging as the standard for transporting packetized audio, video, and data between cameras, VTRs, editing/compositing systems, video servers, and transmitters in professional and broadcast video environments. SDTI builds on the familiar SDI standard that is now widely used in studios and production centers to transfer uncompressed digital video between video devices. SDTI saves time and maximizes video quality. It provides for faster-than-realtime video transfers and a reduction in the number of decompression/ compression generations required during the video production process, while utilizing existing SDI infrastructure. Silicon and board-level adapters are starting to become available to allow manufacturers to build cost-effective, computer-based systems implementing SDTI.

This article will give you an overview of the SDTI (SMPTE 305M) specification. It also describes SDTI implementation issues related to computer-based equipment design, operating systems, and application software. The DV format, PCI-bus computer system architecture, Windows NT operating system, and editing application software are used as specific examples.

The Evolution of SDTI

Today, SDI (SMPTE 259M) is in widespread use as the method to transfer uncompressed digital audio and video signals between digital devices in broadcast and post-production facilities. The advent of compressed video formats such as DVCPRO, DVCPRO 50, Betacam SX, Digital-S, DVCAM, and MPEG-2 brought about the need to transfer compressed audio and video streams between devices. SDI has been used to meet this need, but signals must be uncompressed at the output of a device and recompressed at the input of the target device. Repeated compression/ decompression passes degrade the signal unnecessarily. SDTI was built on the SDI base to provide a mechanism for exchanging digital audio and video signals in their native compressed formats.

The SMPTE 305M SDTI specification evolved from a collaborative effort on the part of Sony, Panasonic, and other equipment vendors and interested parties, under the auspices of the SMPTE PT20.04 Workgroup on Packetized Television Interconnections, to define a common interchange interface for compressed audio and video. Features of Sony's DVCAM interface (QSDI) and Betacam SX interface (SDDI), and Panasonic's DVCPRO interface (CSDI) were incorporated into SDT, which was finally renamed SDTI.

SDTI is designed to be simple and inexpensive to implement. It offers some of the benefits of a network without the burden of networking overhead. SDTI allows users to establish point-to-point unidirectional connections to push compressed data from a transmitter to a receiver. Bandwidth is guaranteed since the link is dedicated during the transmission. It does not require a handshaking mechanism and acknowledgment protocol between the transmitter and receiver as is the case with networking technologies such as Ethernet and Fibre Channel. Significant buffering circuitry at the interface level is not required because transfers are done synchronously, as with videotape.

The SDI Core

Because SDTI is built on the SMPTE 259M SDI specification, they share the same mechanical, electrical, and transport mechanisms. BNC connectors and coaxial cables establish the mechanical link. SDI transports uncompressed digital video using 10-bit words in 4:2:2 YUV component mode for 525- and 625-line applications. Words are serialized, scrambled, and coded into a 270-Mb/s or 360-Mb/s serial stream. In order to synchronize video timing between the transmitter and the receiver, SDI defines words in the bitstream called End of Active Video (EAV) and Start of Active Video (SAV) (Figure 1). At 270 Mb/s, the active portion of each video line is 1440 words and at 360 Mb/s, the active portion is 1920 words. The area between EAV and SAV can be used to transmit ancillary data such as digital audio and time code. The ancillary data space is defined by SMPTE 291M.

Figure 1 SMPTE 259M Video Timing

SDI and SDTI can co-exist in a facility using the same cabling, distribution amplifiers, and routers. Cable lengths of more then 300 meters are supported. SDI repeaters can be used to reach longer distances. A versatile studio configuration that supports all the required point-to-point connections can be established using an SDI router. SDI and/or SDTI streams can be routed from source to destination devices (Figure 2).

Figure 2 SDI/SDTI Studio Infrastructure

SDTI Data Structure

SDTI uses the ancillary data space in SDI to identify that a specific video line carries SDTI information. The packetized video is transported within the active video area providing 200 Mb/s of payload capacity on 270-Mb/s links and 270 Mb/s of payload capacity on 360-Mb/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 (Figure 3). It 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 is also included.

Figure 3 Header Data Packet

The 46 words of header data define source and destination addresses and the formatting of the payload (Figure 4). Line Number and Line Number CRC are used to ensure data continuity. Code identifies the size of the payload to be either 1440 words or 1920 words long. Authorized Address Identifier (AAI) defines the addressing method utilized. Currently the Internet Protocol (IP) addressing scheme is defined. Source Address and Destination Address are 128 bits long allowing over 3.4 X 10³⁸ addressable devices to be supported. Block 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, it also defines the number of blocks that are transported in one video line. The Block Type depends on the data type of the payload. For example, DVCPRO uses fixed-sized data blocks and Betacam SX uses variable-sized data blocks. Cyclic Redundancy Check (CRC) can be used to verify data integrity of the 46-word data header.

Figure 4 Header Data Structure

Between SAV and EAV, the payload is inserted. The payload can be of any valid data type registered with SMPTE. Currently DVCPRO, DVCPRO 50, Digital-S, Betacam SX, DVCAM, and MPEG-2 Program and Transport streams are registered. The data structure of the payload includes a Data Type code preceding the data block (Figure 5). In addition, Separator, Word Count, and End Code are required for data types that feature variable-sized blocks (Figure 6). SMPTE 305M does not specify the data structure inside the data block; it is left to the registrant of the particular data type. As an example of the data structure of a payload, the DV data stream format can be used. The SMPTE PT20.04 workgroup is currently working on the definition of the data structure for the exchange of DV-based audio, data, and compressed video over SDTI.

Figure 5 Data Structure (Fixed Block Size)

Figure 6 Data Structure (Variable Block Size)

DV Data Structure Example
DV data blocks have a fixed size of 171 words (Figure 7). On a 270-Mb/s link, eight data blocks are transmitted in each video line, on a 360-Mb/s link, 11 data blocks are transmitted. Each data block starts with the SDTI Data Type 221h. The data blocks contain Signal Type (ST) that defines whether the system operates at 480I or 480P, whether the vertical refresh rate is 50 or 60 Hz, and whether the bitrate is 25 Mb/s or 50 Mb/s. Transmission Type (TT) defines a transmission rate, for example, 1× for normal transmission and 4× for four times normal transfer speed. Two Digital Interface (DIF) blocks carry the DV audio and video information. An Error Correction Code (ECC) is appended at the end of the data block. ECC is highly desirable since data errors can propagate in compressed systems and produce much more severe defects than will occur for a corrupted pixel in an uncompressed video signal.

Figure 7 Stream Block Format
A complete DV 25 compressed video frame is made up of 750 SDTI data blocks in a 525/60 system. This group of data blocks is called a channel unit. Each channel unit takes 94 consecutive lines of video on a 270-Mb/s link or 69 lines on the 360-Mb/s link (Figure 8). Similarly, in a 625/50 system, a channel unit requires 900 SDTI data blocks which equate to 113 video lines on a 270-Mb/s link or 82 video lines on a 360Mb/s link. DV 50 compressed video frames are made up of two adjacent channel units.

Figure 8 SDTI Data Block Mapping
In a 270-Mb/s system, up to four channel units can be mapped inside the active video area of one uncompressed SDI video frame (Figure 9). In a 360-Mb/s system, up to six channel units can be transported. This explains the ability to transfer DV 25 material at up to 4× realtime on a 270-Mb/s link.

Figure 9 Channel Unit Mapping

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. Computers interface with other SDTI devices through the use of an adapter.

Typically, an SDTI-enabled computer-based NLE system will contain a number of components:

•	a CPU motherboard;
•	A/V storage and a controller to store the digital audio and compressed video material;
•	an editing board with audio/video I/O, frame buffer, digital video codecs and processors;
•	network and console display adapters; and
•	a SDI/SDTI adapter.

 

As an example of a typical SDI/SDTI hardware adapter, a PCI-bus implementation can be used (Figure 10). With the PCI adapter installed, the computer can communicate SDI and SDTI streams with other devices. It can also be used to transcode from SDI to SDTI and vice versa.

SDTI Adapter Architecture
SDI input/output circuity

The SDI input circuitry receives the 270- or 360-Mb/s stream from external equipment and converts the serial bitstream by decoding, descrambling, and parallelizing the bitstream into 10-bit words. The SDI output circuitry does the reverse function by serializing, scrambling, and coding 10-bit words into a serial 270Mb/s or 360MB/s bitstream.

SDI/SDTI controller

The SDI/SDTI controller extracts video synchronization signals from the SAV and EAV codes and detects whether the incoming stream is SDI or SDTI. In the presence of an SDI stream, the controller extracts the embedded digital audio data from the ancillary data packets. It routes the digital audio, uncompressed digital video, and synchronization signals over the Movie-2 expansion bus to the editing card. In presence of a SDTI data stream, the controller routes the packetized data to the SDTI formatter/deformatter circuit.

On the output side, in SDI mode, the controller takes digital audio and video from Movie-2 bus and inserts digital audio packets into the ancillary data space. In SDTI mode, the controller receives the packetized data from the SDTI formatter/deformatter and routes it to the SDI output circuitry. The controller also inserts the SAV and EAV codes in the outgoing SDI stream.

The controller can also let SDI and SDTI streams pass through the adapter by directly routing the incoming stream from the SDI input circuitry to the SDI output circuitry. This is useful to allow several pieces of equipment to be daisy-chained.

SDTI formatter/deformatter circuit

The SDTI formatter/deformatter circuit has both receive and transmit modes.

In receive mode, it performs the following deformatting functions:

In transmit mode, the circuit performs the following formatting functions:

In receive mode, the SDTI data blocks are transferred from the SDTI deformatter into the memory buffer. The AV data processor demultiplexes the video and the audio information from the SDTI data blocks. It then decompresses the audio information into PCM audio streams if required. The demultiplexed audio and video blocks are then transferred to the AV storage device and stored as separate files.

In transmit mode, video and audio files are transferred from the AV storage to the memory buffer. The AV data processor compresses the PCM audio streams if required, multiplexes the audio and video blocks, and assembles them into SDTI data blocks to be sent to the SDTI formatter. Multi-format compressed video decoder

The multi-format compressed video decoder allows previewing of the digital video being received or transmitted. The decoder reads the compressed video blocks and PCM audio blocks from the memory buffer over the PCI bus and displays it on the preview monitor. As several compressed video formats are supported by SDTI, it is important that multiple formats can be decoded for viewing. PCI-to-PCI bridge

The PCI-to-PCI bridge isolates the PCI devices on the SDI/SDTI adapter from the rest of the computer system. It is important not to burden the main PCI bus with the video transfers because the data rate involved can consume a significant portion of the effective PCI system bandwidth. For example, at 6× transfer speed in DV 25, more than 23 MB/second of data throughput is required. SDTI System Software Architecture

The editing system takes advantage of the SDTI technology through a stack of software drivers that control the SDTI adapter (Figure 11). Application software must be modified to adapt the data flow control used in current SDI/analog video editing systems to the new compressed video I/O model. As an example of a software architecture that supports SDTI, Windows NT can be used.

Figure 11 Software Architecture in an SDTI-based Editing System

Windows NT Example
The architecture of Windows NT is very modular, offering a high level of inherent openness. Each important subsystem—storage, network, peripheral interface, graphics—provides a common interface to the operating system kernel independent of the specific technology used. The idea of a streaming peripheral interface is well known under NT. IEEE-1394 device drivers are already in use to stream DV data between consumer video devices and computers. Although IEEE-1394 itself is inadequate for broadcast studio use because of limited cable length, topology, and bandwidth, driver features similar to the 1394 model in NT are required for SDTI.

The low-level SDTI driver interfaces directly with the SDTI hardware using the Win32 Driver Model (WDM). The function of this driver is to control the SDTI adapter and stream the data between the SDTI hardware and the other components of the system such as the storage controller, video codec, and audio sub-system. The driver uses standard Windows NT operating system services such as memory allocation function calls.

The DirectShow software layer provides the streaming architecture model under Windows NT. It abstracts the specifics of the hardware from the application software. It offers a consistent system-level synchronization mechanism between media and devices. DirectShow provides control interfaces to all the different components of the editing system through functional blocks called filters. Different versions of the SDTI control filter can be designed for each data type, such as DV and MPEG-2. The control mechanism for these filters remains the same, independent of the data type, simplifying the work of the application software vendor in supporting several data types within a product.

Editing application vendors must adapt the data flow control used in their current SDI/analog video editing systems to the new compressed video input/output model. Changes are primarily required in capture and output modules. A typical SDI editing system captures by routing uncompressed video to a preview monitor and video codec, compressing it, then sending it to the storage device. An SDTI system captures by routing packetized, compressed video to a deformatter then sending it directly to the storage device. A video codec is used in parallel to decompress and view the material that is being captured. The end user sees the same "capture" being performed, but the underlying mechanism in the application software is very different. Once the video material is in storage, the files are identical whether they were captured through SDI or SDTI. They are manipulated by the editing system in an identical manner. When editing is finished, the final program can be sent out via SDI or SDTI. In SDI mode, the program goes to the video codec, is decompressed, and output as uncompressed SDI to the external equipment. In SDTI mode, the program goes to the formatter, is packetized, and output as an SDTI stream to the external equipment. Again, the user sees "output", but the underlying output mechanism controlled by the application software is very different. Conclusions

The EBU/SMPTE Task Force for Harmonized Standards for the Exchange of Programme Material as Bitstreams has recommended the use of SDTI for streaming data between devices in broadcast studios. This endorsement makes SDTI a clear choice for interconnectivity at the dawn of the DTV era.

SDTI provides a number of important benefits:

SDTI is of clear benefit today and it also offers room for growth in the future. Data routing could be automated. Routers could be developed to detect IP addresses within the SDTI data packets and automatically route SDTI packets to their destination, similar to an ATM switch. Alternatively, a control network such as Ethernet could be devised to run in parallel with the SDTI connections. SDTI could also be extended to take advantage of the 540-Mb/s and 1.485-Gb/s links that are being developed to support HDTV.

References

EBU Technical Review (August 1998) "EBU/SMPTE Task Force for Harmonized Standards for the Exchange of Programme Material as Bitstreams"

Matsushita Electric Industrial Co, Ltd. and Panasonic Broadcast & Television Systems Co. (1997) "SDI/SDDI White Paper"

Proposed SMPTE Standard (October 1998) "Television Data Stream Format for the Exchange of DV Based Audio, Data and Compressed Video over a Serial Data Transport Interface (SDTI)

SMPTE 259M "10-Bit 4:2:2 Component and 4f_sc Composite Digital Signals – Serial Digital Interface"

SMPTE 291M "Ancillary Data Packet and Space Formatting"

SMPTE 305M "Serial Data Transport Interface"

Dan Turow, Gennum Corporation, "SDTI and the Evolution of Studio Interconnect," International Broadcasting Convention Proceedings, 11-15 September 1998, Amsterdam

J.H. Wilkinson, H. Sakamoto, and P. Horne, Sony

---

Alain Legault is Vice-President of Product Development at Matrox Electronic Systems, Ltd.

Janet Matey is Marketing Communications Director at Matrox Electronic Systems, Ltd.

Copyright © 1999 by Matrox Electronic Systems Ltd. All rights reserved. Send all product-related questions to video.info@matrox.com