Streaming Learning Center Where Streaming Professionals Learn to Excel
Related Articles
The problem with streaming video is well, um, streaming. To “stream” video, or deliver it on demand without interruption, you must compress it to low data rates that squeeze much of the quality out of the video. In contrast, all streaming video—whether from Apple (QuickTime), Microsoft (Windows Media), or RealNetworks (Real)—looks great when encoded at sufficiently high bit rates. The problem then, of course, is getting it to your computer where it can play smoothly.
Two examples—one new, one old—illuminate schemes for delivering ultra-high bit-rate videos to consumers. We’ll review them, and then see how to use that information to improve the quality of video that you distribute.
The more recent example is ESPN Motion, a streaming video service from ESPN.com. Maybe it’s just me, but it seems like when you live in a house with three women, however young, you’re perennially sports-deprived.
Each morning I enter my office, scan ESPN to see what I missed (the Marlins won the World Series?), and get rewarded with seven or eight full-motion, high-quality video spots chronicling the big games from the previous night. To ensure that I get the TV-like feel even when I’m watching it on my computer, ESPN is kind enough to throw in periodic commercials.
Of course, what fascinates me is the quality. A quick right click on the video window reveals that it’s Windows Media audio and video encoded to a combined data rate of about 600Kbps, double the highest rate of any video ESPN attempts to stream from their site.
Now, my office is blessed with a pretty high-speed DSL connection, but if ESPN tried to stream that data when I clicked Play each morning, the video would stop and start like the Atlanta traffic, which I don’t miss at all. It would also wreak havoc on the ESPN server between eight and nine in the morning when the 1.5 million folks who have installed this service click their Play buttons. Even divided by the four time zones served, that’s a lot of data.
To avoid this bottleneck, ESPN downloads the data to my hard drive at night when the network is slow, so the video is sitting there waiting for me when I finish my 20-yard commute to the office. Actually, it’s still there now, about 268MB worth and growing. Seems that ESPN Motion forgot to clean up after itself; probably not surprising for a service designed by sports fanatics.
Anyway, a few keystrokes on Google reveal that ESPN Motion was designed by engineers from Walt Disney and ESPN in six months, which sounds about right. We’re not talking rocket science here; after all, the first push content scheme arrived back in 1996, courtesy of Pointcast.
Still, ESPN motion is a solid service, very well done, and deserves all the favorable recognition it’s received. The big picture message is equally noteworthy: if you want high quality “streaming” video, don’t stream. Store it locally, taking all the time you need to get a high-quality stream to hard disk, and then play it. This is a disqualifying distinction among streaming purists—regardless of the so-called “streaming” codec used, if it’s downloaded, it ain’t streamed. But for me, as an end user, the result is the same, and the viewing experience is better.
Another example of this principle is QuickTime’s “progressive download” scheme supposedly hatched by George Lucas when he was preparing a Star Wars trailer and reportedly declared, “There are 24 frames per second in this movie and none of them are optional.” Video distributed via this technique is streamed at high quality, sometimes even higher than ESPN’s 600Kbps, but on demand, in response to a viewer’s click on a Web page.
The video starts playing immediately, and is stored behind the scenes to the viewer’s hard disk. If the connection isn’t fast enough and real-time playback catches up to the stream, playback simply stops, but the download keeps coming. After sufficient time, the entire video is stored to disk, and the viewer can watch it at high quality as many times as desired.
Obviously, neither of these schemes works at all if true streaming or instantaneous and continual on-demand playback is necessary. On the other hand, the ability to deliver shorter clips at very high quality has undeniable appeal in many applications.
So, how do we put this to good use on the content creation and distribution end? The easiest way is simply to encode your files at high bit rates in the QuickTime format, since QuickTime seems to adapt progressive downloads most naturally. Tell your viewers to click on the link, make sure the QuickTime player loads, and go get themselves a cup of coffee. By the time they return, the file should be ready to play.
If you have a Microsoft Windows Media Server, enable its Fast Cache capabilities. This accelerates the stream of data to the client, buffering ahead of playback; if network data is lower than the actual bit rate of the content, it buffers a portion of data before the data starts to play.
When streaming high bit-rate streams in either Windows Media or RealVideo formats, instruct your viewers to adjust their preference settings to increase the amount of data buffered before playback begins. This works less reliably than progressive downloading, but often seems to buffer enough data to allow complete, uninterrupted playback of a very high bit-rate file.
Finally, recognize that the equivalent of the ESPN scheme in a corporate wide-area network is to store the high-bandwidth streams on a local server, where users can access them on the local-area network without consuming wide-area connections. You can accomplish this by implementing cache or proxy servers that are available for both Windows Media and RealNetworks streaming architectures.
