Delivery of compressed videos from video servers employing cycle-based data-block retrieval discipline

The significant frame size variability exhibited in the compressed videos imposes a great challenge on network delivery. In this paper we propose an efficient flow control scheme, employed in the peer stations (i.e., servers and clients), for delivery of prestored compressed videos in a video-on-demand (VOD) system. This scheme resorts to an off-line analysis on the video frame sizes and server properties for figuring out the necessary buffer space and network bandwidth. The server platform of particular interest obeys a cycle-based data-block retrieval discipline, which is an essential technique to reduce the disk seek time for leveraging the disk throughput for supporting a large number of concurrent video accesses. Such a discipline is taken into account here to guarantee smooth delivery of variable-bit-rate videos. In run-time a server-driven control model is in use, where a server performs the primary flow control task, without relying on any feedback from clients. The scheme has been implemented in our prototype VOD system to support both unicast- and multicast communication paradigms under an RSVP-enabled network.

I. Introduction

Continuous progress in video compression techniques in recent years, has significantly reduced the size of video data Fig. 1. Subsystems and their data processing style along a data path in a videoon-demand system. into a range that can be practically delivered over networks in moderate bit-rate data streams for real-time playback (e.g., around 1.5 Mbps for MPEG1-compressed videos). The compressed video frames usually exhibit significant size variability in order to preserve a constant picture quality. This property unfortunately imposes a great challenge on the resource management. In this paper, we particularly focus on a typical video-on-demand (VOD) system where video streams basically flow through three subsystems, namely, the server subsystem, the network subsystem and the client subsystem (Fig. 1). Because subsystems process data in different styles, subject to their own device properties, two buffers—the server buffer, deployed at the interface between the server- and network subsystems, and the client buffer, deployed at the interface between the network- and client subsystems- are usually featured for smoothing out the discrepancies. Suppose we take the instance that the server subsystem places the first data block of a video in the server buffer, as the reference time 0. The total amount of data processed by a subsystem up to time can be described as an accumulative function (or a plan), denoted by and for the server, network and client subsystems respectively. The aim would be to coordinate the three plans in terms of minimizing the resource requirements, such as server- and client buffers, and network bandwidth.