, Research Paper

Planing a Video on Demand Server

Introduction

Video-on-demand ( VoD ) service will let clients to bespeak that certain films or telecasting shows be played on their telecasting sets or computing machines instantly, giving persons direct entree to the stuffs stored in a picture waiter. The end of this undertaking is to plan a Video-on-Demand Server capable of executing to the undermentioned specifications:

+ Capacity & # 8211 ; 25 feature-length films

+ Serve 4 different films at the same time

+ No loss of video/audio

+ No & # 8220 ; stammer & # 8221 ; or jump

+ 100 % mistake tolerance

As antecedently discussed in the cost estimation, the Video on Demand ( VoD ) Server will be based on a multi-processor x86 architecture. The VoD waiter with all elements described in the cost estimation ( excepting RAID degree 4 support ) will be implemented on the Windows NT runing system running on a 500MHz dual-processor Pentium III Xeon system with 512MB of memory. The constellation will dwell of two Ethernet interfaces connected to an Ethernet switch on a T3 anchor, supplying a peak web bandwidth of 30 Mbits/sec. Storage will dwell of a set of four 18GB ULTRAWIDE SCSI-2 thrusts configured as a stripy logical volume utilizing standard Widows NT system tools. To farther addition transportation velocity, a 64MB hardware disc cache will besides be used in the system. Arraies of optical thrusts will besides be employed as secondary storage. The VoD Server will be linked to an array of Uninteruptable Power Supplies ( UPS ) capable of providing 10 proceedingss of backup power.

Similar waiters were tested in this constellation with multiple client entree and was able to saturate the web with 150 clients playing MPEG1 and 2 watercourses. The effectual web use was 25 Mbits/sec. However, the web is saturated at this degree due to the operating expense associated with the TCP protocol. I expect CPU use vs. figure of clients to be about additive as the figure of clients addition.

In the undermentioned pages, I will discourse the qualities of an effectual picture waiter. Furthermore, I will besides discourse the qualities of the picture waiter which I have designed for this undertaking.

Hardware

Architecture

Video waiters are fundamentally big depositories for informations and information which are provided on demand to clients. The VoD waiter architecture can be defined by the manner the information is stored within the picture waiter. Datas can be stored locally within a waiter or can be distributed across a big figure of waiters. Therefore, two distinguishable methodological analysiss exist for picture waiter constellation:

Autonomous Waiters: Video waiters of this type can be viewed as stand-alone entities since they store encoded watercourses locally to themselves and. therefore, do non necessitate the cooperation of other waiters to function a VoD client. The existent physical execution and the logical execution of the picture waiter are comparatively the same. The waiter normally consists of a CPU, a storage medium ( which can dwell of a standard storage hierarchy ) , and a web interface.

Distributed Waiters: Alternatively of hive awaying full picture watercourses locally, encoded watercourse may be spread out among a larger figure of picture waiters which are normally distributed over a local ( but can be a wider ) country web. Therefore, in order to function a VoD client, a set of waiters need to collaborate. The client may necessitate to be cognizant of the topology of the VoD waiters. The encoded spot watercourse can be stored in any coarseness throughout the system.

Autonomous waiters suffer from a well-known job associated with centralised processing, i.e. , the common point of failure. In this instance, when an independent waiter fails, all the clients being served by it are affected. In the instance of the distributed paradigm, if we assume that some loss of informations can be tolerated at the cost of decreased Quality of Service ( QoS ) to the clients so when a waiter fails all the clients being served by the distributed system are affected as they all have a portion of the encoded watercourse stored on the faulty waiter.

One of the drive forces behind the distributed waiter paradigm is the construct borrowed from Redundant Arrays of Inexpensive Disks ( RAID ) . In order to function a big figure of clients from a VoD waiter, the waiter needs to hold a big informations bandwidth from the storage system to feed the demand from the VoD clients. In the field of scientific calculating this big demand for bandwidth was provided by the RAID paradigm. For a VoD waiter, nevertheless, it does non look that supplying a big information bandwidth will needfully take to a larger figure of clients being serviced. This is due to the fact that RAID was designed for a little figure of big majority informations transportations which achieved the higher bandwidth. A VoD system, nevertheless, must serve a big figure of comparatively low bandwidth petitions. In the instance of MPEG1 & A ; 2 encoded picture, this is typically approximately 2.5 Mbits/sec. Thus we might accomplish better consequences by retroflexing independent waiters to supply service.

The distributed system suffers besides from the operating expense associated with coordinating resources which are distributed across to serve a individual petition. This operating expense could be in footings of web bandwidth ( by the usage of an excess messaging protocol ) or CPU use. Alternatively, if the client needs to be cognizant of the waiter topology, the design may be harder to port to other web topologies. Therefore, the best attack appears to be the independent waiter paradigm combined with the optimizing of each waiter to supply the best service it can by itself. These waiters can so be distributed around a wider country web which can so supply service to VoD clients more expeditiously. The VoD client can happen the closest waiter hive awaying a specific watercourse and bring it on demand from that waiter.

Storage System

Presently, picture waiter design is regarded as a system integrating issue where diverse constituents are randomly plugged together. In world, picture waiters are complex entities that must turn to the demands of single picture watercourses every bit good as system-wide demands. The storage subsystem constitutes a major constituent of any media waiter. Yet, today, file system support for uninterrupted media is really limited.

As noted above, RAID systems are non suited for VoD systems. The public presentation of the storage subsystems is critical to the efficient operation of the VoD waiter. The storage system needs to back up multiple I/O petitions and supply the informations back to the waiter so that it can be pumped over the web to the client.

In order to increase the bandwidth from the I/O subsystem, asynchronous I/O petitions are issued. Therefore, anticipated demands for informations can be queued to harrow so that the information is available when it is needed by the clients. This pre-fetching of informations before it is needed consequences in seamless flow of informations and the consequence of jitter observed by the client.

Due to the fact that most of the picture watercourses play continuously, pre-fetching is an efficient and effectual manner of testing disc I/O latency. In likewise implemented picture waiters, I have nev

er observed the system to go disk I/O edge. This decision contrasts with the popular belief that the picture server’s public presentation is critically dependent on I/O public presentation.

Software

The package bundles which would be required for this undertaking include:

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

2. Video waiter for NT Server ( production version )

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

4. A package of modus operandis implementing database back-end interface.

The picture waiter must be able to serve multiple client petitions at the same time. This might take us to look into the potency for working correspondence at the server side in future ascents of the waiter. A picture waiter should be capable of pumping watercourses requested by clients. It should besides supply basic interactivity, i.e. , back up operations such as halt, rewind, play a picture, and, perchance, provide random entree to the picture watercourse with some kind of fast-forward prevue. Therefore, the picture waiter should supply two basic functionalities:

A information pumping faculty

An interface to enable interactivity with the watercourse.

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

The architecture of the picture waiter design is shown supra. The waiter contains two distinguishable logical & # 8211 ; the information and the bid ports. The information nexus is logically a unidirectional nexus with informations fluxing from the waiter to the client. The bid nexus is a bi-directional and is used to implement the application degree interface between the waiter and the client. The information nexus was chosen to be unidirectional for efficiency as no parsing of packages need to be performed at the client terminal.

VIDEO DATA TRANSPORT

The methology of picture informations conveyance is a important factor in the efficiency of the system. Below I will discourse the undermentioned methods of picture informations conveyance and the method which I have selected to be used by the waiter.

Conventionally, dataflow in a Video on Demand ( VoD ) system moves from the picture waiter to the client. The client petitions data from the waiter, which consequences in informations being streamed from the waiter to the client. There are two governments of informations being streamed from the waiter to the client: the pull government and the push government.

In the pull government of dataflow, the VoD client determines how much information is needed and sends a petition for that sum to the VoD waiter. The VoD waiter responds with the sum of informations requested. The client so receives this information in a variable sum of clip and petitions more informations from the waiter. This rhythm continues until the whole film is played out. The information, therefore, is being pulled on demand by the client.

The push government is extraneous to the pull theoretical account. Here, the client does non bespeak any informations from the waiter ; instead, the information is furnished by the waiter on a uninterrupted footing. This signifier of informations flow is particularly suited for Changeless Bit Rate ( CBR ) coded films. By this I mean that a certain sum of informations is ever consumed within a certain clip period.

An illustration of this encryption is the MPEG1 and 2 video criterion. This theoretical account can be applied besides to a Variable Bit Rate ( VBR ) encoded watercourse since the waiter can transform the VBR watercourse into a CBR watercourse and convey the information at this rate.

There are cardinal differences between the push and the pull theoretical account. In the pull theoretical account, informations transportation is initiated at petition of the receiving system. Hence this can be classed as a receiver-initiated manner of informations transportation. The push theoretical account of informations transportation, on the other manus, is sender initiated. Here, the transmitter ( e.g. a VoD waiter ) determines when and how much information is to be sent.

The pull theoretical account contains a important public presentation punishment since two communicating transportations are needed to reassign a unit of informations: a petition for the informations and the existent information transportation. In a VoD system, we are covering with isochronal informations, i.e. information which has rigorous bounds on when it needs to be delivered and which must continue the timing relation contained within the informations. Thus the request-response construction of the pull theoretical account introduces an unwanted hold.

The push theoretical account, on the other manus, exploits the belongingss of isochronal informations ( i.e. , informations transmitted by the waiter at a given rate, on the premise that it is being consumed at the same rate ) . This premise holds for CBR encoded watercourses and demands to be extended to VBR encoded informations. By utilizing the isochronal belongingss of the informations, the push theoretical account eliminates the traditional request-response theoretical account of informations flow, therefore extinguishing hold and continuing web bandwidth.

Several makers of high-end VoD waiters have developed a methodological analysis to expeditiously transport VBR informations over CBR channels and are presently utilizing this method. Thus, I believe that the push government can suit both CBR and VBR traffic. In add-on, I have observed that the push government is consistent with the two cardinal constituents of the Integrated Services Model for Internet: multicast and Quality of Service ( QoS ) support via the Reservation Protocol. For multicast, the push government is evidently the right solution. For the Reservation Protocol, even though the client issues reserve petitions, the traffic forms must be provided by the transmitter. This is compatible merely with the push government of informations conveyance.

It is of import to observe that the push government does non prevent interactivity and random entree capableness. It is still possible to hesitate and randomly entree the picture watercourse. It is possible besides to widen this capableness to multicasted Sessionss.

Bibliography

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

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

2. Changeless 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 farinaceous conveyance and buffer demands for VBR encoded media in VoD waiters, by M. DelRosario, M. Podgorny, and Geoffrey C. Fox, March 1996

4. NPAC Technical Report SCCS-733, March 1996

5. hypertext transfer protocol: //www.pricewatch.com

6. hypertext transfer protocol: //www.videoserver.com/html/products_applications/products_applications.html

7. W. Tetzlaff, M. Kienzle, and D. Sitaram, & # 8220 ; A Methodology for Evaluating Storage Systems in Distributed and Hierarchical Video Servers, & # 8221 ; Proc. IEEE COMPCON, Feb. 1994.

8.W. Tetzlaff, M. Kienzle, and D. Sitaram, & # 8220 ; Using a Storage Hierarchy in Movie-on-Demand Servers, & # 8221 ; submitted to ACM Multimedia, 1994.

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