As we move from a video-centric to a data-centric world, we are faced with a change in the underlying video transport technology. In the past, video was transported over dedicated video networks. Now it is moved across data networks. With some exceptions, packetized networks are designed to drop packets according to predefined rules if the network becomes congested. These lost packets can affect the video delivered at the end of the transport chain.
There are several ways to solve this problem. Two of the most common solutions are to prevent packet loss using QoS technology or to reconstruct the missing packets at the receiving end using FEC.
QoS technology
If you are building your own network, or if you are working with a service provider that controls its own network, it may be possible to use QoS technology to prevent video packets from being dropped. This will not protect you from a backhoe fade, but it will protect you from network congestion.
The first step is establishing a policy regarding the relative priority of different types of traffic on the network. For example, video might be the top priority, voice second and data third.
Once the policy is in place, the next step is to tightly control access to the network. All users must access the network at specific points. When data is first put on to the network, it is given a tag that marks the packet with a specific priority, per the policy established above.
As the traffic transits the network, it encounters QoS-aware routers. If congestion occurs, the routers will start dropping packets according to the QoS policy. If the network is properly engineered, ingress control is maintained and the policy is sound, QoS will ensure that video packets are never dropped at the routers.
In some scenarios, QoS may be difficult to implement. For example, you may not be able to control the entire network, or you may not be able to guarantee that someone won't access the network at an unauthorized point. For whatever reason, you may decide that it is best to rebuild lost packets at the receiving end rather than or in addition to enforcing a QoS policy on your network. This is a job for FEC.
Forward Error Correction
FEC works by sending extra packets of information along with the original payload. The FEC packets can be used at the receive end to recreate data packets that have been lost during transport. The amount of data that can be recovered is directly related to the amount of FEC data sent. In fact, the logical extreme of FEC is to retransmit every data packet as a FEC packet.
This brings up a critical point about FEC. Nothing is free; FEC requires extra bandwidth. Typical numbers for FEC overhead on average packetized networks range from 10 percent to 20 percent, although overhead could be as high as 1000 percent in some specialized military applications. In other words, if you are transporting a 10Mb video stream, FEC will require an additional 1Mb to 2Mb of bandwidth.
Another factor to consider is latency — the time, in addition to transmission delay, for data to become available for a subsequent process. FEC introduces latency by requiring all data packets to be loaded into the FEC matrix whether they are errored or not. This introduces a fixed latency in the receive unit that adds to the total transit time for video sent across a protected connection.
Finally, there is one other thing to know about FEC. The technology discussed in this article is designed to reconstruct lost packets — not errored packets. One characteristic of the lower layer of the IP stack is that if it detects an errored packet, it will discard it rather than pass it up to the next layer. This means that no application layer FEC scheme will ever see an errored packet.
To sum up, QoS can eliminate certain types of errors created in a network if you have control over that network. FEC can fix errors introduced on a network, but it has a cost in terms of overhead and latency.
SMPTE 2022
The Pro-MPEG Forum began initial work on a FEC scheme for video transport. That work, added to by the Video Services Forum, was introduced to SMPTE. This proposed standard is known as SMPTE 2022, and it describes both a FEC scheme and a way to transport constant bit rate video over IP networks.
Figure 1 on page 30 shows how SMPTE 2022 FEC is constructed. At the sender, data is organized into columns and rows. The data blocks in the figure are populated from left to right and top to bottom. Once a matrix is filled, an exclusive or (XOR) function is executed on all of the data in one column. The FEC packet is the resulting value for that column. The same function is performed on subsequent columns. The calculated FEC packets are then interleaved with data packets and sent to the receiver.
At the receiver, all packets are sent through the FEC mechanism. As packets are received, the matrix is filled. Next, a FEC calculation is made for any missing packets, and the reconstructed data is inserted into the matrix. (This is the source of the latency mentioned above.) Finally, the data is delivered to the video application.
The FEC described above is reasonably lightweight in terms of overhead and latency, but there are cases where certain errors cannot be corrected. (See Figure 2.) In this example, packets 14 and 26 — two packets in the same column — are lost. Column-only FEC cannot rebuild the missing packets. SMPTE 2022 allows for the addition of row FEC to provide increased protection against errors. This is known as 2-D FEC because FEC values are calculated for both columns and rows.
The DVB is developing a proposed standard that uses SMPTE 2022 1-D FEC, but then optionally augments this with fountain code FEC, which was developed by Digital Fountain. In cases where network losses are high, this approach is more efficient than 2-D FEC.
In addition, fountain codes have lower latency because repair packets for a particular block are sent immediately following the data. (See Figure 3.) This is accomplished by speeding up the overall data transmission rate so that the data block and repair packets are all sent in the same amount of time it would take to send the original data block without repair packets.
Thinking data-centric
As we move to a world where IT-based technology is employed to transport content, we are challenged to learn about QoS, FEC and other data-centric applications. If you are interested in learning more about these topics, attend sessions at NAB, IBC and other trade shows. Many vendors have prepared excellent tutorials on these subjects for broadcasters.
Brad Gilmer is executive director of the Video Services Forum, president of Gilmer & Associates and executive director of the AAF Association.
Send questions and comments to:brad.gilmer@penton.com
