a blog by Peter Leonard
Clontzman alerted me to a newly-redesigned ESPN site today. One of the most-hyped features is ESPNMotion, a kind of hybrid streaming/cached video delivery system that straddles the boundaries between web and desktop video.
Looking at the FAQ, it's a little difficult to determine exactly what ESPNMotion actually is. System requirements include Flash, which initially made me suspect that it was doing video through the Sorenson Squeeze codec, which is exclusive to Flash. But further down the page we discover that Windows Media Player is also a requirement. It seems odd to involve that software and bypass the much-hyped Sorenson features of Flash, but I never did get jocks anyway.
I installed ESPNMotion on a sacrificial testbed system we keep around for our webmasters to look at pages on a PC. The installer itself is a Win32 app, but before you get to that you need to make sure Flash 5 and WMP7 are installed. The installer is responsible for a piece of tray lint, as well as a background app called "Digstream."
The background app invisibly connects to ESPN's servers (presumably through port 80 to avoid most firewalls) and downloads WMV files in the background. When a quorum of these are saved into c:\...Application Data\DIGStream\ESPNMotion, the tray lint springs to life and alerts you that ESPNMotion is ready for you. Clicking on the notification icon takes you to the main ESPN.com page, and through the magic of JavaScript the web page calls up the dormant WMV files on your hard drive and plays them within the frame of the ESPN site.
This is the real key selling point of DIGStream, or whatever shell corporation sold the tech to ESPN. Since all the clips are downloaded in the background, and you aren't told about it until there's a critical mass (or mess) of them for you to peruse, the system creates the illusion that the video is streaming instantly to your web page, without any of the annoying buffering, hiccups and delays that usually plague on-demand video.
A little investigation reveals the following about the files themselves. So far, they seem to be between 1 and 7 megabytes in size. All are suffixed with ".wmv" as any regular Windows Media file should be, and are encoded with WM9 codecs. Windows Media 7 (the latest available for Windows 98) is capable of using WM9 codecs, so that should take care of the low-end users without a problem. Bitrate is just under 700kpbs, a level of data that would never work on the web but is perfectly fine playing back from winchester storage devices such as your desktop hard drive.
What does ESPN do with all that throughput? For one, they bump the FPS up to 30fps - something that contributes to the dramatic increase in perceived image quality versus normal streaming video. Compared with most clips streamed over HTTP or RTSP, these local files look much more like a DVD player window, which is pretty much the only other time most users will have seen nearly 30fps on their computer.
Strangely, ESPN has decided to encode at least the audio portion of these files in Continuous Bit Rate as opposed to Variable. (WMP doesn't report any details on the video portion of my stream). Since ESPN presumably has enough time to really massage the compression on these clips, you'd think they would go VBR to reduce their size somewhat.
Finally, a note on bandwidth. As a pseudo-network administrator for my department, I have to wonder about dozens of employees running ESPNMotion in the background all day long, sucking down clip after clip of WMV files. Depending on how often ESPN plans to push out new files, this could be quite a waste of bandwidth. At least in regular streaming media clients, the bandwidth is only in use when someone is actively viewing or buffering a file. ESPNMotion's behind-the-scenes approach may make things easier for the end user, but it risks raising the ire of those who have to manage ever more scare shared resources. Some open architecture for supporting local caching servers - as PointCast was forced to do before common sense overtook their own momentum - would go a long way towards making ESPNMotion a more friendly network citizen. It's possible that if DIGStream uses port 80, many corporate firewalls which contain caching web proxies would work seamlessly.
I'm also curious as to whether the URLs from which the background app is collecting the videos are patched into Akamai or another similar bandwidth distribution schema. You would want that kind of geographic and topological strategy when you consider the popularity of sports in general and ESPN in particular on the web today. Netcraft tells me that at least one of their servers, motionslow.espn.go.com, is running Apache on Netware, about which I shall say nothing in order to be polite.