A quick prototype for dc was implemented by Wu in the Fall, 1998. It provided a remote control interface to the AMX control system so the Berkeley MIG Seminar broadcast engineer could control which video source was routed to the capture machines. The need for a new dc that supported multiple streams, interfaces to more services, and dynamic extensibility was immediately obvious. The design and implementation of the current version of dc was completed during the Spring and Summer of 1999. This version was used to produce the seminar webcasts beginning in the Fall, 1999 semester. Although the system has performed well beyond initial expectations, it can still be improved. This section discusses several changes and improvements.
A webcast becomes more and more difficult to manage as the number of services increases. The special-effects service alone can double the number of input streams and interface controls. Our goal is to have one person produce several webcasts simultaneously. Consequently, the need for automation is apparent. Automation eliminates the need for the director to perform mundane manual tasks. One particularly time consuming chore is camera tracking. As the speaker moves about the stage, the camera must be moved to ensure he or she is correctly framed. Automatic camera tracking is a well-known technique for solving this problem that should be incorporated into the webcasting system [7].
A second example is stream switching. Take the case of a webcast composed of speaker and content streams. If an audience member asks a question, the content stream should be switched to the audience camera and the camera should be moved to show the person asking the question. The fact a question has been asked is known because the audio mixer detects that the input from an audience microphone is above a threshold. Our studio classroom has three audience microphones mounted in the ceiling on the left, center, and right sides of the room. The mixer adds the output of the speaker microphone to the room audio and routes it to the webcast audio stream. Consequently, the mixer can identify the side of the room from which the question comes. We need a mechanism for the mixer to signal the webcast control system that an audience question from a specific area of the room has occurred. An intelligent control system that implements a policy specified by the director can automatically execute the commands to switch to the audience camera and position the camera to the appropriate area in the room. In addition, the bandwidth allocation between the speaker and content stream can be changed to reflect this new configuration. Low-bandwidth transmissions allocate more bandwidth to the speaker because slides are often static relative to the speaker. However, bandwidth should be diverted from the speaker to the content stream when switching from slides to the audience. Lastly, automation can be used to log events, such as stream switching, to assist video query, summarization, and automated authoring of multimedia titles derived from a lecture [15].
Automation relies on two mechanisms: 1) the ability to monitor events produced by other processes in the webcast and 2) the ability to invoke commands in lieu of the director. The bandwidth-allocation agent, for example, monitors switching events and responds with commands to the transcoder to either increase or reduce bit-rates. The current dc architecture cannot support such agents because it uses unicast communication channels to services. Thus, communication, both events and commands, between clients and services cannot be monitored or forwarded to other participants. However, using multicast for the communication channel will remove this limitation. An appropriate logical decomposition of the events can be created using SNAP containers so automation agents can monitor only the events in which they are interested. The bandwidth-adjusting agent can wait for an event like ``Switch Content Stream to Audience Camera" and respond with commands to reduce speaker bandwidth and increase content bandwidth.
A second area in which dc can be improved is security. We ignored many security issues during the development of dc because we used rapid prototyping to the system. In retrospect, we note many security weaknesses that will need to be addressed. First, the SDS service allows any process to present itself as a service. It also gives any process information about all existing services. Rather than duplicating effort, we plan to replace the prototype SDS service with the Ninja SDS System that is better designed for security [6]. A second security issue arises because Tcl/Tk code is transferred from services and evaluated in the client without checks. Thus, a malicious service can kill a client application by simply sending an exit command. Moreover, the Tcl/Tk code segment is difficult to write correctly. So, even a trusted service might cause harm through carelessness. One approach to solve these problems is to implement a certificate system that ensures the correctness and trust of the code. Another approach is to create a description language for user-interfaces similar to the document language proposed by Hodes and Katz [9]. Rather than sending code, services transfer a description of the user-interface. By restricting the description language, clients can limit the access to services and thereby protect themselves. A third approach is to sandbox the code as is done in Janus [8]. The code runs in a confined area with limited access to resources (e.g., socket communications can be limited to the parent service or file writes can be prohibited).
A third area in which dc can be improved is in audio control. Audio has been largely neglected by the current dc prototype. However, many of the design principles used for video also apply to audio. Audio devices can be viewed as a service that can be switched in conjunction with or independently from video. Audio effects can be applied just as in video. However, the biggest problem we must solve is to provide seamless interaction with remote participants. Solving this problem will require changes in the studio classroom to provide visual feedback or information about remote participants (i.e., to provide a sense of presence [4]) and an audio control system that can handle echo cancellation with long delays resulting from Internet communication.
A fourth area in which dc can be improved is controlling commercial webcast transmissions. We began simulcasting the Berkeley MIG Seminar using Real Networks because the unicast transport used in commercial systems is easier to deploy than the multicast transport used in the Mbone. Integrating these technologies into dc will enable a wider webcast audience. In addition, viewers will benefit from the flexibility and versatility of dc. For example, the Synchronized Multimedia Interaction Language (SMIL) developed by the World Wide Web Consortium can be used to view webcasts with multiple streams like those produced by dc [22].
A fifth area in which webcasts produced by dc can be improved is interactivity. Many webcasts follow the television model of broadcasting in which there is no audience interaction. The Internet, however, is capable of audience participation. Nowhere is this capability more important than in distance learning where the student's ability to ask questions during a lecture is critical. Many mechanisms for student participation exist (e.g. chat sessions, video conferencing, and interactive response systems), but more research is needed to determine the most appropriate models for integration with live webcasts. Moreover, moderation techniques will need to be developed to handle non-trivial numbers of participants. For example, if 200 people want to ask a question simultaneously, who gets control and how is the interaction moderated?
Lastly, our experience suggests that future studio classrooms should use equipment directly connected to the Internet. Rather than connecting cameras and microphones to matrix switches and mixers and using a control system like the AMX, a better solution will connect the devices directly to the network. Switching and control are easier to implement. And, production control will be better if all devices are available at any time rather than just a subset of devices through a matrix switch.