errors by appending redundancies, especially if they occur in bursts. The motivation
of RS FEC method is in its ability to maintain data integrity without retransmission and
its ability to handle network burst errors. There are various parameters that may be
adjusted when implementing RS codes to obtain different levels of error correction.
The number of bits used to represent a data symbol may be changed to focus on the
correction of different distributions of errors (such as scattered or in burst). The
number of data symbols in each encoded block may also be changed to vary the size of burst
errors it can handle. Finally, the symbol block size may be changed in relation to
the ratio of the number of errors it can handle to the amount of overhead redundancies
imposed. Reed-Solomon codes of 4-, 8-, and 16-bit symbols were implemented and
experimented with to reveal their actual error correction ability and their feasibility to
provide error control for VOD application.
The second method, HEC, focuses on concealing the errors in the MPEG
sequence headers and on maintaining video stream's format integrity. Researchers
have observed that if the error resides on the headers, the video will play with incorrect
frame rate and order. If excessive error resides on the headers, the MPEG decoder
terminates the decoding process, causing the MPEG player to quit prematurely. The
HEC error control method is implemented as follows. On the server side, each packet
is parsed to separate out the sequence headers from the image data. The sequence
headers are then encoded with RS codes before transmission. The client decodes to
correct errors in the sequence headers and then reinserts the headers back into the image
data in the proper position. The advantage of this method is that it imposes a low
overhead on the data transmission while maintaining the integrity of the video format.
Recall that maintaining the integrity of the video format ensures the success of
playing the whole video with correct frame rate throughout. However, the tradeoff is
that the quality of the image is not guaranteed.
A 2.5 Mb MPEG file was used as the
requested video program throughout the experiment. The video server rate controls
the transmission at 4 Mb/s, satisfying the real-time playing constraint of 30 frames/s. It
was observed that as the number of clients increased, the average throughput
since a single server has to serve an increasing number of clients. As throughput
decreased, the frame rate at which the server provided also decreased because such
application requires a large amount of CPU processing. Thus, the number of
concurrent clients a single server can handle is limited by the CPU's processing power.
The measurements showed that an UltraSparc 2, UltraSparc 1, and Sparc 5 could only
support up to 18, 10, and 5 concurrent clients, respectively, while maintaining the
transmission rate at 30 frames/s.
Simulation Model for Error Control Experiment
Random network errors and network burst
errors (i.e. example, due to congestion) were simulated for the error control experiments.
Random network error rates from 10-8 to 10-2 (in units of
bits) were simulated using a random number generator. Each experiment used an error
rate with a constant burst error size in the range of 1 to 10 bits. The errors were
simulated and inserted into the packet on the server side before transmission, but after
the error control decoder. On the client side, the error control decoder processed
the packet when it was first received, before any processing by the client. Figure 1
shows the simulation model used for error control experiments.
Error Rate and SNR with no error control.