Introduction

The development of IP Multicast, the Mbone Tools [11], and commercial streaming media systems (e.g., Apple QuickTime Streaming, Cisco IP/TV, Microsoft Windows Media, and Real Networks) has lead to a rapid growth in the use of streaming media on the Internet. Several hundred live webcasts are produced each week that are being viewed by tens of thousands of viewers [20]. Webcasts are becoming an alternative to traditional television broadcasts.

The television industry has developed many techniques to produce high quality video programs that can be used to improve webcasts. One technique is to switch between different video sources. In a typical television news production, several video feeds are sent to a central studio. The director selects the stream that best portrays the content and broadcasts that stream to the audience. News broadcasts, for example, introduce a subject at the anchor desk and cut to different sources as needed to present the story (e.g., recorded material, a live-remote report, etc.). Another television technique uses video effects to combine several video sources into one stream (e.g., composition effects), to place text on an image to describe who or what is being displayed (e.g. titling effects), and to transition between streams (e.g., fade effects). An interview show, for example, might display an interviewer in one window and a remote person who is being interviewed in a second window composited side-by-side with titles to identify the program, the participants, or the location of the remote source.

Webcast producers are reluctant to integrate conventional broadcast television techniques into webcasts for several reasons. First, television production equipment is very expensive. Second, the technologies and models used in broadcast television typically require many people to operate the system. Third, most broadcast television programs produce a fixed data rate, single video stream with no interaction. Fourth, webcasting has a fundamentally different production model than television broadcasting and the tools and interfaces used to produce high quality webcasts must reflect the underlying infrastructure.

We have produced the ``Berkeley Multimedia, Interfaces and Graphics (MIG) Seminar" webcast on the Internet Mbone since 1995. The seminar features invited lecturers who give formal presentations. The seminar takes place in a room equipped with a variety of audio/visual hardware, which is used to produce the webcast. We have used the Berkeley MIG Seminar webcast as a practical experiment to explore the problems associated with webcast production.

Our webcast is comprised of two video streams and one audio stream. One video stream focuses on the speaker, called the speaker stream, and a second stream focuses on the presentation material, called the content stream. Figure 1 shows a sample webcast from the remote viewer's perspective. The director can switch any of several video sources into either stream. For example, when a member of the local audience asks a question, the content stream can be switched to a view of the audience so that a remote viewer can follow the conversation. Or, if a remote person asks a question, the content stream can be switched to the remote viewer and the projector in the classroom can be switched from the presentation material to the remote person. These examples illustrate the complexity of the webcast control problem. The director must control the production viewed by the students in the classroom and, at the same time, he must control the production viewed by a remote participant.

  

Figure: An example MIG Seminar webcast. The left panel shows a thumbnail for each stream in the session. The right panel displays selected streams with greater resolution and frame rate.

The MIG Seminar originates from a classroom with many audio/video sources, computer systems, and software processes as shown in figure 2. The classroom is equipped with several cameras (e.g., speaker and audience cameras), a VCR, and a document camera. These devices are connected to a conventional video matrix switch. Two capture machines take video from any connected input device. Moreover, they can receive the same input simultaneously. The capture machines digitize the audio and video signals for transmission into two multicast sessions (i.e., one for video and one for audio), which we call the studio session.

  

Figure: Infrastructure used to produce the MIG Seminar webcasts.

The studio session is analogous to the routing switcher and control room in a conventional television studio. As in television, webcast production sends all sources to one location, the studio session. The producer/director previews all sources and selects a subset of the streams that define the webcast. The selected streams are sent to the broadcast session. Thus, for a viewer to see the slides and the speaker, the producer sets the matrix switch to the correct configuration and broadcasts the two capture machine streams. Video special-effects can be added to the webcast by placing an effects processor on the edge of the studio session. It takes one or more streams from the studio session, renders the effect, and sends the new stream back into the studio session. Stored playback material (e.g., a predefined opening segment) and remote participant video are other examples of sources available in the studio session.

Production of a high quality webcast is a complex operation. In a previous paper, a Broadcast Manager application was described that automated the tasks required to initiate a webcast [23]. For example, the MIG Seminar webcast requires that more then ten processes be started on different hosts with appropriate arguments (e.g., multicast addresses and port numbers, media formats, bit-rates, and quality settings).

The Director's Console (dc), described in this paper, is designed to control a webcast during live production. It controls the webcast sources, adds effects to these streams, and determines the final output. Dc is implemented as a system of distributed processes organized with a service model, which adapts to different physical infrastructure and to different broadcast configurations.

The remainder of this paper presents the design and implementation of dc. Section 2 describes the webcast production model. Section 3 describes the system architecture. Next, the user interface is described in Section 4. Section 5 describes the implementation. Section 6 discusses our experiences developing and using the tool and suggests future work. Section 7 describes related research. And lastly, section 8 concludes the paper.