Designing A Video On Demand Server Essay

, Research Paper

Designing a Video on Demand Server

INTRODUCTION

Video-on-demand (VoD) service will allow customers to request that certain movies or television shows be played on their television sets or computers immediately, giving individuals direct access to the materials stored in a video server. The goal of this project is to design a Video-on-Demand Server capable of performing to the following specifications:

+ Capacity – 25 feature-length movies

+ Serve 4 different movies simultaneously

+ No loss of video/audio

+ No “stutter” or skip

+ 100% fault tolerance

As previously discussed in the cost estimate, the Video on Demand (VoD) Server will be based on a multi-processor x86 architecture. The VoD server with all elements described in the cost estimate (excluding RAID level 4 support) will be implemented on the Windows NT operating system running on a 500MHz dual-processor Pentium III Xeon system with 512MB of memory. The configuration will consist of two Ethernet interfaces connected to an Ethernet switch on a T3 backbone, providing a peak network bandwidth of 30 Mbits/sec. Storage will consist of a set of four 18GB ULTRAWIDE SCSI-2 drives configured as a striped logical volume using standard Widows NT system tools. To further increase transfer speed, a 64MB hardware disk cache will also be used in the system. Arrays of optical drives will also be employed as secondary storage. The VoD Server will be linked to an array of Uninteruptable Power Supplies (UPS) capable of supplying 10 minutes of backup power.

Similar servers were tested in this configuration with multiple client access and was able to saturate the network with 150 clients playing MPEG1 and 2 streams. The effective network usage was 25 Mbits/sec. However, the network is saturated at this level due to the overhead associated with the TCP protocol. I expect CPU utilization vs. number of clients to be nearly linear as the number of clients increase.

In the following pages, I will discuss the qualities of an effective video server. Furthermore, I will also discuss the qualities of the video server which I have designed for this project.

HARDWARE

ARCHITECTURE

Video servers are basically large repositories for data and information which are provided on demand to clients. The VoD server architecture can be defined by the way the data is stored within the video server. Data can be stored locally within a server or can be distributed across a large number of servers. Thus, two distinct methodologies exist for video server configuration:

Autonomous Servers: Video servers of this type can be viewed as stand-alone entities since they store encoded streams locally to themselves and. thus, do not require the cooperation of other servers to serve a VoD client. The actual physical implementation and the logical implementation of the video server are relatively the same. The server usually consists of a CPU, a storage medium (which can consist of a standard storage hierarchy), and a network interface.

Distributed Servers: Instead of storing entire video streams locally, encoded streams may be spread out among a larger number of video servers which are usually distributed over a local (but can be a wider) area network. Thus, in order to serve a VoD client, a set of servers need to cooperate. The client may need to be aware of the topology of the VoD servers. The encoded bit stream can be stored in any granularity throughout the system.

Autonomous servers suffer from a well-known problem associated with centralized processing, i.e., the common point of failure. In this case, when an autonomous server fails, all the clients being served by it are affected. In the case of the distributed paradigm, if we assume that some loss of data can be tolerated at the cost of reduced Quality of Service (QoS) to the clients then when a server fails all the clients being served by the distributed system are affected as they all have a part of the encoded stream stored on the faulty server.

One of the driving forces behind the distributed server paradigm is the concept borrowed from Redundant Arrays of Inexpensive Disks (RAID). In order to serve a large number of clients from a VoD server, the server needs to have a large data bandwidth from the storage system to feed the demand from the VoD clients. In the field of scientific computing this large demand for bandwidth was provided by the RAID paradigm. For a VoD server, however, it does not appear that providing a large data bandwidth will necessarily lead to a larger number of clients being serviced. This is due to the fact that RAID was designed for a small number of large bulk data transfers which achieved the higher bandwidth. A VoD system, however, must service a large number of relatively low bandwidth requests. In the case of MPEG1 & 2 encoded video, this is typically about 2.5 Mbits/sec. Thus we might achieve better results by replicating autonomous servers to provide service.

The distributed system suffers also from the overhead associated with coordinating resources which are distributed across to service a single request. This overhead could be in terms of network bandwidth (by the use of an extra messaging protocol) or CPU usage. Alternatively, if the client needs to be aware of the server topology, the design may be harder to port to other network topologies. Thus, the best approach appears to be the autonomous server paradigm combined with the optimizing of each server to provide the best service it can by itself. These servers can then be distributed around a wider area network which can then provide service to VoD clients more efficiently. The VoD client can find the closest server storing a specific stream and fetch it on demand from that server.

STORAGE SYSTEM

Currently, video server design is regarded as a system integration issue where diverse components are haphazardly plugged together. In reality, video servers are complex entities that must address the requirements of individual video streams as well as system-wide requirements. The storage subsystem constitutes a major component of any media server. Yet, today, file system support for continuous media is very limited.

As noted above, RAID systems are not suitable for VoD systems. The performance of the storage subsystems is critical to the efficient functioning of the VoD server. The storage system needs to support multiple I/O requests and provide the data back to the server so that it can be pumped over the network to the client.

In order to increase the bandwidth from the I/O subsystem, asynchronous I/O requests are issued. Thus, anticipated demands for data can be queued to disk so that the data is available when it is needed by the clients. This pre-fetching of data before it is needed results in seamless flow of data and the effect of jitter observed by the client.

Due to the fact that most of the video streams play continuously, pre-fetching is an efficient and effective way of screening disk I/O latency. In similarly implemented video servers, I have never observed the system to become disk I/O bound. This conclusion contrasts with the popular belief that the video server’s performance is critically dependent on I/O performance.

SOFTWARE

The software packages which would be required for this project include:

1. MS Windows NT Server (Version 4 or above)

2. Video server for NT Server (production version)

3. ActiveMovie video client (Windows 95, Windows NT)

4. A packet of routines implementing database back-end interface.

The video server must be able to service multiple client requests simultaneously. This might lead us to investigate the potential for exploiting parallelism at the server side in future upgrades of the server. A video server should be capable of pumping streams requested by clients. It should also provide basic interactivity, i.e., support operations such as stop, rewind, play a video, and, possibly, provide random access to the video stream with some sort of fast-forward preview. Thus, the video server should provide two basic functionalities:

A data pumping module

An interface to enable interactivity with the stream.

An interface is defined to enable the client to interact with the stream in a consistent manner. A consistent interface leads to cross platform development, i.e., clients can be developed on multiple platforms and communicate in a predictable way with servers built on multiple platforms. This leads to transparent execution between cross-party platforms.

The architecture of the video server design is shown above. The server contains two distinct logical– the data and the command ports. The data link is logically a unidirectional link with data flowing from the server to the client. The command link is a bi-directional and is used to implement the application level interface between the server and the client. The data link was chosen to be unidirectional for efficiency as no parsing of packets need to be performed at the client end.

VIDEO DATA TRANSPORT

The methology of video data transport is a crucial factor in the efficiency of the system. Below I will discuss the following methods of video data transport and the method which I have selected to be used by the server.

Conventionally, dataflow in a Video on Demand (VoD) system moves from the video server to the client. The client requests data from the server, which results in data being streamed from the server to the client. There are two regimes of data being streamed from the server to the client: the pull regime and the push regime.

In the pull regime of dataflow, the VoD client determines how much data is needed and sends a request for that amount to the VoD server. The VoD server responds with the amount of data requested. The client then receives this data in a variable amount of time and requests more data from the server. This cycle continues until the whole movie is played out. The data, thus, is being pulled on demand by the client.

The push regime is orthogonal to the pull model. Here, the client does not request any data from the server; rather, the data is furnished by the server on a continuous basis. This form of data flow is especially suitable for Constant Bit Rate (CBR) coded movies. By this I mean that a certain amount of data is always consumed within a certain time period.

An example of this encoding is the MPEG1 and 2 video standard. This model can be applied also to a Variable Bit Rate (VBR) encoded stream since the server can transform the VBR stream into a CBR stream and transmit the data at this rate.

There are fundamental differences between the push and the pull model. In the pull model, data transfer is initiated at request of the receiver. Hence this can be classed as a receiver-initiated mode of data transfer. The push model of data transfer, on the other hand, is sender initiated. Here, the sender (e.g. a VoD server) determines when and how much data is to be sent.

The pull model contains a significant performance penalty since two communication transfers are needed to transfer a unit of data: a request for the data and the actual data transfer. In a VoD system, we are dealing with isochronous data, i.e. data which has strict limits on when it needs to be delivered and which must preserve the timing relation contained within the data. Thus the request-response structure of the pull model introduces an undesirable delay.

The push model, on the other hand, exploits the properties of isochronous data (i.e., data transmitted by the server at a given rate, on the assumption that it is being consumed at the same rate). This assumption holds for CBR encoded streams and needs to be extended to VBR encoded data. By using the isochronous properties of the data, the push model eliminates the traditional request-response model of data flow, thus eliminating delay and preserving network bandwidth.

Several manufacturers of high-end VoD servers have developed a methodology to efficiently transport VBR data over CBR channels and are currently using this method. Thus, I believe that the push regime can accommodate both CBR and VBR traffic. In addition, I have observed that the push regime is consistent with the two fundamental components of the Integrated Services Model for Internet: multicast and Quality of Service (QoS) support via the Reservation Protocol. For multicast, the push regime is obviously the correct solution. For the Reservation Protocol, even though the client issues reservation requests, the traffic descriptors must be provided by the sender. This is compatible only with the push regime of data transport.

It is important to note that the push regime does not preclude interactivity and random access capability. It is still possible to pause and randomly access the video stream. It is possible also to extend this capability to multicasted sessions.

BIBLIOGRAPHY

1.CBR Transmission of VBR Encoded Continuous Media in Video on Demand

Servers, by M. Del Rosario and Geoffrey C. Fox (presented at the 2nd IASTED/ISMM International Conference, Palo Alto, California, August 85);

2. Constant Bit Rate Network Transmission of Variable Bit Rate Continuous Media in Video on Demand Servers, by M.DelRosario and Geoffrey C. Fox, published in Multimedia Tools and Applications 3, 215-232 (1996); and

3. m-Frame granular transport and buffer requirements for VBR encoded media in VoD servers, by M. DelRosario, M. Podgorny, and Geoffrey C. Fox, March 1996

4. NPAC Technical Report SCCS-733, March 1996

5. http://www.pricewatch.com

6. http://www.videoserver.com/html/products_applications/products_applications.html

7. W. Tetzlaff, M. Kienzle, and D. Sitaram, “A Methodology for Evaluating Storage Systems in Distributed and Hierarchical Video Servers,” Proc. IEEE COMPCON, Feb. 1994.

8.W. Tetzlaff, M. Kienzle, and D. Sitaram, “Using a Storage Hierarchy in Movie-on-Demand Servers,” submitted to ACM Multimedia, 1994.

9.http://www.schange.com/products/index_products.html