Why Retransmission Fails for Live Video
TCP handles packet loss through ARQ (Automatic Repeat reQuest) — when a packet is lost, the receiver detects the gap, sends a NACK, and the sender retransmits. This adds one round-trip time (RTT) of delay minimum. For a stream from London to New York (70ms RTT), recovering one lost packet adds 70ms. At 60fps video, that is more than 4 frames of delay — visible as a freeze or artifact.
UDP has no built-in retransmission. Live streaming protocols use UDP to avoid TCP's retransmission latency. FEC replaces retransmission with preemptive redundancy.
How FEC Works
FEC uses erasure coding — a mathematical technique that generates k redundant "repair" packets from a group of n source packets. If any packets from that group are lost during transmission, the receiver can reconstruct the missing packets from the repair packets and the remaining source packets, as long as the number of losses does not exceed the number of repair packets.
Example: a 4+2 FEC group sends 4 source packets and 2 repair packets (6 total). The receiver can reconstruct the original 4 source packets as long as no more than 2 of the 6 are lost. No round-trip needed — reconstruction happens locally at the receiver the moment the group is complete.
Common FEC algorithms used in streaming:
- SMPTE 2022-1 (Pro-MPEG FEC): Standard in broadcast for MPEG-TS over UDP. Uses a 2D matrix arrangement for row and column FEC, protecting against burst losses.
- LDPC (Low-Density Parity Check): More efficient for high loss rates; used in some satellite delivery systems.
- SRT (Secure Reliable Transport): Uses ARQ retransmission primarily but falls back to FEC or combines both depending on latency budget and loss rate.
- RIST (Reliable Internet Stream Transport): Open standard using RTP with SMPTE 2022-1 FEC or retransmission, designed for broadcast contribution over public internet.
FEC in Live Streaming Protocols
SRT (Secure Reliable Transport): Developed by Haivision, now open source. Primary loss recovery is ARQ retransmission within a configurable latency budget (typically 120–1000ms). FEC is available as an additional layer. Widely used for contribution feeds from venue to cloud encoder.
RIST: Designed by the Video Services Forum as an open alternative to SRT. Uses standard RTP/UDP with SMPTE 2022 FEC. Interoperable across vendors. Common in broadcast playout and distribution.
WebRTC: Uses Opus FEC for audio and ULPFEC/FlexFEC for video. FEC is standard and always on in WebRTC media flows, making browser-based video conferencing resilient to typical 1–5% packet loss on internet paths.
FEC vs Retransmission Tradeoff
| Approach | Latency Added | Bandwidth Overhead | Best For |
|---|---|---|---|
| ARQ Retransmission | 1+ RTT per loss event | Only for lost packets | Low-loss paths, higher latency tolerable |
| FEC only | None (decode locally) | Fixed % regardless of actual loss | Predictable loss, ultra-low latency |
| FEC + ARQ (SRT) | Minimal (ARQ within budget) | FEC overhead + retransmits | Variable public internet paths |
Frequently Asked Questions
Does FEC help with Netflix or YouTube streaming?
No — these services use TCP via HLS or DASH. TCP handles loss through automatic retransmission, and the large playback buffer absorbs the delay. FEC is used in professional broadcast contexts where UDP is the transport and latency is too tight for retransmission: live sports contribution feeds, broadcast playout, and WebRTC conferencing.
How much overhead does FEC add to bandwidth?
FEC overhead equals the redundancy ratio. 25% FEC on a 100 Mbps stream adds 25 Mbps of repair packets — 125 Mbps total. The ratio is configured based on expected loss: paths with 1% expected loss need far less redundancy than paths with 5%. SRT can adapt the FEC ratio based on measured path loss.