The Silverlight Guru: Protocols and the Big Picture
If you've got questions about streaming with Silverlight—or anything related to Windows media video or audio—you've come to the right place. Ben Waggoner is Microsoft's principal video strategist for Silverlight and he's well-known to those who frequent industry conferences and forums. He's the source, and he's happy to address Silverlight questions large or small.
For this series, we'll be fielding Silverlight questions from Streaming Media's readers and from the Streaming Media forumsfor Ben to answer. If you've got something you'd like help with, post to the forum or, even better, drop us a note at tdreier@streamingmedia.com, so we can keep surprising Ben with questions he hasn't seen before.
Our first question was e-mailed from Erik from Sureflix Digital Distribution:
As we are porting our embedded video player from Window Media Player to Silverlight we have noticed there is no Silverlight equivalent for Network.bandWidth, Network.bitRate and Network.lostPackets. With WMP we used these properties to select the correct bitrate file for each user and to monitor QoS. Are there any plans to support these features in Silverlight any time soon?
Another area that is lacking in Silverlight is support for setting the video playback rate (slow-motion or fast-forward). Are there any plans on adding that as well?
Streaming with Silverlight never uses the lossy protocols you may be used to, explains Ben, so the tools are going to be a little different. While the Windows Media Player starts with UDP (User Datagram Protocol) as its first option (then falls back to TCP and finally HTTP) when streaming media, Silverlight always receives data via HTTP. With UDP, packets that went missing in transmission would need to be specifically requested for resending by the player. With HTTP, dropped packets are automatically resent as part of the protocol making LostPackets not really a useful metric.
Video actually moved to the HTTP protocol because of expediency, says Ben, explaining that he's summarizing ten years of network protocol development in a few sentences. Many firewalls blocked UDP traffic, forcing a fallback to HTTP, so lots of streams wound up tunneling through HTTP anyway. With Silverlight, Microsoft just skipped straight to HTTP, avoiding the potentially lengthy negotiation and fallback period WMP could have while trying UDP and then TCP before finally getting to HTTP.
As for bandwidth, that's hard for a video server to measure, since the stream can't know how much it's not using. If not all the content gets through, however, then it can be measured. You should check out Silverlight's new Smooth Streaming technology, which automatically measures the download time of each chunk of video data to see if the viewer's connection can handle higher bandwidth content. If the pipe is large enough, the viewer will see a better picture. With Smooth Streaming, which Akamai began supporting a few weeks ago, video quality is dynamically adjusted so the stream never stops or even pauses.
The APIs Silverlight does have that can be used to tune classic WMS streaming are Rendered FPS, Dropped FPS, and Buffering (also here). With the CBSSports.com NCAA March Madness player, Microsoft used measurements of dropped frames and buffering events to suggest the user switch bandwidths. Since Silverlight is a full application framework, deep heuristics can be implemented inside of Managed Code.
As for the slow-motion and fast-motion requests, Ben admits they've gotten other requests for it, but says "We can only get so much done in a given release; that's not something we’ve implemented for Silverlight 3."
We got two e-mails from Michael T. of Massachusettes, and the first wasn't so nice. "Why does he work for the Dark Side?," Michael asked. (For the record, Michael, Ben says he's been a Mac user for more than 20 years, and currently enjoys the opportunity to make an impact on online video by working with such an enormously influential company.) In this next note, Michael asked:
What strategically is Microsoft trying to gain from Silverlight and who does MS see it's main competitor?
Silverlight is fundamentally about making a great rich interactive technology, Ben says, and grew out of the huge investment Microsoft and its partners had made in the .NET platform. The technology broadened where .NET can be deployed to, including the Mac and soon portable devices. Silverlight developers have been working with Novell, Ben explains, to help improve Moonlight, a open-source implementation of Silverlight for Linux, based on the popular Mono implementation of .NET.
With Silverlight, Microsoft also wanted to create a technology that would meet its own publishing needs for MSN, Xbox.com, and more. Windows Media Player wasn’t well-supported on other platforms, but Silverlight is a cross-platform solution. It's even developed in areas that weren't part of the original design: Smooth Streaming, mentioned in the previous question, wasn't envisioned at first, but was able to happen because of Silverlight's smooth and flexible structure.
As for the competition, Silverlight is focused more on building a great Rich Interactive Application technology than the competing technologies. Java and Flash are both browser plug-in RIA platforms, but each has some big differences in the fundamentals. Certainly, only Silverlight has anything like Smooth Streaming. The goal is to offer a broadly supported high-quality experience with tools such as better advertising functionality and a better video experience—such as with four-camera support and picture-in-picture technology—to impress the viewers.
Submit your Silverlight questions to Streaming Media’s Formats, Codecs, and Players forum, or send them directly to the author at tdreier@streamingmedia.com.