Lessons Learned From Live Events

It’s hard to believe, but 2009 marks the 10th anniversary of TV Worldwide. Over the past decade, we’ve webcasted more than 5,000 live and archived events and, by necessity, become quite experienced at producing live webcasts—so much so that many of our clients know us primarily as a live-webcast service provider. This experience has taught us many things about what and, perhaps more importantly, what not to do.

1. Have a Reason to Go Live
This may seem obvious, but there are many webcast events that don’t have any real reason to be streamed live other than the "sexiness quotient." Live is almost certainly more exciting, but that excitement stems mostly from the frayed nerves of hoping the long list of things that could potentially go wrong don’t. However, there are two main conditions that, if either is met, are solid reasons for webcasting live: if the event is interactive and participatory on the part of the viewers and if the content is time-sensitive.

Interactive participation in a webcast doesn’t necessarily require it to be live, but it certainly helps. And doing a webcast that is live and participatory greatly increases the chances that viewers will remain glued to their monitors for the duration. Adding contests or raffles at the end of webcasts as well as strong "takeaway" content also helps to increase the stickiness and participation.

Time-sensitive content, on the other hand, tends to require a live webcast. Examples of this kind of content might be a press conference, a major news announcement, a sporting event, or an awards show—any event in which the content has little to no evergreen value and is old news as soon as it is learned.

2. Don’t Blow Out the Bitrate (or Screen Size)
There is no shortage of people and companies bragging about their HD streaming capabilities. Technological reality aside, do you really have to stream at 500Kbps or higher? If the content is fast-paced, such as a sporting event, or if it has a lot of fast camera movements, then you obviously need to push more data to fill in the gaps and avoid pixelation. However, for much other content—such as talking-head content or videos featuring stationary or slow-moving objects—streaming anywhere from 200Kbps to 300Kbps works just fine.

You should also think carefully about the size of the screen, especially in an embedded environment. The rule of thumb here is to know your audience. If you are streaming music videos to a largely 20-something, male, tech-savvy audience, then maybe you want to push the envelope on bitrate and screen size. However, if your audience is made up of professionals on corporate networks, keep in mind that five people in the same office watching a webcast at 300Kbps will more than max out a T1 network connection for the entire office. For the client, we’ve consistently found that reliability and ease of use for the viewer rank higher on the list of must-haves than the biggest screen at the highest bitrate and resolution. Keep in mind, you can always go back to the source and encode at a higher bitrate for an on-demand archive, which is always much easier to deliver.

3. Test, Test, and Test Again
Any live production is, by definition, a one-shot deal. Either it goes right or it doesn’t. The only way to ensure that it goes smoothly is to test and plan using the exact conditions as the live event. Of course, no one can think of everything that could possibly go wrong and plan for every contingency. But there are some general issues that come up regularly enough to warrant mention.

The obvious first step is to clock the internet connection and determine your upload and download bandwidth. It’s good to speed-test the connection against a couple of servers in different geographical locations to see if one is noticeably better or worse than another. If you have the option of working with multiple delivery networks or if the network you use has multiple publishing nodes, this test could suggest the best place to point the stream.

Second, and perhaps most importantly, it’s often critical to get an encoder set up on-site prior to the event and send a test stream to the publishing point that will be used for the live event. This will not only tell you if you can send a solid and reliable stream from the event location, but it will also bring to light any potential firewall issues. We almost always choose to push the stream as opposed to having it pulled from the delivery network so that we don’t always need to have a static IP address or a connection outside of the local firewall at the event location.

If it’s possible to run the test on an earlier day at a similar time to the live webcast, that is ideal. Many conference centers and hotels have very different usage patterns over their local networks. And not all of them have a clear bifurcation of the internet line provided for the webcast and the rest of the network. However, it’s important to ask if the internet line can be split and if the venue has the capability of "fencing off" the minimum bandwidth you need to be safe at the chosen bitrate. If it’s not possible, it’s still worth asking if the venue can do this, if someone there knows how the network is divided, and, if necessary, what the usage patterns are typically like during the time the event is to take place.