You are on page 1of 6

Keywords: Forward Error Correction, FEC, Packet-loss

Forward Error Correction


Version
0.6

Date
2009-11-30

Author

Comment

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.

Figure1:FECoverview

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.

Figure2:FECpacketgenerationontheencoderside(onedimensionalFEC)

Figure3:Packetreconstructiononthedecoderside(onedimensionalFEC,1packetlost)

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.

Figure4:Reconstructionimpossible(onedimensionalFEC,2packetslost)

Types of packet-loss
Random errors
Random packet loss will likely result in a scattered
pattern of lost packets in the stream, which should
be easy to correct with one-dimensional FEC.

Figure5:Randompacketloss

Bursterrors

Packet loss occurring in bursts cannot be recovered


by one-dimensional FEC. By adding another dimension
and thus employing an FEC matrix, burst errors can be
recovered.

Figure6:Burstsofpacketloss

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.

Figure8:Packetreconstructiononthe
decodersidewiththerightreconstruction
orderdepicted(twodimensionalFEC,7
packetlost)

Figure7:FECpacketgenerationontheencoderside
(twodimensionalFEC)

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.

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.

FEC matrix
5,10
10,10
20,5
8,8
10,5
8,5
5,5
4,6
6,4

Overhead
10%
10%
20%
12.5%
20%
20%
20%
16.7%
25%

Latency
30Mbps
17.5 ms
35.1 ms
35.1 ms
22.5 ms
17.5 ms
14.0 ms
8.8 ms
8.4 ms
8.4 ms

3Mbps
175.5 ms
350.9 ms
350.9 ms
224.6 ms
175.5 ms
140.4 ms
87.7 ms
84.2 ms
84.2 ms

100Mbps
5.3 ms
10.5 ms
10.5 ms
6.7 ms
5.3 ms
4.2 ms
2.7 ms
2.5 ms
2.5 ms

Recovery
5 IP packets
10 IP packets
20 IP packets
8 IP packets
10 IP packets
8 IP packets
5 IP packets
4 IP packets
6 IP packets

Figure10:ExamplesforoverheadanddelayinvariousFECconfigurations

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.

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

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
o=- 1312 1320 IN IP4 192.168.10.103
s=Quicklink Encoder
c=IN IP4 224.1.1.103/32
t=0 0
b=AS:5128
a=control:*
a=recvonly
a=type:broadcast
m=audio 20000 RTP/AVP 97
b=AS:128
a=rtpmap:97 mpeg4-generic/48000/2
a=fmtp:97 streamtype=5; profile-level-id=15; mode=AAChbr; config=1190; SizeLength=13; IndexLength=3;
IndexDeltaLength=3; Profile=1;
a=control:trackID=1
m=video 20002 RTP/AVP 96
b=AS:5000
a=rtpmap:96 H264/90000
a=cliprect:0,0,717,1280
a=framesize:96 1280-720
a=framerate:50.00
a=fmtp:96 packetization-mode=1;profile-levelid=4D4020;sprop-parametersets=Z01AIJZ0AoAt2AoEAAAcIAAK/ILRgAJiYAHJ1e98H
hEI1A==,aP48gA==
a=control:trackID=2

Figure11:SDPdatawithoutFEC

v=0
o=- 1421 1429 IN IP4 192.168.10.103
s=Quicklink Encoder
c=IN IP4 224.1.1.103/32
t=0 0
b=AS:5128
a=control:*
a=recvonly
a=type:broadcast
m=audio 20000 RTP/AVP 97 99 98
b=AS:128
a=rtpmap:97 mpeg4-generic/48000/2
a=fmtp:97 streamtype=5; profile-level-id=15; mode=AAChbr; config=1190; SizeLength=13; IndexLength=3;
IndexDeltaLength=3; Profile=1;
a=control:trackID=1
a=rtpmap: 98 2dparityfec/48000
a=fmtp:98 20008 IN IP4 224.1.1.103
a=rtpmap: 99 2dparityfec/48000
a=fmtp:99 20010 IN IP4 224.1.1.103
m=video 20002 RTP/AVP 96 99 98
b=AS:5000
a=rtpmap:96 H264/90000
a=cliprect:0,0,717,1280
a=framesize:96 1280-720
a=framerate:50.00
a=fmtp:96 packetization-mode=1;profile-levelid=4D4020;sprop-parametersets=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

Figure12:SDPdatawithFEC