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