Keywords: Forward Error Correction, FEC, Packet-loss

Forward Error Correction

Version Date Author Comment
0.6 2009-11-30 Brees

Introduction
Whenever data is transmitted, via cable, radio, or satellite link, the transmitted signal will be subjected
to distortions and noise. These interferences can be caused by signal degradation, noise on the
transmission channel or network congestions. In IP-networks, bit errors may lead to the loss of whole
packets, which in turn result in visible and audible errors in the decoded stream.
Retransmission of lost packets is too costly and they may not arrive at the decoder in time.

Solution
Forward Error Correction (FEC) is an approach for minimizing these irregularities by providing
additional redundant information, that allow the receiver to reconstruct a certain amount of lost packets
without retransmission of packets.
An FEC algorithm is applied on the sender side to audio and video packets. The data the algorithm
produces is sent parallel to the regular RTP streams and can be used in case of packet loss for
reconstruction by applying the inverse FEC algorithm.

Figure 1: FEC overview 

1
FEC algorithms
The FEC algorithm takes a predefined block of packets (FEC group) and calculates an FEC packet. A
potential algorithm could be a simple XOR, that uses a block of n packets as input.

Figure 2: FEC‐packet‐generation on the encoder‐side (one‐dimensional FEC) 

Figure 3: Packet reconstruction on the decoder side (one‐dimensional FEC, 1 packet lost) 

The lost packet in fig. 3 can be recovered by applying the FEC algorithm (XOR) on the received data
packets and the FEC packet. In one-dimensional FEC only one packet per FEC group is recoverable
using the XOR algorithm.

Figure 4: Reconstruction impossible (one‐dimensional FEC, 2 packets lost) 

Types of packet-loss

Random errors

Random packet loss will likely result in a scattered

pattern of lost packets in the stream, which should      Figure 5: Random packet loss
be easy to correct with one-dimensional FEC.

 
Burst errors 

Packet loss occurring in bursts cannot be recovered

  Figure 6: Bursts of packet loss 
by one-dimensional FEC. By adding another dimension
and thus employing an FEC matrix, burst errors can be
recovered.

2
Two-dimensional FEC

As shown in fig. 7 there are now FEC groups consisting of rows and of columns. Each FEC group
produces an FEC packet. The overhead of this FEC matrix is at 33%, but of course the ability to
recover packets has been increased significantly too to 25-43% (fig. 8). Additionally, bursts of packet
loss can now be recovered to a certain degree.

                        

Figure 8: Packet reconstruction on the 
decoder side with the right reconstruction 
order depicted (two‐dimensional FEC, 7 
packet lost) 

Figure 7: FEC‐packet‐generation on the encoder‐side                   
(two‐dimensional FEC) 

FEC drawbacks

Overhead

The additional FEC packets introduce a certain overhead. This overhead depends on the size of the
FEC groups. The smaller the FEC group, the larger the overhead and vice versa. A one-dimensional
FEC, with groups of n packets, result in an overhead of 1/n.

3
For two-dimensional FEC with a FEC-matrix of n columns and m rows, the overhead would be 1/n +
1/m.

Delay

Packets arriving at the receiver need to be buffered so the reconstruction can take place in case of
lost packets. The decoding of the RTP payload can't start until all packets of an FEC group (or in case
of two-dimensional FEC the whole FEC matrix) have arrived or a timeout has been reached.
The resulting delay depends on the size of the FEC groups. Larger FEC groups will produce a higher
delay. On the other hand higher bitrates will produce a bigger amount of packets transmitted per
second and will thus decrease the delay.

The following figure illustrates the impact of overhead and added delay using specific examples.

Latency
FEC matrix Overhead 3Mbps 30Mbps 100Mbps Recovery
5,10 10% 175.5 ms 17.5 ms 5.3 ms 5 IP packets
10,10 10% 350.9 ms 35.1 ms 10.5 ms 10 IP packets
20,5 20% 350.9 ms 35.1 ms 10.5 ms 20 IP packets
8,8 12.5% 224.6 ms 22.5 ms 6.7 ms 8 IP packets
10,5 20% 175.5 ms 17.5 ms 5.3 ms 10 IP packets
8,5 20% 140.4 ms 14.0 ms 4.2 ms 8 IP packets
5,5 20% 87.7 ms 8.8 ms 2.7 ms 5 IP packets
4,6 16.7% 84.2 ms 8.4 ms 2.5 ms 4 IP packets
6,4 25% 84.2 ms 8.4 ms 2.5 ms 6 IP packets

Figure 10: Examples for overhead and delay in various FEC configurations 

Summary:
Packet loss is a common factor of today's IP networks, which can disturb the delivery of audio and
video data. If the transmitting channel is prone to disruption (wireless networks, oversaturated links),
this disturbances may lead to a heavily distorted media output on the receiving side.
Retransmission of lost packets would take too long. Transferring additional FEC data in parallel to the
media streams, which allow reconstruction in the event of packet loss induce a slightly higher
bandwidth usage and a bearable delay in favor of the ability to iron out a certain amount of lost
packets.

4
Standards:
FEC: Pro-MPEG Code of Practice #3 release 2 (with modifications)

Contact
For questions or sale queries please send a mail to mailto:sales@quicklink.tv. For further information
you can also visit our website www.quicklink.tv

5
FEC in Quicklink products

FEC in the Quicklink hardware series

All Quicklink hardware series en- and decoder implement two-dimensional FEC for RTP-streaming.
FEC can be switched on separately for the audio and video stream. The size of the FEC matrix is
configurable by choosing an FEC level or use the 'custom' level, which allows the user to choose an
arbitrary size for the FEC matrix.

The encoder will generate FEC packets for the rows and columns of the FEC matrix and send them to
the preconfigured ports. The information, that FEC streams are available and on which ports they are
streamed, are nested in the SDP file, that is downloaded and parsed by the decoder.

The following example shows the SDP file for the same audio/video RTP-stream. The first figure
shows the SDP file without FEC. In the second figure the lines, that are defining the FEC streams are
added in red ('in red'?).

• v=0
• v=0 • o=- 1421 1429 IN IP4 192.168.10.103
• o=- 1312 1320 IN IP4 192.168.10.103 • s=Quicklink Encoder
• s=Quicklink Encoder • c=IN IP4 224.1.1.103/32
• c=IN IP4 224.1.1.103/32 • t=0 0
• t=0 0 • b=AS:5128
• b=AS:5128 • a=control:*
• a=control:* • a=recvonly
• a=recvonly • a=type:broadcast
• a=type:broadcast • m=audio 20000 RTP/AVP 97 99 98
• m=audio 20000 RTP/AVP 97 • b=AS:128
• b=AS:128 • a=rtpmap:97 mpeg4-generic/48000/2
• a=rtpmap:97 mpeg4-generic/48000/2 • a=fmtp:97 streamtype=5; profile-level-id=15; mode=AAC-
• a=fmtp:97 streamtype=5; profile-level-id=15; mode=AAC- hbr; config=1190; SizeLength=13; IndexLength=3;
hbr; config=1190; SizeLength=13; IndexLength=3; IndexDeltaLength=3; Profile=1;
IndexDeltaLength=3; Profile=1; • a=control:trackID=1
• a=control:trackID=1 • a=rtpmap: 98 2dparityfec/48000
• m=video 20002 RTP/AVP 96 • a=fmtp:98 20008 IN IP4 224.1.1.103
• b=AS:5000 • a=rtpmap: 99 2dparityfec/48000
• a=rtpmap:96 H264/90000 • a=fmtp:99 20010 IN IP4 224.1.1.103
• a=cliprect:0,0,717,1280 • m=video 20002 RTP/AVP 96 99 98
• a=framesize:96 1280-720 • b=AS:5000
• a=framerate:50.00 • a=rtpmap:96 H264/90000
• a=fmtp:96 packetization-mode=1;profile-level- • a=cliprect:0,0,717,1280
id=4D4020;sprop-parameter- • a=framesize:96 1280-720
sets=Z01AIJZ0AoAt2AoEAAAcIAAK/ILRgAJiYAHJ1e98H • a=framerate:50.00
hEI1A==,aP48gA== • a=fmtp:96 packetization-mode=1;profile-level-
• a=control:trackID=2 id=4D4020;sprop-parameter-
sets=Z01AIJZ0AoAt2AoEAAAcIAAK/ILRgAJiYAHJ1e98H
hEI1A==,aP48gA==
• a=control:trackID=2
• a=rtpmap: 98 2dparityfec/90000
• a=fmtp:98 20004 IN IP4 224.1.1.103
• a=rtpmap: 99 2dparityfec/90000
• a=fmtp:99 20006 IN IP4 224.1.1.103

Figure 11: SDP data without FEC        Figure 12: SDP data with FEC