I am often asked to elaborate on the benefits of ARQ versus FEC, for streaming live video over the internet, as ARQ provides a basis for the “Reliable” in SRT (Secure Reliable Transport). If you are interested in learning more, please read on.

As broadcasters move to take advantage of ubiquitous and low-cost high bandwidth connections to support their video workflows, they are often confounded by a number of IP streaming options. The methods used for transporting compressed video are designed specifically to recover from packet loss that is inherent to any data transfer over the internet.

This post will compare the two fundamental methods for packet loss recovery – ARQ (Automatic Repeat reQuest) and FEC (Forward Error Correction). Both techniques are designed to detect and correct errors in data transmission.

A simple background:

• FEC – Forward Error Correction: Historically used within the Pro-MPEG FEC standard by broadcast equipment vendors to transmit data over less than pristine networks.
• ARQ – Automatic Repeat Request: The technique used in TCP (discussed below) but more often associated with R-UDP, Haivision’s Open Source SRT and various proprietary implementations including those by Zixi and QVidium.

TCP/IP and why it does not scale for low latency video.

Almost all of today’s web traffic is protected from packet loss by TCP/IP (Transmission Control Protocol over Internet Protocol) – a set of rules that dictates the delivery of data over the internet. TCP/IP establishes and maintains the relationships and handshaking between sending and receiving computers.  

These rules require that the receiver acknowledge all received packets so that the sender can resend any which were lost. However, for real-time video streams, TCP/IP falls apart because the communication is highly inefficient, especially over long distances. Too many receipt acknowledgements flood the connections, dramatically reducing the bandwidth efficiency. The buffering established between every sender and receiver in the workflow (every router for example) also introduces enormous transmission delays. This is why TCP based protocols (such as RTMP, HLS, and MPEG-DASH) are not a good fit for low latency broadcast requirements.

What is FEC?

FEC (Forward Error Correction) is a technique that adds redundant data to a video stream prior to transmission. I like to think of the analogous RAID storage technology – spreading and duplicating raw data over several hard drives so that if one fails, all of the original data can be recovered.

Before the video stream heads on its path, calculations are performed to create the data necessary to rebuild the stream at the other end, if any data is lost. FEC is great over a semi-managed network where there could be some minor data loss, but falls short if large chunks of data are lost. In the RAID example above, if two drives fail at the same time you are out of luck. So FEC is not well matched with the burstiness of public internet transport and the type of packet loss due to things like entry point congestions due to circuit or SLA over provisioning.

FEC is typically effective when packet loss is less than 3%-5% and when a sender/receiver relationship is not possible, such as with uni-directional satellite or over multicast.

FEC does add bandwidth overhead, (for the redundant data) typically in the range of 30%, to protect against networks with “known” lossiness. FEC also adds latency to perform the initial calculations and provide for the recovery calculations. Typically, this added delay can be in the order of 100 to 500 milliseconds. You can tune FEC within most standard implementations by adding or removing rows from the associated (and not “user friendly”) “redundancy matrix”. One of the real issues with FEC is the fact that to avoid over-provisioning the FEC overhead (which translates to extra latency and unnecessary bandwidth being used), the operator needs to be aware of the packet loss pattern, which is virtually impossible to do for internet connections.

Where, why, and how does the Makito support FEC?

Haivision’s Makito series of video encoders and decoders supports two types of FEC. For broadcast transmission, and to be compatible with various established workflows and components, we support Pro-MPEG FEC. This is mostly used in satellite transmissions where there is no datapath for a sender/receiver relationship. The Makito series also supports a lightweight FEC implementation which we use to protect from data loss when transmitting multicast, typically within a building or campus.

ARQ – Finder of the lost packets.

ARQ (Automatic Repeat Request) is a packet retransmission approach better suited to live video streams or very large files. Instead of acknowledging the receipt of every packet, ARQ simply acknowledges if a packet is missing, thus avoiding the massive amount of communications that make TCP highly latent and inefficient with bandwidth.

The bandwidth overhead needed for ARQ simply scales in relation to the packet loss experienced, and doesn’t have a fixed “breakable” level like FEC, making it much more appropriate for the unpredictability of the public internet. If the packet loss is minimal, so is the overhead.

Certainly, ARQ does add some latency, which depends on the retransmission or round-trip time of the sender/receiver. The farther apart the nodes, the more latency you will need to accommodate through larger buffers. Considering that the round-trip time from, say, New York to Los Angeles is about 100 milliseconds, the additional latency is not hugely significant. Also, as the most efficient networks are designed with a few very short transmission segments, latency of the overall workflow can be minimized.

Where, why, and how does the Makito support ARQ?

ARQ helps ensure the “Reliability” of the SRT (Secure Reliable Transport) streaming protocol. Within SRT, Haivision tuned the implementation for the lowest latency performance and to respect the nature of video – its timing. The protocol is highly tunable by adjusting the buffering at either end of the SRT connection and setting a bandwidth limit for any communications and retransmission on top of the raw data.

Haivision supports both SRT (ARQ) and FEC to address all video streaming applications.

The Makito X series of low latency video encoders is designed to be adaptable for all video streaming applications. With the option between ARQ and FEC always available to them, video streaming professionals can rely on the same encoder for each and every one of their video streams – which is not only cost-effective, but also helps to simplify workflows.

With the ability to do either, when is ARQ the preferred method for protecting against packet loss, and when is FEC? Fortunately, we put together a quick table, which you can use a “cheat sheet.”

Table of ARQ vs FEC