You are on page 1of 7

Video-on-demand: Technology, Architecture and Cost

Digital Content Management Group Interactive Media Section e-Services Programme


CONTACT: LUISA CONTE Phone: (03) 9253 6282 Author: Santosh Kulkarni

This report aspires to comply with IS&W Behaviors #12, 1, 2 and 3: We Speak and Write Concisely We Understand Our Partners' Business We Create and Deliver Alternatives and Solutions We Work Side-By-Side with our Partners and Keep them Informed

Telstra R&D Management Pty Limited 1998. All rights reserved. Use of this publication is permitted by Telstra R&D Management only on the condition that: 1. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording or otherwise; 2. No part of this publication may be used for any commercial purpose; and 3. No part of this publication may be given to any entity other than the entity to which Telstra R&D Management Pty Limited has directly provided this publication without the prior written permission of Telstra R&D Management Pty Limited. Version 1 2 Publication Date August 21, 2000 September 29, 2000 Print Date 4/5/2013 1:09:00 AM Comments Draft Draft

1 Introduction
This document deals with the various issues related to video-on-demand which are relevant to Telstra. The primary focus is on reducing the cost of providing efficient video-on-demand services. Various models and techniques which would help Telstra in reducing the cost of delivering the service are discussed, analyzed and proposed. The report is organized as follows. The rest of this section gives and overview of video-on-demand technology and the services offered by this technology. The next section lists the different components involved in a video-on-demand system. Video on demand is a technology that provides entertainment on demand to all the subscribers of the service. Video on demand provides customers with informative and entertaining streams of multimedia and video information. Some of the services that can be offered by video on demand technology are: Movies-on-demand: Movies, TV shows, special interest programs and music videos can be watched by home users at their convenience.

E-commerce: Customers can shop from home for some of their favourite items such as books and software from various web sites. Interactive advertising: Customers can interact directly with full motion video advertisements and order the product on-line while they watch the advertisement.

There are two distinct types of video on demand applications, each requiring different technology. 1. 1. Near-Video-on-demand: This technology delivers the same content using multiple video streams with staggered start times. For example, twelve video streams each starting at ten minute intervals can deliver a single, two-hour video. Users wishing to watch the video may have to wait. The waiting time is no longer than ten minutes. In this technology many users share a single video stream. 2. True-Video-on-demand: This technology provides the users with the requested content immediately. In response to a user request, the video server delivers the content in a video stream immediately, without any waiting time. Generally video streams are dedicated to users unless multiple users request a single content title at exactly the same time. Using this technology, it is possible to provide interactive control of the video stream to the users. For example, users can be provided with VCR controls such as play, fast forward, rewind, pause. True video-on-demand will be the focus of this report.

2.

2 Components Required in a Video-On-Demand System


A detailed explanation of the important components is listed in this section. The components which are important from Telstras point of view have been analysed and the different techniques that can be used to improve the performance of the system are discussed. 2.1 Video server Video server plays a major role in video on demand systems and is a critical component of the system. A video server has access to the video content and is responsible for the delivery of the video content in continuous streams that are free of unacceptable video artifacts. A video server therefore has to store and manage large and complex video files. The important features of a video server are listed below: Video server capacity: This is the number of video streams to be delivered simultaneously. The type of the video stream supported by the video server is also important. An MPEG-2 encoded video at 6Mbps requires more video server capacity than a video that is encoded with MPEG-1 at 1.5Mbps. Ideally a video server should be independent of the video streams (eg. MPEG1, 2, 4, RealVideo). This allows the content to be stored and delivered in the most cost-effective manner. Input/Output performance: Input/output performance is an important video server feature to consider. Normal file systems are optimized for short and random data access rather than large sequential access. Video files can be stored as large contiguous files for sequential access or as small clusters for random access. Which is a better approach depends on the network configuration and is discussed in section 4.2. Optimized access to large video files is also a desirable property of video servers. The input/output process can be buffered (the data to be read is transferred to a disk buffer and then transferred to the user memory in smaller chunks) or direct (data is transferred from the disk directly to the user memory). The direct I/O method is a better approach because for large video files, the buffered approach slows the data throughput.

Dynamic content management: The number of streams that can be supported by a single video file is limited by the data throughput characteristics of the content storage device. If a particular video title needs more streams than the device can support, multiple copies of the video file are needed. One way to achieve this is to store multiple copies of the most popular video titles. This is not a very cost effective approach. A much better approach is to have a video server which supports dynamic content management. If a particular video title requires more streams, the video server duplicates the video file. When the demand for the video title drops, the extra copies are deleted. Data storage: If only disk-based secondary storage systems are used to store and manage the huge amount of video data the system cost would be extensively high. A tape-based tertiary storage system seems to be a reasonable solution to lowering the cost of storage and management of this data. This approach introduces several issues to be

considered. The important issues are the replacement policy on disks, the decomposition and the placement of continuous data chunks on tapes and the scheduling of multiple requests for materializing objects from tapes to disks. Replacement policy is concerned with freeing space on disks for materializing a video object that has been requested and is partially or fully not residing on the disk. Several policies have been proposed and implemented which support single stream environment and multiple stream environment. A policy which is cost effective and provides a good response time should be considered when designing the VOD server. If a video object is distributed on multiple tapes, it reduces the transfer time as data is transferred simultaneously from the different tapes at the same time. This strategy increases the time spent on exchanging tapes and also seeking the location on the tapes. Therefore there is a tradeoff between seek time and transfer time. The video object should be distributed in such a manner that the total time (seek + transfer) is reduced. Fault tolerance: Failure of the storage system is a major concern. If the storage system fails, content cannot be accessed and delivered causing disruption in the services. The video server should have a mechanism to replicate the content so that if a certain section of the disk fails, content can be transferred from an alternate location. In the middle of transmission, if the entire video server fails, the VOD system should be able to transfer the connection to another server without the knowledge of the user. This is discussed in sec 4.2. Open and scalable architecture: The video server should be able to support a variety of network distribution options. The video server should be easily and economically upgraded to support the increase in content and number of users. 2.2 Back office software/hardware This component is required to do the following tasks: Keeping track of the content: where is it coming from, royalty issues, advertising services. Content management. User account management. Standard billing systems and customer management systems. There is software/hardware available in the market that can perform the above tasks. 2.3 Other components Digital set-top boxes, application server and the network configuration are the other components of a video-ondemand system. The next section discusses the network configuration which is the most important component of a video-on-demand system.

3 Network Configuration
It is very important to design the network configuration so as to minimize the cost of content delivery. There are two major costs associated with the delivery of content. The cost of video servers (non-recurring cost) and the cost of transferring the content (network bandwidth which is a recurring cost). The VOD system should be configured in such a way that the total cost is minimized. There are two major ways to implement the network architecture: centralised system architecture and networked system architecture. 3.1 Centralised system architecture In this model, there is one large central server which stores all the digital content. This server controls and manages all content storage and supports all video streams. Therefore if there are 1000 requests at a given time, the server should be able to transfer 1000 streams of video simultaneously. This also means that the network bandwidth required has to be very high in order to support 1000 streams. If we are sending MPEG-1 video encoded at 1.5Mbps, then in order to send 1000 video streams, a total bandwidth of 1.5Gbps is required. Also, as the number of subscribers increase, so will the number of streams needed, which will require additional channel bandwidth. This is a very expensive alternative given the costs involved in maintaining high speed networks and is therefore not a feasible option. Figure 1 shows the configuration for a centralized system architecture.

Content Storage

Video Server
High speed private network

Exchange1
ADSL 2Mbps

Exchange2

Exchange3

Customers

Figure 1. Centralized system architecture


3.2 Networked system architecture In a networked system architecture, multiple video servers are distributed throughout the network infrastructure. Each video server controls and manages a subset of the content storage and is responsible for a subset of the video streams. For example, a video server connected to a particular exchange will be responsible for all the video streams sent from that exchange. Figure 2 shows a typical layout for a networked system architecture. Ideally all the high demand content is replicated at the video servers connected to each exchange. This reduces a lot of traffic between these servers and therefore relaxes the bandwidth requirements between the major hubs. If a local server does not have a requested video title, it searches through a list of all the video servers which have that title and selects the one with the least network costs. Networked architecture is a feasible option as it relaxes the bandwidth requirements on the network but has to be combined with other bandwidth reduction techniques which are discussed in the next section.

Storage 1
ADSL 2Mbps

Video server

Exchange 3

Video server Storage 3

Network

Video server Storage 2

Exchange 1 Exchange 1 111

Figure2: Networked system architecture


4 Bandwidth Reduction Techniques
The key problem in deploying large-scale video on demand applications is economy rather than technology. In order to have an efficient and cost effective video-on-demand system it is important to reduce the bandwidth requirements as much as possible. This section explains some of the bandwidth reduction techniques and analyzes their suitability to video-on-demand services. 4.1 Multicasting A typical video-on-demand system uses dedicated channels to service each user request. This increases the bandwidth requirements as more and more streams are requested. Multicasting is an approach whereby various customers can share a single movie stream resulting in reduced system cost per customer and improved system scalability. Multicasting has some limitations associated with it. For example, in order to share a single channel with a group of customers, all the customers have to request the video at the same time and watch it without any interaction (no pause, fast forward, rewind, etc). This defeats the purpose of a true and interactive video-on-demand system. There are certain multicasting techniques which can be used to provide interactive video-on-demand services. Batching: In this approach, the requested video is intentionally delayed by some amount of time, called a batching interval, so that subsequent request for the same video arriving during the current batching interval may be serviced using a single I/O stream. This trades off reduced I/O stream requirements for increased latency. Therefore, large batching intervals would seem to be incompatible with the notion of a ture VOD system. Batching can only be used with popular videos since unpopular videos are unlikely to receive multiple requests during the (short) delay interval. Patching: In this approach, also called as a dynamic multicast, the multicasting stream is not static but can expand dynamically to accommodate new requests. For example, if there is a video being streamed through a local video server and there is a new request for the same video, then the video server starts caching the video data in its local disk. The server therefore needs an initial patching stream to transmit the leading portion of the video. When the leading portion of the video is transmitted, the rest of the video is transmitted from the data already buffered in the local disk. Using the patching technique, channels are used only briefly to broadcast the first few minutes of the video, instead of being held up for the entire duration of the playback. Patching can be seen as a multicasting technique for interactive video-on-demand systems where a single channel can be shared with multiple users. Patching also saves the storage costs as only a small amount of the video stream has to be buffered at the local disk ( depending on the requests). There are many variations to patching, which are more efficient. Transient patching is similar to patching but the patching stream is longer than used in the traditional patching scheme by a fixed time slice (t). This helps to reduce the length of any future video streams if there are any new requests in that time slice (t). Split and merge protocol divides the video stream into a service stream for regular playback and an interactive stream for user interaction (pause, fast forward, rewind, etc). If there are new requests for the same video title then patching is used for that time period. Patching is very effective in reducing the bandwidth and storage requirements if the number of interactive requests from the users is within a certain limit. Beyond that, patching looses its efficiency as it results in starting multiple patches of the same video and increases the bandwidth requirements. Piggybacking: This approach tries to alter the playback rates of the on-going video streams by 5% (an amount supposedly undetectable to human observers) in order to merge the respective video streams into a single stream which can then serve the entire group of requests. The idea is to display the leading stream at a slower rate, and the trailing stream at a faster rate. Then, assuming this interval is sufficiently small, the faster stream will eventually

catch up with the slower stream. At this point the streams can be piggybacked or merged. There are different piggybacking policies that can be used to achieve maximum savings in bandwidth. The three basic types of piggybacking policies are simple merging policy, the odd-even policy and the greedy policy. The first two are elementary as they involve at most a single change of speed for each video stream. Therefore they can achieve a maximum of 50% improvement in the number of streams saved, because they pair of subsequent streams. The greedy policy changes the speed of the different streams in such a way that the streams are merged at the earliest possible time in order to achieve maximum savings in bandwidth. There are some limitations associated with piggybacking. The first is that it takes a long time for two streams to merge. Therefore if the streams are very far apart, it is possible that they will never merge at all. The second drawback is that, unless the VOD server is powerful enough to make the video rate changes on the fly, it will have to store at least two versions of each video, doubling the storage requirements. The quality of service may also be affected when the playback rates are altered. Piggybacking assumes that the number of interactive requests is not very high. This is because, each interactive request causes the merged stream to start a new stream. This is therefore not a recommended option due to the level of interaction present in an interactive video-on-demand service. Volatile storage: In this approach, every single video title that is transferred to a video server is cached in the servers local disk completely. Apart from its local storage, each video server has a volatile storage where the video content is stored for a short period of time. This procedure enables any future requests to be served from the local server without any additional video streams required from the distant server (the only exception is when a future request is for a part of the video which is still not present in the local volatile storage). There are no restrictions in the number of interactive requests as all the requests are satisfied from the local video server. The only drawback with this approach is that it increases the storage cost as additional volatile storage is required at each video server connected to an exchange. Ideally, this approach can be combined with patching to achieve a hybrid solution which will be cost effective in terms of storage and bandwidth costs. The storage costs and network costs have to be compared and a topology has to be designed accordingly. 4.2 Server selection In a networked system configuration the server selection process is very important. When a local video server does not have the requested video title, a remote server which is the most cost effective has to be selected for transferring the video data. There are two methods of server selection: static and dynamic server selection. In static server selection, the process of selecting the server is done only once when a particular video is requested. Once the server is selected, the entire video is streamed from this server. Dynamic server selection is a process which constantly keeps looking for the best available server. If, after a certain video stream has been started from a server, a different server which is more cost effective is available, the connection is transferred to that video server. This process is transparent to the user. Dynamic server selection is a more efficient process as it tries to reduce the transfer costs as much as possible. Dynamic server selection also makes the video-on-demand system fault tolerant. For example, in the middle of a video transmission, if the video server fails, the connection can be transferred to the next best video server without any interruption to the user. In order to make the server selection process very efficient, the video server has to store the video data in an appropriate manner. For example, if a static server selection process is used then the video file can be stored as one large continuous file as this will expedite the data access which is sequential from a fixed server. In case of a dynamic server selection process, the video files can be divided into clusters and stored on the disk. This will enable faster access to any particular cluster when a connection is transferred to a different video server. 4.3 Video content distribution The method of distributing the content is also very important. Depending on the likes and dislikes of the users connected to a particular exchange, appropriate content should be stored at that local video server. This would depend on the borrowing habits of the customers. This process can be static or dynamic. In the static approach, the borrowing habits of all the users over a fixed period of time can be studied and the content can be distributed accordingly. This process can be repeated every 6/12 months (or a fixed period of time) and the content can be updated accordingly. In a dynamic model a resident program constantly monitors the borrowing habits of the users and accordingly transfers the content between the video servers dynamically. The dynamic content distribution

process has to be based on a smart algorithm which considers borrowing habits, locality information and many other factors.

5 Video-on-Demand Costs
The primary costs associated with a video-on-demand system are: 1. 1. Cabling costs: If a video-on-demand system is evolving from a networked system which is scalable, the cables are largely in place and would not be affected by the additional requirements of a video-on-demand system. Cabling costs would be dependent on the bandwidth requirements of the various parts of the network. 2. Network bandwidth costs: Although difficult to estimate, network bandwidth costs are a substantial component of the operating costs. The actual cost depends on the network topology and distances involved, but must attempt to minimise these costs by appropriate network design. Similar work has been done in our section in the Vista project. 3. Set-top-box costs: This is a fixed cost and doesn't affect the network architecture of a video-on-demand system. 4. Video server costs: A video server is a massive I/O device capable of producing multiple video streams from content stored at many sources. The cost of a video server depends on the number of streams produced and the amount of content (number of videos) stored in the server.

2.

3. 4.

From the above listed costs, the cabling and set-top-box costs are fixed whereas the network bandwidth and video server costs are variable and would depend on the network architecture. The network topology should be designed in such a way that the combined cost of the network bandwidth and the video servers (storage and number of independent streams) is minimised. The network topology would in turn depend on various other factors such as server selection strategy, bandwidth reduction techniques, content distribution strategy. Therefore all these factors have to be considered in order to design an efficient video-on-demand system.

6 Protecting the Video Content


If the video data is cached at the client end, it is possible that the data can be replicated and resold by some of the users. Some mechanism has to be devised to stop the replication process. For the wide-spread sale of a multimedia content, the use of caching is necessary because neither the network infrastructure nor any content providers servers can support an arbitrary number of unicast connections with content that is encrypted in real time. This conflict between copyright protection and scalability inhibits effectively the deployment of caching and pre-fetching of commercially sold video content. There are two main techniques used to stop resale and illegal copying of video data: digital watermarking and data encryption. Digital watermarking technology enables the possibility to add copyright or customer information into digital data, like video, to protect the content from resale by an original customer. Usually digital watermarks are additional hidden tags that are holographically inlaid in the multimedia data. This hidden information is perceptually undetectable. The information is embedded with a secret key and can be retrieved using the same secret key. This technique de-motivates the illegal re-use of distributed digital data. The video encryption approach uses encrypted point-to-point delivery to ensure that only paying users receive the service. To ensure that copyright violations can be proved, the delivered content is further watermarked with information about the content seller as well as the customer.

7 Future Directions
Telstra needs to develop a business model with feedback from projects like Vista which provide costing models for video-on-demand. The VOD trials being carried out in USA by companies like Concurrent (www.ccurr.com) and Intertainer (www.intertainer.com) should be studied. The R&D teams of these companies should be contacted and possible technologies for VOD should be discussed. After considering all the factors discussed in this report a network topology should be designed which reduces the overall cost of delivering video content to the customers.

You might also like