What workedEdit

We used Wowza Media Server running on Amazon EC2 as our streaming media server. This was very easy to deploy with one of Wowza's AMIs and pre-configured startup package, which required minimal modification.

We used Ubuntu's Remote Desktop Sharing (VNC) application to allow the director to control the camera laptops. This allowed the director to start/restart the DV stream when needed.

What didn't workEdit

We couldn't get the director's talkback to work, probably due to an issue with the laptop sound mixer. It might be worth using a USB adapter specifically designed for VOIP to reduce the potential for such problems. As a result the camera operators worked largely autonomously, with occasional directions over text chat.

Programme sound was initially very distorted due to an incorrect setting on one of the cameras. It took us a while to spot this because we didn't have audio monitoring set up properly.

There was no time to produce astons on the day.

We had sound routed through one camera, which mostly worked, except that on a couple of occasions we lost the signal from the camera due to a battery change or the CAT5 cable being nudged resulting in loss of connection. The second camera was sending audio at a different sample rate to the first, so it was not possible to switch to that camera's sound as a fallback when we lost the signal from the first camera.

We arrived at the venue two hours before the scheduled start time. This was barely enough time to get everything set up, and was not enough time to test everything properly and finesse the camera settings.

The director was too slow in pressing the record button to catch the start of one of the sessions.

The switching laptop was painful to use because of the combination of a small monitor (1024x768) and the transcoding overhead. Switching windows took a long time. It would be worth doing the h264 transcoding on a separate laptop, and considering a lighter Linux distribution, to address this problem.