Introduction

Video On Demand (VOD) is one of the most promising future multimedia services that allow users to view video programs at a desired time.  Video programs are stored in a server with a compression format (such as MPEG1) to reduce the necessary disk space and transmission bandwidth.   Upon the request of a user, the video server delivers through a network the requested video program.  Users are equipped with a TV set-top box that provides interactive operations such as pause and stop, slow and fast forward, and rewind.  A good VOD system should handle startup and interactive requests by having low latency, requiring small buffering capability at the user's TV set-top box, and supporting a large number of concurrent users with guaranteed Quality Of Service (QOS).2

VOD can be realized using emerging broadcast network infrastructures based on Asynchronous Transfer Mode (ATM) technology.3  ATM networks provide high speed transport and QOS guarantee, attending the requirements of a good VOD system.   However, due to ATM novelty, there is a lack of experience on transport of multimedia traffic.  Standardization bodies are still attempting to understand how ATM performs outside the theoretical realm.  There are many factors that may not have been properly accounted for in theoretical performance analysis; such factors may only be thoroughly investigated through network experiments and simulations.

In this paper, ATM performance is evaluated through experiment and simulation.  A prototype application that distributes MPEG video over an ATM network is developed to investigate the suitability of ATM technology for transporting compressed video as MPEG. This prototype VOD application is based on a video server where the video programs are stored as an MPEG, and users can request and play the video programs in real-time. This prototype is used to investigate design issues such as rate control and error control. In addition, performance measures such as throughput and frame rate are presented to demonstrate the suitability of ATM technology for transporting such multimedia traffic.  The performance measures presented in this paper will enhance knowledge of the behaviors, limitations, and possible improvements of ATM network in supporting multimedia applications.

Design

The design of the prototype VOD application is based on the client/server architecture, focused to provide rate and error control.   The architecture consists of a concurrent server and one or more clients. The server

architecture consists of several modules that handle various tasks of the concurrent server.  One module listens to the network connection and creates a new thread for each client request received.  Another module's responsibility is to copy chunks of the MPEG file from the local disk resident at the server side into a buffer and parse the buffer into MPEG frames. Several of these parsed frames are then loaded into memory; there, they wait for the appropriate transmission time.

There are two reasons to have a number of frames ready and waiting in memory.  The first involves a situation where it is time for the server to transmit, but the frames are still in the process of being parsed.  The server pauses and waits until the frame is completely parsed to transmit, creating an uneven flow of data to the client. Significant consecutive transmission pauses from the server will create an underflow of data to the decoder at the client.  The result is a possible degradation of video quality or the termination of the MPEG decoder altogether.  The second reason involves the kernel scheduler.  Since the server is concurrent, multiple clients can view different videos simultaneously.  This means multiple threads are reading data from a disk, leaving the scheduler to decide which thread's instruction to handle at any one time.  Since there is a fixed amount of time to retrieve data from a disk, some of the threads will be blocked until the disk drive is available.  This blocking creates a pause in the frame parsing process and delays the server transmission time.  Again, if there are no parsed frames ready in memory, the server transmission time may be delayed, which leads to data underflow.

The client architecture consists of four separate buffers and three distinct processes: the producer, the consumer, and the MPEG play process.  The producer process receives packets from the server and copies the packet payload into one of three buffers: buf1, buf2, and buf3.  The goal of the producer is to keep buf1, buf2, and buf3 filled throughout the packet transmission.  Semaphore locks are placed on buf1, buf2, and buf3 to avoid the race condition problem.  The consumer reads from one of the three buffers and fills the fourth buffer (temp_file) in packet sequential order.  The fourth buffer (temp_file) is the actual MPEG bit stream from the server.   The MPEG play process executes the MPEG decoder to decode temp_file.  The fourth buffer (temp_file) is necessary because the decoder must always have data to process.  Of course, the decoder assumes the end of the MPEG file is reached and terminates otherwise.

back.gif (221 bytes) next


Page 2

 

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