Prototyping the Interactive Multimedia Jukebox (IMJ): A Scalable, Internet-Based Video Delivery Service Kevin C. Almeroth (kevin@cc.gatech.edu) Mostafa H. Ammar (ammar@cc.gatech.edu) Broadband Telecommunications Center College of Computing Georgia Institute of Technology Atlanta, Georgia 30332-0280 {kevin, ammar}@cc.gatech.edu (404)894-3292 (404)894-0272 (fax) December 31, 1996 1 Introduction Straightforward, one-way delivery of video programming through television sets has existed for many decades. In the 1980s, new services like Video-on-Demand (VoD) were touted as the new revolution in TV services. However, VoD has not achieved the success initially predicted. Even though it is technically feasible, service providers have been hesitant to make the investment necessary for wide-scale deployment. Furthermore, almost all of the trials to date suggest VoD is too expensive and there is too little demand. What is needed, and what we propose, is a new paradigm offering flexibility in how programs are requested and scheduled for playout, ranging from complete user control, (like VoD) to complete service provider control (like traditional broadcast or cable TV). 2 Jukebox Paradigm The jukebox paradigm offers a compromise between two types of program scheduling. At one end of the scheduling spectrum, a set of broadcast TV channels each carry a pre-set schedule of programs. At the other end of the spectrum, VoD programs are transmitted to individual users only when the user makes a request. Broadcast TV offers choice only through the variety of available channels. In a VoD system, users control what they receive, but the size of such a system grows proportionally to the number of users. The goal of the jukebox paradigm is to offer some amount of user choice while eliminating the near-linear relationship between system size and user population. The jukebox paradigm is based on three properties: 1. The jukebox provides a set of channels which are multicast to all users watching each channel. 2. Users' program requests are scheduled on one of the jukebox's channels using criteria ranging from simple to complex. One possibility is to schedule a request on the channel with the shortest wait time. 3. A schedule of currently playing and scheduled programs is available to all users and any scheduled program can be watched by any user. The jukebox architecture has three components. The scheduler receives user requests, builds and maintains a schedule, manages video server operation. The second component is the video server. The third is the set of receivers including their playout facilities and scheduler interface. 3 Prototype Our prototype, called the Interactive Multimedia Jukebox (IMJ), is implemented using a combination of existing software, the World Wide Web (WWW), the Internet Multicast Backbone (MBone), and some custom C code. The WWW provides our scheduling interface, both receiving requests and updating a WWW page containing the schedule. The main IMJ home page is located at http://imj.gatech.edu/. The MBone and its associated audio and video tools provide delivery over the Internet. The IMJ also delivers one channel of programming into the Georgia Tech Cable Network by converting the audio/video stream to NTSC and injecting it into the cable network. Currently the IMJ supports three "channels" of 128Kbps H.261 video and 39Kbps Intel DVI encoded audio. To avoid copyright infringement and network overload, two of the three channels are limited to the Georgia Tech campus. These two channels carry content owned by the Turner Broadcasting Company. However, we have just received preliminary approval to transmit some Turner cartoons outside of Georgia Tech. The IMJ video server currently provides only very basic functionality. Programs are accessed using NFS. The storage format and loading functions are provided through the RTP Tools suite developed by Henning Schulzrinne. 4 Current and Future Developments o Provide interactivity to give users more individual control. o Track usage by monitoring WWW page access, program requests, and channel viewership. o Build a server capable of supporting more channels and of a higher quality. o Allow the tailoring of rules to control how user requests are scheduled. o Support the delivery of multiple streams per channel providing varying quality to users in different service groups.