Got your attention?  I hope so, because for such a hot technology, there’s a surprising level of misunderstanding and general fuzziness out there around the precise meaning of the term ‘streaming‘ - even among some new media types Who Should Know Better.  Here, then, is a brief clarification (in an effort to keep the eyes-glazing-over syndrome to a minimum, I’ll keep it as short as possible):

One of the most basic things web protocol HTTP does is allow for the downloading of files - in fact, each and every image and/or icon you see on any web page is just a simple (image) file that your browser has downloaded into temporary storage somewhere ‘under the hood’ and then rendered for you to view.  If you have Adobe’s  Flash Player installed (and according to a recent study, 99% of you do), the browser knows it’s also OK to download any Flash file types it comes across, because the player will take it from there.  Of course, Flash (or  Silverlight or Quicktime, for that matter) will let you start viewing the content while the file’s still being downloaded, but that is not streaming (it may feel that way, but it’s not).  What it is instead is something that’s come to be known as progressive downloading - and historically, at least, this is what YouTube has been doing.

On the server-side, there’s no rocket science involved here - just point some simple HTML code to the flat Flash file as you would at any image file, and you’re done.  Of course, there are limitations to such a simple solution.

• First, whether progressively viewed or not, the content ends up as a local file - so it’s relatively accessible to the viewer (there’s no shortage of YouTube video-capture software out there to do just that).  While that’s not much of an issue for user-generated clips of water-skiing squirrels, it is an issue for implementing robust copy protection on premium content.
• Another issue is bandwidth management - while client players do request a bit-rate (i.e. quality level) based on an initial one-time test of the  internet connection, the server has no knowledge of this - it knows only that an entire file (and a much larger file than a typical image file, I might add) has been requested, so it serves that entire file as fast as it can regardless of any client-side network conditions or whether the content’s actually going to be viewed in its entirety.  Not efficient.

Enter the streaming media server, specialized software designed to deliver a stream of zeros and ones as needed, rather than rely on any web server’s basic ability to serve files.  Think of it this way: while progressive downloading is much like standing at the water cooler at the office holding a paper cup you can drink there or walk away with and maybe not even finish,  streaming is more like standing at the water fountain at your gym.

• This makes rights management much easier, since there’s no actual underlying file involved

• The other advantage is that unlike ye olde HTTP, newer streaming protocols such as Microsoft’s MMS and Adobe’s RTMP know all about the changing network conditions and maintain an ongoing back-and-forth conversation with the client - to sneak in a bit of computer science lingo here (because that Master’s degree was expensive), these protocols are stateful (HTTP, in contrast,  is stateless).  This fundamental characteristic makes all manner of performance optimization and interactive functionality possible.

In short, internet video via progressive download is essentially an artifact of HTML and the web browser. Over the next few years,  internet video will  inevitably evolve to be primarily comprised of premium (rights-protected) content delivered to non-browser platforms such as set-top boxes and televisions that may not even have a hard drive to download to.  As Amazon clearly understood when it switched from a download to a streaming model last year for it’s Video on Demand service,  true streaming will be crucial to this evolution.