Rate Control

Since the design involves synchronization between the server and its multiple clients, rate control plays a major issue.  To ensure synchronization, a Timer layer, which resides above both the server and the client layer, is implemented.  The Timer has two primary duties.  One duty is to ensure the proper timing of the server in sending packets to the client.   This is implemented by setting a clock resident at the server and transmitting the parsed frame to the client at each clock tick.  The clock is implemented by measuring the elapsed time between the last packet sent to the client and the time the next packet is ready to be sent.  Each packet that is sent to the client passes through the Transmitter, which passes the packet on to the client.  The clock reads the current time when a new packet is sent to the Transmitter and reads the time again when the Transmitter acknowledges that it is ready for the next packet transmission.  The time of the next packet transmission is determined by subtracting the latter time from the former time.

The second duty of the Timer is to ensure that neither the server nor the client does indefinite waiting.  This is implemented by setting two alarms, one for the server and the other for the client, used for a time-out purpose.  The alarms will guarantee that if the server crashes, the client will eventually time-out instead of waiting endlessly for packets from the server.  Similarly, if the client crashes, the server will time-out instead of waiting endlessly for client acknowledgment.

To obtain control over the transmission rate, and to avoid overflow or underflow, one must understand the structure of the MPEG.  A full-motion video consists of a set of pictures to be displayed sequentially.  These pictures (frames) are MPEG-compressed, producing bit streams that represent the pictures as well as control information for the MPEG decoder.  The bit streams are arranged into hierarchical structures from frames, down to individual pixels.  One reason for such arrangement is to provide random access to the video sequence.  The following BNF notation describes the MPEG bit stream1:

table1.gif (6526 bytes)

Control information is stored in the header of each group and provides information about the specific group needed by the decoder.  For example, the slice header provides slice information such as the position of the slice in a frame as well as the quantifier scale.

All group headers start with a unique 32-bit code to distinguish one group from another. Thus a frame header start code will be different from the slice header start code.   Fields in the MPEG sequence header also indicate the frame rate in which the video program should be displayed.  Therefore, based on the MPEG structure, transmission rate can be controlled using any of the MPEG sub-structures (i.e. frame, slide, and macroblock) as a rate control unit.  These structures could allow varying levels of coarse to fine granularity.  Fine grain control would require a large processing overhead to parse the MPEG bit stream.  In the experiment, MPEG files are parsed according to the frame header start code and sent to the client one frame at a time. It is uncertain that sending frame by frame is optimal in comparison to sending by slice or by macroblock.  Further experimentation is necessary.  However, sending by frame instead of by slice or by macroblock will reduce the overhead processing time at the client side since a frame is much larger than a slice and macroblock.  To clarify, the client need not process as many packet headers.  Shorter overhead processing time is favored because the VOD system must satisfy a real-time constraint of 30 frames/s. Furthermore, with a shorter overhead processing time, a single server can handle more clients.

Error Control

Network conditions are not always optimal.  Random network errors and network burst errors (i.e. due to congestion) may degrade the quality of the transmitted MPEG video stream severely and to an unacceptable level.  Error control methods that alleviate this situation are achieved either by correcting the errors or by concealing the errors.  Error control methods can be categorized into two main categories: forward error correction (FEC) and selective retransmission. Selective retransmission, however, is not feasible due to the possible network latency delay in the retransmission, which violates the requirement of a good VOD system. Because the VOD system is a real-time application, selective retransmission methods may lead to rate control complexity and cause problems such as data under-flow.   In either case, the retransmitted data may arrive too late to be of any use.   Thus, FEC methods are favored for real-time applications such as VOD.

Two forward error correction methods, the Reed-Solomon Forward Error Correction (RS FEC) and the Header Error Concealment (HEC), are implemented and investigated. Reed-Solomon FEC encodes each packet with RS codes on the server side before transmission, decodes the packets, corrects errors within range, and maintains data integrity on the client side. Reed-Solomon codes are non-binary codes capable of

back.gif (221 bytes) next


Page 3

 

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