Getting live video from a venue back to a studio has been a common requirement for many years. Increasingly, video over IP is the backhaul technology of choice.
There are a variety of professional video over IP contribution standards either already in place or under development. The genesis of these documents was the Pro-MPEG Forum. These standards, incubated in the Video Services Forum, and formally standardized under SMPTE, all fall under the SMPTE 2022 multipart standard. Various parts are signified by a dash after the standard number, e.g. SMPTE 2022-1, 2022-2 and so on. A comprehensive view of the 2022 family of standards is shown in Figure 1.
In these standards, a number of network protocols are used to transport professional video over IP. At the data link layer, by far the most common technology in use today is Ethernet over SONET. At the IP layer, the dominant standard is IP. These standards — SONET, Ethernet and IP — all are well established and are very common for all IP-based applications. It is above this layer that we see some specialization for professional video transport.
At Layer 3, the 2022 standards specify User Datagram Protocol (UDP) and Real Time Protocol (RTP). UDP is used to deliver datagrams, and RTP is used both to convey timing information about the individual packets, and to provide a mechanism that can be used by Forward Error Correction (FEC) to recover lost packets.
The published 2022 standards (2022-1, 2022-2 and 2022-3) all rely upon MPEG-2 transport streams (TS) and higher level MPEG compression and synchronization mechanisms to transport professional video. Some future standards in this family will move away from MPEG-2.
SMPTE 2022-1 and 2022-2
Together, SMPTE 2022-1 and 2022-2 provide a mapping of MPEG-2 TS onto IP networks, with an associated standardized FEC mechanism. 2022-1 describes the FEC, and 2022-2 describes the mapping of the MPEG-2 TS onto IP. Almost all equipment currently manufactured for professional video transport of contribution SD-SDI streams on IP networks conforms to SMPTE 2022-1 and 2022-2. If we spend a few minutes to understand SMPTE 2022-1 and 2022-2, this will help us understand the rest of the family.
If you look in the upper right-hand portion of Figure 1, you will see that we start with an MPEG-2-compliant TS. This TS typically contains video, audio and ancillary data. 2022-1 and 2022-2 assume that video, audio and data have been previously compressed into an MPEG-2 compliant bit stream. The documents also assume that this TS is a constant bit rate (CBR) stream. As the figure shows, 2022-2 describes how to map this stream onto an IP network using UDP and RTP.
Optionally, this IP stream may employ an FEC mechanism that is defined in SMPTE 2022-1. This mechanism allows for recovery from errors during transmission. The FEC scheme is designed to protect for, at most, a 3ms outage because experience has shown that beyond this limit, IP networks employ other means of protection. In other words, for a backhoe fade where a fiber is cut after the 3ms outage, the network will automatically reconverge on another route, or the network operator will begin to recover from the failure using some other means.
In summary, 2022-1 and 2022-2 are for professional transport of CBR MPEG-2 transport streams. These standards cover CBR only. In a CBR stream, the bit rate does not vary.
SMPTE 2022-3 and 2022-4
The group working on the 2022 family of standards recognized that there may be cases where a user would like to transport variable bit rate (VBR) MPEG-2 transport streams. 2022-3 and 2022-4 are VBR mapping documents; they are based upon 2022-2.
The group quickly identified two different use cases for VBR contribution feeds. The first case is called Piecewise Constant VBR (2022-3), and the second is called Non-Piecewise Constant VBR (2022-4). In Piecewise Constant VBR (2022-3), even though the bit rate varies over time, the receiving application can assume that the MPEG TS packet pacing is equally distributed between PCRs and can recreate the packet timing exactly as it was presented to the input of the transmitter. This means that between any two successive PCRs, the signal is CBR at a specific bit rate for that period of time. Between the next two PCRs, the bit rate will also be constant for that period of time but will be at different bit rate. Because the CBR rate can change at every PCR, the result is that the long-term bit varies over time.
2022-3 provides two options for sending a VBR stream. One option sends datagrams into the network at a constant rate, regardless of whether datagrams are full of TS packets or not. This achieves the required result, but is less efficient because some packets are not full. The second option only sends datagrams into the network when they are full of TS packets. Because the intial bit rate is variable over time, the resulting datagram rate will be variable over time. In 2022-4, Non-Piecewise-constant VBR, the incoming stream to the transmitter does not provide equally distributed packets between PCRs (usually because one or more programs in a MPTS have been removed). In this case, the original pacing of the incoming stream is lost. The 2022-4 standard provides a method of signaling the original packet timing to the receiver to ensure that the interpacket timing of the original signal can be maintained.
In summary, 2022-3 and 2022-4 both build upon 2022-2 and add the capability to deal with VBR MPEG-2 transport streams. There are two VBR documents because we have identified two different use cases for VBR transport.
SMPTE 2022-5 and 2022-6
As this group has continued to evolve, user demand has grown for uncompressed, full bandwidth professional video transport. SMPTE 2022-5 and 2022-6 address this requirement. These standards are meant to transport high bit rate media over IP. By high bit rate, we mean uncompressed video at rates from 270Mb/s up to 3Gb/s. The transport carries not just active video, but the entire video signal, including VANC and HANC. These standards are intended to transport uncompressed video, although at some point in the future, a user might employ them to transport professional video wrapped in a container such as MXF.
As Figure 1 shows in the upper left-hand corner, if a user has an uncompressed SDI stream, that stream may be mapped onto an IP network by using 2022-6. 2022-5 describes an optional FEC mechanism to protect the stream. The FEC matrix size is enlarged over that of the 2022-1 matrix to accommodate the higher bit rate. The RTP header in IETF RFC 3550 is used, and the FEC header is based on IETF RFC 5109 with expansion to accommodate the extension of the error correction scheme.
Future work - JPEG 2000
We have identified an additional user requirement — the ability to transport JPEG 2000 on IP networks. The group has identified two mechanisms for this use case — transporting the JPEG 2000 in an MPEG-2 TS stream, and transporting the content wrapped in an MXF wrapper. Looking again at Figure 1, starting with an SDI stream, video can be compressed using JPEG 2000. One of the challenges in transporting JPEG 2000 is that audio is not addressed as part of the JPEG standard. So, in the case of a TS, a standardized mapping of the JPEG 2000 code stream to MPEG-2 TS has been recently completed. One way to handle audio would be to include it in an ancillary stream and compress it using MPEG-2. There are several other ways to create standardized compressed audio streams, and the 2022 transport documents do not care what the mapping is as long as the result is a legal MPEG-2 TS.
Once the JPEG 2000 is encapsulated as a TS, the user can employ 2022-2 to map the stream onto an IP network. Alternatively, as shown in the center of Figure 1, the JPEG 2000 video plus audio as ancillary data could be mapped into an MXF wrapper. Once wrapped, it is conceivable that this stream could be transported using 2022-6.
Status update
As of the writing of this article, SMPTE 2022-1, 2022-2 and 2022-3 are published SMPTE standards. 2022-4, 2022-5 and 2022-6 are working their way through the standardization process. The committee is preparing to begin work on JPEG 2000.
Brad Gilmer is President of Gilmer & Associates, executive director of the Advanced Media Workflow Association and executive director of the Video Services Forum.
Send questions and comments to: brad.gilmer@penton.com
