correcting 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

decreased, 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.

figure1.gif (5847 bytes)
Figure 1
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.

figure2.gif (4910 bytes)
Figure 2
Error Rate and SNR with no error control.

back.gif (221 bytes) next

Page 4


Chin-Yu Chen - Error Control For Video On Demand ... [1] [2] [3] [4] [5] [6]