Video Over IP

Inside Pro-MPEG FEC

Professional video streaming over IP networks has become a reality and this paper provides an
insight into the workings of Pro-MPEG CoP#3 Forward Error Correction (FEC) in protecting
contribution and distribution services.

In transporting real-time media over IP networks either UDP or RTP (Real Time Protocol) protocols
can be used. RTP provides packet sequence ordering over UDP, enabling a receiver to identify out of
sequence, discarded or reordered packets so is more robust than UDP. The Pro-MPEG CoP #3 FEC
scheme uses the RTP transport protocol as a building block for providing packet recovery techniques
to ensure reliable real-time media transport.

The MPEG Transport Stream (TS) packets must first be packed into IP frames. Since most streams
will pass over an Ethernet network at some point, whose MTU (Maximum Transmission Unit) is
1500, the IP frame must be constrained so that fragmentation does not occur. This limits the
number of TS packets to a maximum of 7 per IP packet. Packing the maximum of seven 188 byte
packets into an IP packet gives optimum packing efficiency at the cost of excessive data loss per a
packet. If only a single MPEG packet is placed in an IP packet minimal loss of data occurs on packet
loss, at the cost of higher transmission overheads, which in turn will place greater demand on the
network. The illustration below shows the maximum of seven MPEG-2 TS packets packed into a
single RTP packet. RFC2733 defines the RTP payload format to allow error correcting of real-time

media. The RTP format does not care about the video format inside, so MPEG, SDI, SDTI etc packets
can be encapsulated as long as RTP encapsulation is used. RTP restricts the number of consecutive
packets that can be used to generate the error-correcting packets to 24 limiting the burst correction
capabilities. The Pro-MPEG CoP #3 FEC defines an extension, which allows non-consecutive packets
to be used for generating the FEC error correcting packet. In this scheme periodically selected media
packets are used to generate the FEC packet.

The generation of the FEC packets is based on the use of a

matrix. The matrix size is defined by two parameters L and D, L
is the spacing between non-consecutive packets to be used to
calculate the FEC packet and D is the depth of the matrix.

The scheme defines the generation of two types of FEC packet

these being Column FEC and Row FEC packets. This matrix
shows Column FEC packet generation for a matrix of L =4 and
D=4. The size of the matrix trades between latency,
transmission overhead and error protection. Once the media
packets are aligned in the matrix the FEC packets are computed
by XOR (exclusive or) of the media packets along the column or
row of the matrix. In column FEC this means that every Lth
media packets is XOR’d with the next L packet thus 0L⊕L⊕2L⊕3L
= FEC0 in a matrix of 4x4. In Row FEC consecutive media
packets on each row are XOR’d to generate the FEC packet. The
error-correcting scheme can be changed but for Pro-MPEG CoP
#3 Issue 2 equipment shall only use the XOR type.
Column FEC provides correction for consecutive burst packet loss of up to L packets. The FEC
packets are generated per a column within the matrix allowing loss of any single media packet
within a column or burst of error within a row to be corrected through the FEC packet. Column FEC
is ideal for correcting packet burst errors and random errors.

Row FEC provides correction of non-consecutive packet loss and can correct any single packet loss
within a row of media packets. The FEC packets are generated per a row allowing loss of any single
packet to be recovered. Row FEC is ideal for correcting random packet errors.

Column FEC is often called 1D FEC due to the FEC only being calculated on 1 dimension where
Column and Row FEC is referred to as 2D FEC due to the FEC being calculated on 2 dimensions,
column and row.

The combination of Column and Row FEC provides a robust error protection scheme capable of
dealing with random and burst errors, and is able to correct more errors than either column or row
schemes can independently.

Once the FEC packets have been computed they must be transmitted with the media packets to the
receivers. The standard defines that the media and FEC packets are transmitted separately on
different UDP ports. The diagram shows the transmission of the media packet on port n while the
column FEC packets are transmitted on port n+2 and row FEC packets on port n+4 as defined in the
Pro-MPEG CoP #3 standard.

This enables reception by both non-enabled and enabled FEC receivers, the FEC enabled receivers
can utilise the additional FEC streams to correct any missing or corrupted media packets while non-
enabled receivers are unaffected by the FEC packets and will simply ignore them.

The transmitted media and FEC streams are received at the receive site. The receiver should use the
available FEC packets to the best of its ability to reconstruct the original media stream. The
illustration below shows the correction of missing packets using the available column and row FEC
packets to recover the missing media packets.
The errors on a network, which can affect a media stream, are packet loss due to channel bit errors,
burst packet loss due to network buffers and network re-route. We have now seen the complete
cycle starting with encapsulation, and then FEC packet generation to lost packet recovery. The
protection offered by the FEC scheme comes at a cost in terms of additional transmission latency
and bandwidth overhead.

However the Pro-MPEG CoP #3 FEC scheme enables broadcasters to select the correct matrix size
and FEC scheme allowing the broadcaster to provide the correct level of protection within the
transmission constraints such as bandwidth.

The size of the matrix and the FEC scheme defines the transmission overhead required over a pure
RTP transmission, the table below shows the overhead associated with 1D FEC and 2D FEC for
encapsulation of 7 MPEG-2 Transport Stream packets per an IP packet.

The current issue of the Code of Practice only covers the transmission of CBR Constant Bit Rate
MPEG-2 transport stream packets. This is not to be confused with variable bit rate video coding. In a
CBR transmission the transmission bit rate remains constant allowing the receiver to lock on and
determine the MPEG-2 PCR (Program Clock Reference).

Quantifying the benefits of using FEC is dependent on many factors such as network error and the
type of errors. The benefit of using FEC can best be summarized with the following statement.

“In transmitting a broadcast service over an IP network, if you occasional notice a disruption in the
service which is annoying the use of FEC will ensure that you are perfectly happy as the occasional
glitch will now be very occasional to the point were you are unlikely to notice any service disruption.
An hypothetical example would be a glitch that occurs every few days may happen once a year.”

Please contact TANDBERG Television for further information on Video Over IP solutions.