Figure 2 presents an overview schematic diagram of some of the key elements in the Wytch Farm webcast and their network relationships. The figure is a Flash movie - so you can roll over areas for more detail, and you can zoom in by Command or Right Clicking.
The AV was captured in Wytch Farm by a small outside broadcast team from the Open University.
The setup included 3 cameras and 3 microphones. The audio feeds were mixed and balanced via an audio mixing desk, and the video feeds were simply switched. One camera was a simple and inexpensive webcam; one was a domestic quality Hi8; and one was a broadcast tv quality camera. The latter was used as the main video source with the others providing alternate shots for variety. The webcam, for example was directed out into the stores area of the shed and was used before and after the presentation to give a live context to the interface (and on occasion showing a forklift moving around beside the presentation area)!
The AV feed was encoded locally on a Dual Pentium II (300Mz) via the Real Networksª v5 encoder using their own streaming codecs. We aimed for a 34Kbps bitrate to fit reliably within a 56K baud pipe (made up from 8K audio, 26K video). This single 34K stream was sent over the BP Amoco intranet to an AV server in Sunbury, near London England.
There were three AV servers deployed for this event, all of which were Pentium II (400Mz) NT servers running the RealNetworksª v5 server (licenced for a maximum of 300 simultaneous users). The principle server in Sunbury received the encoded stream which it made available to all local networked users as a unicast (ie. Each user taking an individual 34K stream from the server). In addition the Sunbury server had been pre-configured to "split" its services to two further servers: one in Aberdeen Scotland, the other in Houston Texas. Both of these split servers was configured to be identical to the Sunbury machine, taking a single 34Kbps which was made available to local clients. The split architecture was required to avoid the risk of network traffic bottlenecks between the various segments of the BP Amoco intranet. On the day this architecture proved to be unproblematic, with one major exception! The machine deployed in Houston performed unresponsively during the morning rehearsals and so was excluded from the services offered live. Instead, the relatively small number of users in the Americas were seamlessly switched to the Sunbury server for the live event. Whilst this increased the risk of poor performance to those clients, in reality the BP Amoco transatlantic link was quite adequate to this traffic. The
In tandem with the AV services, the KMi Stadium architecture uses a range of management servers to direct non-AV event information to clients. In this webcast, the main sources of this information are about slides and chat. The slide information relates to the "state" of the presentation (eg. Which slide the speaker wants the audience to see); whilst the chat information relates to any text comments that are being made by participants. The "state" of chat and slides were captured on processor clients which were running locally in Wytch Farm on a dedicated Pentium II (400Mz). The management servers themselves were co-located with the AV sevices on each event server. In this event we used Macromedia Shockwave 7 Multiuser servers (licenced for 500 clients), which were configured to be dumb - simply taking instructions from the processor clients and forwarding these to all connected users. The data rate of management information was variable but very low, including, for example, a stay-alive ping from all connected users (to register their continuing interest in the event)! The biggest problem faced by event management is a function of its independence from the AV. The AV server technology we used in this event can introduce a substantial lag between encoding and decoding - a lag which is different in each case. In some cases the participant client is seeing and hearing something some 20 seconds after the presenter said it! Given that this is a broadcast technology - designed to be primarily 1 way - this lag is not evident to the audience. However, the event technology can be nearly synchronous - meaning that it is essential to introduce an artificial delay before any events are acted upon in the remote client. In this software the events are stacked and individually delayed in each local client to match the AV delay. On the day, local synchronization was fairly good and stable - when the presenter said something, it happened for each remote client at about the right time! One feature of this service which is has been omitted from figure 2 (for simplicity) is that none of the MM multi user servers had any special status (cf the Sunbury AV server). Instead the control architecture mandates the processor clients on the event manager machine to keep each of the remote 'split' servers in synch with each other, independently and directly.
The base client used in the webcast was Microsoft Internet Explorer 3.01 (the standard browser of the BP Amoco Common Operating Environment). The browser required a small range of plug-in software to be added, including: Macromedia Shockwave 7; Quicktime 3; and Real Networks G2. This software was included in a BP Amoco automatic COE update, via the SMS software management system. All users who registered on the webcast web pages prior to the event received SMS packages which automatically installed the appropriate software. For those who did not wish to do so, some of the software was also set to auto-install on demand via the web page. The presentation client was set to automatically cache the slides used in the presentation, when the user first opened the relevant page. The Macromedia Shockwave Cache was used, to avoid the risk of the browser flushing its own cache before the presentation. For users on a slow bandwidth connection, the larger presentation assets (primarily the Quicktime movies) were set to stream to the user - so that they would be in the cache before being required but did not prevent the user starting the presentation. All these non-live assets, including movies and all the control software were bundled into a cache of less than one megabyte. The live audio and video feeds were streamed to the user on demand - requiring an open connection with a stable data rate, but little cache or disk.