Wes Simpson
In many broadcast television applications today, forward error correction allows recovery from errors that occur during transmission. However, new delivery systems that use HTTP streaming don’t need FEC, and there is currently a debate within the broadcast community about whether FEC is beneficial for Ethernet video within the studio.
UNDERSTANDING FEC
The main goal of FEC is to correct errors that occur in digital transmission. This is accomplished by adding extra data to a bitstream that allows a receiving device to recover from bits that have become lost or scrambled in transmission.
Many FEC algorithms work on a fixedsized block of data such as a 188-byte MPEG Transport Stream (TS) packet, or a set of data packets arranged into a fixed quantity of rows and columns such as in SMPTE 2022 FEC transmissions.
FEC bytes (in the MPEG TS case) or packets (in the SMPTE 2022 case) are added to the original data stream using specialized mathematical techniques. Whenever errors are detected in the incoming stream, the receiver processes the FEC data along with the correctly received data to produce an overall valid output.
Determining the required amount of FEC data to add depends on the anticipated error rates. For example, MPEG TS packets commonly add 16 bytes of Reed-Solomon FEC data that allows up to 8 faulty bytes to be repaired. For ATSC transmission, 20 bytes of FEC are added to allow correction of up to 10 bytes. These values represent 8- and 10-percent FEC overhead, respectively.
FEC APPLICATIONS
Fig. 1: Comparison of FEC and ARQ systems for error correction In SMPTE 2022 FEC, the number of rows and columns in an FEC matrix are adjustable; if a transmission is made with a matrix sized at 10 rows with 50 columns, the amount of FEC overhead would be 60 packets for every 500, or 12 percent.
A surprising number of digital technologies use FEC codes (or their synonym, ECC—error correcting codes). Included in this list are hard disk drives of all types; CDs, DVDs and Blu-ray discs; flash memory and some types of system memory, including much of the RAM used inside Google’s data centers.
FEC is frequently used in one-way delivery of video, audio or other signals that can’t or don’t use a reverse path to correct transmission errors. Point-to-multipoint transmissions such as satellite systems or over-the-air broadcasts commonly use FEC, because there is no practical way to retransmit lost data to one receiver in a network delivering content to thousands or millions of devices.
Another common application of FEC is in networks such as IPTV systems, where a single video stream is distributed to multiple viewers simultaneously by using multicasting protocols inside the network.
WHEN FEC ISN’T NEEDED
Adding FEC bytes or packets to a signal that uses retransmission to replace lost or corrupted data doesn’t make much sense. This process, called Automatic Repeat-reQuest (ARQ) allows the receiver to ask the transmitter to re-send data that is missing or received with errors, and is used by transmission control protocol, the most widely used transmission protocol on the Internet.
Each TCP connection requires a one-to-one relationship that forces the transmitter to wait until the receiver has acknowledged successful data reception before more data can be sent. Data transmission speeds can drop rapidly as network delay increases between the transmitter and the receiver.
Data networks used inside a broadcast facility are typically maintained to have extremely low error rates, arguably making the extra processing and bandwidth consumed by FEC superfluous. It may even be possible to operate in-house networks without FEC or ARQ, as is commonly done with SDI signals.
Products that use MPEG-DASH (dynamic adaptive streaming over HTTP) also use TCP ARQ. Path1, a San Diego-based developer of encoding technology recently introduced its new PiXiE encoder-decoder, which, according to company founder and CTO Bart Schade, “is designed for contribution and primary distribution applications, which typically travel over high-quality, private IP networks already, but may also be delivered over the Internet. By avoiding FEC and using the ARQ that is built into DASH, our customers can pack more services into a given amount of bandwidth, while still getting a high-quality, real-time video delivery over any IP network, even the Internet.”
CHOOSING FEC WISELY
In Fig. 1, the upper portion shows the bandwidth profile of a one-way FEC-based transmission that is simultaneously delivered to multiple destinations. The lower portion shows an ARQ-based transmission, including a packet that has been retransmitted due to a request from the receiver.
The choice of whether to use FEC or ARQ depends on the application. For oneway networks with long round-trip delays or point-to-multipoint architectures, FEC is a better solution. ARQ works best for systems that support bidirectional communications and that have low delays and error rates. For systems using MPEG-DASH or other forms of HTTP streaming, FEC doesn’t provide any added benefit.
Wes Simpson is an industry consultant and author of “Video Over IP, Second Edition,” from Focal Press. Your comments are welcome towes.simpson@gmail.com.
