Streaming the Olympics: How We Got Here

Though it may seem like it was just yesterday, it’s now been 18 months since we delivered for NBC the Beijing 2008 Summer Olympics using Windows Media Services, Windows Media Player and Silverlight. Whereas in Beijing we experimented with HTTP adaptive streaming for on-demand SD delivery only, the one thing we all knew for sure as soon as the Beijing closing ceremony was over was that for Vancouver 2010 we wanted to deliver all video in HD, both  live and on-demand, using HTTP adaptive streaming. By November 2008 the first glimpses of IIS Smooth Streaming definitely put on-demand HD delivery within reach, and by May 2009 live Smooth Streaming was a reality too.

A year ago we began working with NBC and CTV on putting together the 2010 Vancouver Winter Olympics video site, later adding Norway’s NRK as another customer. We teamed up with a number of partners to get the job done:

As you can tell just from the list of partners, this was a hugely complex project. Despite the Winter Olympics being smaller in scale than Summer Olympics, I’d estimate that this project was about 2-3 times more complex than the Beijing 2008 Olympics project due to the additional technical challenges we decided to take on in order to raise the bar in online video streaming.

In order to reduce some of the complexity we also made an early decision to deliver everything exclusively in Smooth Streaming and Silverlight, without a WMS/WMP fallback option. Though I’m sure some critics will be quick to assert such a decision was meant to force greater Silverlight adoption, the truth is less political and more practical: Trying to encode all videos for both Windows Media and Smooth Streaming (let alone additional formats such as MP4/H.264) would’ve probably doubled or tripled the cost and severely impacted the amount of functionality we were able to add to the client.

If you follow Smooth Streaming developments, you’ve probably heard of the Smooth Streaming Player Development Kit and the Silverlight Media Framework. Both of these frameworks and their underlying Smooth Streaming Media Element (SSME) were in fact designed for the Olympics project and first put to test on NBC Sunday Night Football 6 months ago. And while on the client side the Olympics player is actually quite similar to the SNF player (aside from the much improved rew/ffwd/slo-mo features and the lack of multi-camera angles), the chief difference between the Olympics and SNF is actually on the backend. One word: automation.

From a video operations standpoint, SNF was very much a manual operation. We created publishing points and started encoders by hand – and then stopped them 4 hours later. When you’re doing only one game a week, you can afford to do that with just a few people. But when you have to run 20-30 events per day, as many as dozen of those simultaneously, for 2 weeks straight – it’s absolutely unthinkable to try to run everything by hand. You’d need an army of engineers just to keep things running smoothly.

Enter iStreamPlanet. Our encoding service partner took it upon themselves to build a fully automated live video encoding service for the Olympics. This involved: turning on H.264 multicast decoders (our source streams arrive from Vancouver as H.264 multicast streams over dedicated OC-12) and tuning them to the right channels; routing the decoded video to the available Inlet Spinnaker HD encoders; creating multiple publishing points on IIS origin servers; starting publishing points and encoders; stopping encoders and publishing points; moving VOD archives to expected locations. Having such a service allowed Delta Tre, our CMS provider, to remotely schedule events without any human involvement required. For a young technology such as Smooth Streaming this is a big deal because it proves it’s possible to scale Smooth Streaming to large professional broadcast environments.

Another huge development and step forward for this project was the creation of the Rough Cut Editor, a soon to be publicly available “light touch” editor for Smooth Streams. The RCE allows editing of Smooth Streaming sources, both on-demand and live (!), without any re-encoding whatsoever. The concept is remarkably simple: if a Smooth Streaming manifest is like a playlist of video/audio fragments which live in the cloud, then editing, merging and appending multiple Smooth Streaming sources should be as simple as re-arranging entries in a manifest. Since Smooth Streaming video is just a series of fragments and each 2-sec fragment must be downloaded separately, it’s completely irrelevant whether fragments are downloaded/played in a sequential or non-sequential order – the end result plays equally smooth either way. This is something that hasn’t been possible with Windows Media or any other streaming media technology until now. It’s a total game-changer.

No Comments