Progressive Downloading and Streaming

Ordinarily, if you take no special steps, Silverlight plays media files using progressive downloading. This technique means that the client downloads media files one chunk at a time. Once it's accumulated enough of a buffer to provide for a few seconds of playback, it begins playing the media file, while it continues downloading the rest of the file in the background.

The overwhelming advantage of progressive downloading is the fact that the client can begin playing a media file almost immediately. In fact, the total length of the file has no effect on the initial playback delay. The only factor is the bit rate—in other words, how many bytes of data it takes to play 5 seconds of media.

Progressive downloading also has a second not-so-trivial advantage: it doesn't require any special server software, because the client handles all the work of buffering. Thus, the client can use progressive downloading with any web server. And if you want to ensure scalability on the web server, you simply need to set a maximum transfer rate using bit rate throttling, as described in the sidebar on this page.

BIT RATE THROTTLING

Bit rate throttling is a feature in the IIS web server that allows you to limit what users can download to certain types of content. With video content, bit rate throttling prevents people with good connections from downloading the video file really quickly, which could swamp the server if a large number of people request the file simultaneously. Bit rate throttling also saves bandwidth overall. That's because most web surfers won't watch a video form start to finish. In fact, it's estimated that 80% of users navigate to a new page before finishing a video, effectively throwing away any extra unwatched video data they've downloaded in advance.

Typically, when using bit rate throttling you'll configure IIS to begin by sending a burst of content when a video file is requested. This ensures that the user can start playback as fast as possible. However, after this burst—for example, after the user has downloaded 10 seconds of video—the rest of the video data will be sent much more slowly. Limiting the transfer rate has no real effect on the client's ability to play the media, as long as the client can download the content faster than the application can play it. In other words, a 700KB/s transfer limit would be a disaster if you had a high-quality video with a bit rate over 700KB/s.

To use bit rate throttling, you need to download the IIS 7 Media Pack, which Microsoft provides as a free download at http://www.iis.net/default.aspx?tabid=22. You can also find a full walkthrough that shows you how to configure bit rate throttling at http://learn.iis.net/page.aspx/l48/bit-rate-throttling-configuration-walkthrough.

For all its advantages, progressive downloading isn't perfect. It also has a few notable disadvantages, which are remedied by a technology called streaming. When streaming, the client doesn't perform an ordinary download—instead, it communicates with web server continuously. Furthermore, the client doesn't need to manage the buffering, because the web server sends just the content that's required.

Streaming has the instant playback ability of progressive downloading, along with the following advantages:

• Scalability. Although bandwidth throttling ensures respectable server scalability, streaming is still far more efficient. Although there are numerous factors, switching from progressive downloading to streaming could net your web server a two or three times improvement in scalability—in other words, it may be able to serve the same video content to three times as many simultaneous users. This is the reason that streaming is usually adopted.

• Control over seeking. With streaming, each chunk of video data is discarded once it's been displayed. This prevents users from saving the complete video file on their hard disk. You also have the choice of whether or not to allow seeking. You can index your content so that the user can freely jump around to new positions, with little lag, or you can restrict seeking in some video content so that the user is forced to watch it from beginning to end—and annoying but practical technique if you're displaying an advertisement before the real video content that the user wants to watch.

• Adaptability. Different clients have different connection speeds, and can support different bit rates. When providing progressive downloads, many websites deal with this issue by including lower-quality videos that are more likely to be supported, or by giving users the choice of different versions of the same file, each of which is encoded at a different bit rate. The first technique gives you a poorer viewing experience, and the second option has its own problems—it's time-consuming, average users don't always know their bandwidth, and the amount of video data a computer can handle can be influenced by other factors, such as the current CPU load or the quality of a wireless connection. When you use streaming server, you can opt into a more powerful solution called adaptive streaming. With adaptive streaming, the web server customizes the bit rate of the media file to suit the client. If the situation changes—for example, the network starts to slow down—the server deals with the issue seamlessly, automatically adjusting the bit rate down, and bringing it back up again when the connection improves. The player won't have to stop and refill its buffer, as it would with a progressive download.

Streaming also has one significant disadvantage. Namely, it needs the dedicated serverside software known as Windows Media Services. Windows Media Services is included with Windows Server 2003, and available as a free download for Windows Server 2008.

Note If you use the MediaElement with a URL that starts with http:// or https://, Silverlight begins a progressive download. If you use the MediaElement with a URL that starts with mms://, Silverlight attempts to stream it, and falls back on a progressive download if streaming fails.

So what's the bottom line for a developer when creating a media-rich Silverlight application? First, determine whether you'll be deploying your application to a web server that supports streaming. That will determine the best way to encode your video files (as described in the next section). Currently, about 65% of all web content is delivered by progressive download, with YouTube leading the way as the single most popular deliverer of video content. For a deeper look at the technical differences between streaming servers and progressive download, check out http://learn.iis.net/page.aspx/454/windows-media-server-or-web-server.

If you don't want the complexity of configuring and maintaining a server with Windows Media Services, or you use a web host that doesn't provide this service, your applications will use progressive downloading. You'll get the most out of progressive downloading if you follow these best practices:

• Consider providing multiple versions of the same media file. If you have huge media files and you need to support users with a wide range of connection speeds, consider including an option in your application where users can specify their bandwidth. If a user specifies a low-speed bandwidth, you can seamlessly load smaller media files into the MediaElement. (Alternatively, consider encoding your video with a lower bit rate. If the tradeoff in quality is acceptable, you'll simplify your code.)

• Adjust the BufferingTime property on the MediaElement. You can control how much content Silverlight buffers in a progressive download by setting the BufferingTime property of the MediaElement. The default is 5 seconds of playback, but higher-quality videos that will be played over lower-bandwidth connections will need different rates. A longer BufferingTime property won't allow a slow connection to play a high-bit rate video file (unless you buffer virtually the entire file), but it will smooth over unreliable connections and give a bit more breathing room.

• Keep the user informed about the download. It's often useful to show the client how much of a particular media file has been downloaded. For example, websites like YouTube and players like Media Player use a progress bar that has a shaded background, indicating how much of the file is available. To create a similar effect in a Silverlight application, you can use the DownloadProgressChanged event. It fires each time Silverlight crosses a 5% download threshold (for example, when it downloads the first 5%, when it reaches 10%, when it reaches 15%, and so on). It also fires again when the file is completely downloaded. When the DownloadProgressChanged event fires, you can read the DownloadProgress property to determine how much of the file is currently available (as a value from 0 to 1). Use this information to set the width of a Rectangle, and you're well on the way to creating a download progress bar.

• Consider informing the user about the buffer. You can react as the buffer is filled using the BufferingProgressChanged and read the BufferingProgress property to find out how much content is in the buffer (as a value from 0 to 1). For example, with a BufferingTime of 5 seconds, a BufferingProgress of 1 means the client has its full 5 seconds of media, while a BufferingProgress of 0.5 means the buffer is half full, with just 2.5 seconds available. This might be too much information to display, or it might be useful to the user to see why a media file can't be buffered successfully over the current connection.

• Use bit rate throttling. If you own the web server, you may want to ensure the best possible scalability by limiting the speed at which users can download content. Choose a limit that's slightly above the bit rate of your videos, but not extreme (for example, 500KB/s).

It's worth noting that the word streaming isn't always used in the technical sense described here. For example, Microsoft provides a fantastic free Silverlight hosting service called Silverlight Streaming. It provides 10GB of hosting space for Silverlight applications and media files. But despite its name, Silverlight Streaming doesn't use streaming—instead, it simply serves video files and allows the client to perform progressive downloading.

Tip If you're looking for an efficient way to host large media files with your Silverlight application, be sure to consider Silverlight Streaming (http://silverlight.live.com). It's free, has no advertisements or annoying branding requirements, and offers a staggering 5 terabytes per month of bandwidth for video viewing.

+1 0

Average user rating: 5 stars out of 1 votes

Post a comment

  • Receive news updates via email from this site