VBrick 9000 Admin Manual page 184

RTP packets. This specification was extended by the Pro-MPEG forum in Pro-MPEG Code
of Practice #3 and later adopted by SMPTE as SMPTE Standard 2022-1. This standard has
been further extended in SMPTE Standard 2022-2, and 2022-3. This is the algorithm VBrick
has implemented in the 7000 encoders. Direct reference to these specifications is
recommended, but a brief discussion of how to utilize the FEC capabilities follows.
The FEC algorithm can be viewed as providing additional XOR packets for a matrix of
packets with L Columns and D Rows. FEC is provided as up to two separate streams which
are received on separate UDP ports. One stream supports XOR for a row of the matrix - L
adjacent packets. This XOR scheme provides for recovery from one single packet loss in a
group of L packets. The second stream supports XOR for a column of the matrix – D
packets. This second stream provides for recovery from a burst of lost adjacent packets. If
the destination port for the media stream is N, then the first stream is sent to port N+2, and
the second stream to port N+4.
It can be seen that the overhead added for the scheme is 1/L for the first stream and 1/D for
the second stream. For both streams the overhead is (L+D)/(L*D). Clearly as the matrix size
is reduced, the overhead is increased and the ability to recover from random errors is
increased. On the other hand, more overhead does not always lead to better recovery. If burst
errors are expected, it is desirable to have L to be at least the length of the expected burst
error. Whether you are better off with more rows or more columns depends on the statistics
of the errors. Row FEC packets are good for protecting against single packet losses in a row.
Column FEC packets protect against single packet errors in a column. So - if your errors are
random, then rows are better, but if your errors tend to come in bursts, then the row FEC
does not help you as much. You need to have at least as many columns in your matrix as the
largest expected burst. If you knew your statistics were always going to come in a burst of 10
packets with the bursts being random and rare then you would turn off the row FEC and
would create a matrix with a at least 10 columns. In this case (for example) a 50 row and 10
column matrix would be better than a 5 row by 5 column matrix.
When determining the FEC configuration, potential limitations of the FEC receiver need to
be understood. In the specific case of the VBrick VB7000 Series decoder, the limitations are:
L*D <= 100; 1<=L<=20; 4<=D<=20. In addition, since in order to recover a packet, both
the row and column FEC packet must be received, an additional end-to-end latency equal to
the time to receive LXD packets will be incurred. The Encoder Configuration > Streams
page in VBAdmin shows the overhead and the latency incurred by each configuration.
Since the specifics of configuration are highly dependent on the expected packet loss
statistics, and specific latency requirements of the application, it is not possible to provide
guidelines that will work in all situations. It is, however, possible to provide some examples.
Note that for random bit errors, each bit error will cause loss of an entire packet so that (for
example) if utilizing 1500 byte packets, a bit error rate of 1 in 1,000,000 will translate to a
packet loss rate of 1.2% and a bit error rate of 1 in 100,000 will translate to a packet loss rate
of 12%. In these cases, a 10x10 matrix is adequate to recover from virtually all errors. The
overhead in this case is 20/100 or 10%.
If the error rate and bandwidth constraints are such that it is not possible to eliminate all
video artifacts with FEC configuration, it should be noted that generally artifacts will persist
until a reference frame is successfully received. The user's experience may be improved by
reducing the on the Encoder Configuration > Video Input page. However
IDR Frame Interval
be aware that IDR frames are very expensive in terms of bandwidth utilization so reducing
the IDR interval will cause a general degradation of video quality/sharpness.
176 © 2015 VBrick Systems, Inc.