Recently, a client requested that I create a Silverlight application that would “stream” video on demand. Since I knew the client didn’t have any server infrastructure in mind. I asked the client if true streaming was really required. This got me a blank stare, and I rephrased my questions in terms of what functionality and user experience was actually required. What I discovered was that the client wanted users to be able to play videos without having long download delays. He used the word “streaming” because, as he said, “streaming is just what I say when I mean getting video over the Internet.”

He’s not alone. It seems that this word, streaming, has become somewhat synonymous with watching video or audio over the Internet, without regard to the actual nature of delivery. In truth, many of the situations described as streaming are actually using another delivery mechanism known as progressive download.

This matter is further confused by the fact that the Microsoft Silverlight Streaming Service (http://streaming.live.com) does not actually stream anything, but rather provides files via http- allowing progressive download of video or audio files, or plain-old download of other files. The service has an exciting name with “Silverlight and Streaming” prominent, but in fact it’s really just a big ol’ file server in the sky. However, that file server is being provided expressly to help support people writing Silverlight applications and as a free service it is a Good Thing™. Nevertheless, the naming is confusing.

After talking about these matters with a number of colleagues, I’ve discovered that there’s a general confusion about the differences between streaming, progressive download, and simple downloading - both among technical and business professionals. So, I decided to write a not-very technical primer to help orient people.

Let’s start with understanding three different types of file delivery over the internet: downloading, streaming, and progressive download.

Downloading

Explicitly downloading a file is well understood by practically everyone. You somehow indicate a file (click a link, drag an icon, etc…) and you wait a while during which that file copies over to your hard drive. Once it’s there you can open it, or do whatever you like with it: it’s your local copy.

Downloading files that are embedded into a web page is a somewhat more subtle matter. If I visit a web page with pictures in it, what happens is that each picture gets downloaded to my hard drive and then gets displayed on my screen. My browser doesn’t show it to me directly off the Internet, but rather looks at the copy of the file on my hard drive in order to show the information on the screen. I say this is slightly more subtle, because I never pick out a location for these files, they just get automatically downloaded and then, if not accessed for a long time, will ultimately get deleted to make room for other files. On my computer, with the browser I use, they get stuck into a folder called "Temporary Internet Files."

Streaming

Streaming, and by this I mean true streaming, works quite differently. With this mode of delivery, a file (or other kind of “feed”) is sent to your computer a little bit at a time, just fast enough for you to watch/listen to it. Streaming is inherently about delivering information that has a time aspect. When I’m watching a movie, I don’t need to be seeing the beginning, middle and end at the same time, I consume it a frame at a time. Pictures, on the other hand, are viewed all at once and thus are not suitable for streaming.

Now to most folks, this may all seem very obvious, but there’s a key point going on here. In true streaming the bits that are sent to your computer are never put onto the hard drive. Instead, they’re directly interpreted by your streaming media player (like Windows Media Player, Silverlight, Quicktime, Flash, or what-have-you). After you watch a moment of audio or video stream, it’s gone—never having been stored to your hard drive.

Streams can be live or on-demand. In the live case, some kind of broadcast is being converted to a streaming format and fed out as soon as the conversion process allows. In on-demand cases, typically files are stored on a server and some kind of server software feeds them out on request—the rate at which they are fed out corresponds to the rate at which they are meant to be viewed/listened to. At no point, even in an on-demand stream, does the stream go way ahead of the client… you’re not downloading any future parts, even if you have sufficient bandwidth to do so. Often clients will buffer a few seconds of the stream, but it's pretty much play-it-as-it arrives. The buffering happens in memory and again, nothing is saved to hard drive.

Streaming has several key advantages over downloading. First, you can start watching more or less immediately. Second, you don't use up any hard drive space on the client computer. Finally, because the file is not stored locally, it can be a good way of providing copy protected content to an end user. Many sites which legally play copyrighted materials do so in a streaming format. When the user is not authenticated and logged in, he cannot access the content locally.

The biggest disadvantage to distributing streams, however, is that true streaming requires a server that is capable of producing streams. Microsoft Media Server and Adobe Flash Server are two such examples, and they each stream in their own proprietary formats: mms and rtmp respectively. So, in other words, if you wanted to point your browser or streaming media player directly at a stream, you’d type an address that starts with mms:// or rtmp:// as opposed to http://. The http: is a good tipoff... if your video file comes from an http address, it's a sure bet that it is not truly streaming.

Progressive Download- The Hybrid

So, what then is progressive download? Here’s where the water begins to get muddy because to the end-user, progressive download can feel exactly like true streaming but to a software developer or IT person, it’s a lot closer to downloading.

It works like this: in progressive download, the browser or media player that a file be downloaded. But rather than waiting for the entire file to arrive, the playback starts as soon as there’s enough downloaded to play back some of the file. Generally, this is within only a second or two. As you watch/listen to that first piece, the file keeps downloading, and given a good enough connection, you’ll have all new pieces of the file before their needed—the download will outpace your viewing and you’ll watch it from beginning to end with only a couple of moments of delay at the beginning.

So, in progressive download versus regular download, you don’t have to wait for the entire file to download- you can start watching pretty much just as quickly as you could in a true streaming situation. As I mentioned before, from the end-user’s perspective, progressive download can feel exactly like streaming and if you click on a link and it starts playing a video right away, you can’t necessarily without looking at the URL of the link or some http traffic whether that content is being delivered via stream or progressive download.

Unlike streaming, however, in progressive download the thing you’re watching is actually being downloaded to your hard drive (generally into the browser cache if you’re watching something embedded in a web page). This brings us to one of the key disadvantages of progressive download: it tends to be unsuitable for some forms of premium content where the user is not meant to be able to play back the file on demand. For example, if you use the site www.pandora.com, part of why they are able to play music legally without charging is that you cannot pick what you listen to. If you were able to retrieve files from your hard drive after they’d been downloaded, then you could build your own illegal library of music, and Pandora would probably not be allowed to send such content over the Internet.

Progressive Download and Random Access

When I first learned about progressive download, I mistakenly thought that trying to access random parts of a file would be a big problem. Suppose the item that you’re watching via progressive download is a three hour movie… sure, you can start watching the beginning in a few seconds, but what if you want to jump to the middle of the file… then you need to wait for the download to catch up—downloading 1.5 hours, right?

As it turns out the situation is much better than this given the right configuration. If the web server that hosts the file supports http 1.1 (which virtually all do) and if the client is smart enough, then downloading does not have to happen beginning-to-end. Instead the client says to the server "hey, can you give me this particular section of the file I'm interested in?" and the server will send back just that piece in response. It's then saved by the client to the hard drive, but rather than waiting for the whole file to arrive, the client (Media player, quicktime, etc) just shows that little piece to the user. These requests for small slices of the file are called "byte-range requests" and any http 1.1 server supports them (it's part of the http 1.1 definition).

Silverlight as a Client

Notice that to achieve progressive download, you need a client capable of requesting byte ranges and capable of playing a portion of a partially downloaded file. All the major media players are capable of this. However, I believe that earlier versions of the Silverlight MediaElement (the Silverlight built-in media player control) were not able to do this. This seemed to lead to more confusion about streaming, whether Silverlight supports streaming, etc.

I've done first-hand tests and I can safely say that Silverlight 2.0 does indeed support playing downloaded files, true streaming, and progressive downloads. It seems to do a little better with true streaming than progressive download performance-wise, but I'm not quite sure on that. It seems like you should be able to get pretty much the same performance/quality from progressive as from streaming, but I haven't quite gotten that performance-- it may have more to do with the encoding of the files than actual performance.

Hope this clears things up a bit!