Introduction

Webcasting
  What is webcasting?
  Different from Video Conferencing?
  What are the drivers?
  Key market technologies

Key Elements
  Preparation
  Capture
  Delivery
  Reuse

ProLearn Live Trails
  ProLearn Summer School 2006

Summary

References

Articles
  Basic audio-visual equipment for webcasting
  Audio-Visual Webcasting Tips

Delivery of the webcast from the venue requires that the Audio-Visual feed be encoded into a streaming format that can be broadcast over the internet, normally to a streaming server, where it is distributed to webcast clients. The webcast clients need some way of requesting this stream from the server and publishing this information is most commonly done via a web page.

Encode

Encoding an audio-visual feed for webcasting involves digitizing the feed and then encoding it into a live stream of data. An uncompressed video stream of “Standard Definition” video requires around 30 Mbytes/s, nearly 100 Mbit/s of bandwidth which is not practical to stream to end users. To solve this problem the encoders use codecs to compress the data stream. How much compression is applied depends on desired quality, size (dimensions) and perhaps most importantly available bandwidth both to the server, from the server and at the clients end of the network. Good quality quarter screen webcast feeds of between 150 and 300kbit/s can be created with modern codecs when combined with techniques such as reducing resolution and frame rate.

Appendix 2 gives a detailed example of using a software based encoder called Wirecast (Varasoft, 2006) to create a QuickTime webcast stream on a PC, as used during the recent Prolearn Summer School 2006.

Serve

Serving the live webcast stream is the responsibility of the streaming server. When a client requests a “live streaming file” from the server, the server replicates the incoming stream and forwards it onto the webcast clients. Each client’s request generates a single Unicast feed. Modern streaming servers can handle thousands of such simultaneous feeds. However bandwidth requirements are almost always the limiting factor. For example, 100 clients viewing a 200kbit/s stream would consume 20Mbit/s of the available bandwith from the streaming servers immediate network.

Appendix 3 outlines available server technologies and some alternative broadcast methods that can be used to minimize bandwidth.

Publish

Publishing a live feed can be similar to providing end users with a URL. In the case of RTSP (Real Time Streaming Protocol, 2006) for example, the URL might look like;

rtsp://my.streamingserver.com/somepath/live_feed.sdp

The handling of webcasting streams is highly dependant on the codecs used to encode the data, and the formatting of the files. It is quite easy for the receiving client to become confused, eg. for the wrong media player to launch and be unable to decode the stream. With this in mind most streaming media solutions have ways of creating a ‘reference’ or ‘meta’ file that refers to the above URL. This file can then be embedded in a web page like a normal video file, allowing information about an event to be combined with the a streaming video file. Specialized content management systems (CMS) such as the XO Backlot (a KMi Stadium Technology) used for Prolearn TV are ideally suited to solving the administrative issues associated with handling many events and associated streaming video files. The Stadium system and commercial products such as Datmedia (Datmedia, 2006) and Starbak (Starbak, 2006) include content management within their streaming solutions. Content management solutions also have the advantage of automatically handling availability of the streaming media, such as limiting access to the streaming file to only when the event is live. Appendix 4 gives an example of using XO Backlot CMS to create an event and publish a live stream.

Contact: Kevin Quick