An Efficient Implementation of Interactive Video-on-Demand Steven Carter and Darrell Long University of California, Santa Cruz Jehan-François Pâris University of Houston

Why Video-on-Demand? Increased customer convenience Few people enjoy returning video tapes Even fewer people enjoy paying late fees Improved selection of videos Current pay-per-view provides only a small selection of popular videos Savings in time and resources It takes time and fuel to drive to the video rental store

Why Now? Technology becoming available Processors are inexpensive Storage is nearly free ($200 for 40GB) Fast networking is seeing wide deployment Consider the success of Tivo Records live television using MPEG to disk Provides interactive access to recorded programs

Why Interactive? It’s hard! It’s more expensive! … but it’s what people expect They won’t give up functionality they have come to expect They’d like to pause to make microwave popcorn They’d like to rewind to see the play again They’d like to be able to fast forward past the boring parts

Related Research Conventional video-on-demand (VoD) Requires one stream per client Patching An independently developed version of stream tapping Batching Group the requests of several clients together Various near video-on-demand (NVoD) schemes

Key Observation For videos of non-trivial length, several clients will be viewing portions of that video One client watching a 120 minute video and a second client begins watching the same video 10 minutes later The server needs only send data for the non-overlapping portion The potential for savings is enormous

Assumptions A set-top-box with: A fast network connection A few gigabytes of local storage A modest processor Keep in mind that set top boxes with these features already exist

Our Solution Stream Tapping uses multicast to tap in existing video streams Server load is the primary difficult in making VOD a reality Stream Tapping reduces server load by allowing clients to tap into video streams created for other clients Cost per client is dramatically reduced Client waiting time is also reduced

Stream Types A B C 0  22 33 44 Stream Time (since start of complete stream A) bb cc cc  bb Full tap Complete stream Partial tap

Complete Streams Start at a particular position in a video and transmit the remainder of the video For non-interactive Stream Tapping, the starting position is the beginning of the video Used primarily by the first client in a group to view the video

Stream Types A B C 0  22 33 44 Stream Time (since start of complete stream A) bb cc cc  bb Full tap Complete stream Partial tap

Full Tap Streams Can be used if the delay (  ) is less than the buffer size (  ) The full tap stream transmits the video from time 0 to  The complete stream is tapped and written to the buffer while the full tap stream is played

Stream Types A B C 0  22 33 44 Stream Time (since start of complete stream A) bb cc cc  bb Full tap Complete stream Partial tap

Partial Tap Streams Can be used when a complete stream is available but    Note that given current technology,  will be very large The client will tap the complete stream for  units while simultaneously viewing the first  from a partial tap stream Subsequently, partial tap streams of length    are used for the client to catch up to the complete stream

Stream Types A B C 0  22 33 44 Stream Time (since start of complete stream A) bb cc cc  bb Full tap Complete stream Partial tap

Tapping Options Extra Tapping Allows the client to tap data from any active video stream active, not just the complete stream of the video group Decreases server load by decreasing the length of full tap streams Stream Stacking If the server has streams available, the client can combine them to receive data at rate higher than the nominal rate Allows the server to service stream more quickly, which allows new streams to be scheduled

Interactive Stream Tapping When an interaction begins, Stream Tapping deallocates resources associated with a client If the client was the only one using a stream, then the stream is terminated Stream Tapping determines the resources needed for an interaction, and allocates an interaction stream Note: for rewind, the client’s buffer can be used When the interaction is complete, the client is merged into a video group (tapping existing streams if available)

Contingency Streams These are streams that are held in reserve for interaction The pool of these streams can be managed using high and low watermarks for hysteresis Having such a reserve of streams is essential to avoid blocking

Simulation Model Stream Tapping is too complex to model analytically, so we used discrete event simulation The length of the videos was derived from empirical data and a gaussian with mean 102 minutes provided the best fit The popularity of videos was modeled using a Zipf-like distribution, which is the distribution used in most VoD studies

Comparison with Conventional Systems

Contingency Streams versus Start-up Latency

Contingency Streams versus Resume Latency

Contingency Streams versus Blocking Probability

Effect of Client Buffer Size

Effect of Tapping Options

Conclusions Stream Tapping has been shown to work well in the interactive environment We have shown that VCR-like controls are possible Previous work has ignored them or only provided course-grained control The use of storage in the STB is an enabling technology

Video Length Distribution