I. Problem

Currently available record and play tools are difficult to use and require a large amount of local disk space. A playback server is needed to provide scalable, highly available and intuitive media-on-demand playback capability. In this project, we propose to design, implement and evaluate a playback server and client.

II. Analysis

There are several problems which need to be solved for playback of stored sessions to be an integral part of the CSCW toolkit. First, a variety of media types must be supported. The MASH media recorder and player provide this functionality, along with an extensible software architecture that makes it easier to add new data types. Second, starting and controlling a playback session must be simple (only a few steps) and intuitive. Some existing archives, including the UCB Multimedia Archive and the Internet Multimedia Jukebox provide intuitive web access, although the IMJ does not allow requestors to control sessions once they've been started. Third, the archive design must be scalable and highly available so that it can economically support a large number of users. Finally, there should be a way to navigate through sessions. Using a simple slider to navigate through a 2 hour session is frustrating and can cause discourage users.

III. Design

The figure below shows the proposed architecture for the playback system.

IV. Implementation

Server
The server will be implemented using the Service Construction Kit upon which TranSend is built. This will allow us to easily leverage cluster computing technology for increased performance and availability. In the context of this project we will also be gaining experience with, and evaluating the propsed RTSP (RTSP). RTSP is an Internet Draft protocol for "controlled, on-demand delivery of real-time data". RTSP provides a standard set of requests such as PAUSE and SEEK that the server stub can translate for the given media stream. All commands refer to a logical time system and are format independent. Including an implementation of this protocol in the MASH shell will enable an additional class of multimedia applications to be implemented using the toolkit. We are still evaluating possibilities for the user's view of the server. A possible solution is to publish the directory of available sessions on a WWW page. The eventual goal for the system, is to provide database search access through the available sessions.

Client
For reliable media streams such as MediaBoard data, the client provides a graphical view of the database from the locally cached data name space. The user is provided with a navigational interface to seek to any portion of the stream. From the logical time of the new location in the MediaBoard stream, the player also requests RTP packets for the corresponding video and audio streams.

The client will be implemented as a browser plugin to allow the playback system to be interfaced to the WWW.

The participants in this evaluation will be the class of CS294-7. The performance metrics we will use are:

• Requests per user per day

This will indicate whether server access and mediaboard navigation cause playback to be more convenient, and therefore, more often used.
• Amount of seeking within a stream

This will indicate whether the additional mediaboard navigation functionality encourages seeking through the stream.
• Locality of reference among different users.

How often will stream coalescing be useful?

Although our user population may be too small to show this effect, we will start gathering these statistics.

We will try to separate the effects of the additional navigation from the effects of server access by deploying them separately. We hope to have initial server access available several weeks before the mediaboard navigation functionality is ready for use.

One of the advantages of our non-intrusive style of evaluation is that we can continue it for many weeks with low overhead to ourselves and the users.

VI. Grading Contract

Design client and server : B
Implement client and server : A-
Evaluate playback system : A+