An Ef fi cient Implementation of Interactive Video-on-Demand

1. 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

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

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

10. 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

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

12. 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

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

14. 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

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

16. 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

17. 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)

18. 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

19. 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

20. Comparison with Conventional Systems

21. Contingency Streams versus Start-up Latency

22. Contingency Streams versus Resume Latency

23. Contingency Streams versus Blocking Probability

24. Effect of Client Buffer Size

25. Effect of Tapping Options

26. 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

27. Video Length Distribution