There's a running joke in my family that when my kids catch me watching sports highlights on ESPN.com during working hours, I smile and say "market research." Okay, not much of a joke, but a couple of weeks ago it actually became true when I noticed that ESPN had dramatically upgraded its highest quality video stream from the site.

How much of an upgrade? Well, when I last looked in February 2009, ESPN distributed at 576x324 @ 24 fps, and encoded using the VP6 codec at a target video data rate 712 kbps. The highest quality stream today is 720p resolution at 29.97 fps, encoded at a video data rate of just under 3 Mbps.

ESPN, which previously distributed via progressive download, has also deployed adaptive streaming -- which is no surprise -- but is using an RTMP-based scheme, rather than HTTP. If you've been following the debate, most cognoscenti consider HTTP technically superior to RTMP because HTTP packets are more firewall friendly and can benefit from HTTP caching, not to mention that you don't need a streaming server to deliver the packets, which should make HTTP less expensive. Offsetting the weight of all these theoretical arguments is the fact that RTMP-based streaming still seems to be the dominant technology, and ESPN choosing RTMP is a nice endorsement.

The folks at ESPN who were responsible for these changes were too busy for a phone interview, but ESPN was kind enough to pass along some email questions to Joe Alicata, director of product development at ESPN Digital Media. Here are my questions and his replies. Below that, you'll find some analysis of the H.264 configuration options used by ESPN to encode its videos.

SM: You've changed from the VP6 to the H.264 codec; why was that?

ESPN: Correct, we have moved to the more universal H.264 codec, which helps reduce overhead within our transcode farm which is designed around H.264 optimizations and efficiency.

SM: You've also changed to adaptive bitrate technology from static. What's the goal here?

ESPN: Correct. This provides the best experience to our fans given the current conditions they are viewing our content by analyzing elements such as CPU and current bandwidth to determine the optimum bitrate for playback.

SM: You've also increased the resolution and data rate of your video. What was that about?

ESPN: Correct. Our goal is to continue to provide the best experience for our fans. We are now delivering five different bitrates up to 720p HD at just under 3MB/sec video when conditions support it.

SM: What was behind your change from progressive download to RTMP streaming?

Correct again. As part of our goal to improve the quality of our fan's experience, we have moved to RTMP streaming gaining us faster time to first frame and the ability for our fans to seek to any point in the video using our chaptering thumbnail feature. This also provides us operational efficiencies as fans are only downloading segments of the content they are likely to view.

SM: RTMP vs. HTTP has been a pretty significant industry debate, with HTTP having lots of promoters and great success with events like the Olympics and Sunday Night Football. Did you consider HTTP? If not, why not, and if so, why RTMP?

ESPN: We did consider HTTP delivery but ultimately felt, at our decision point, RTMP was a more refined option within the frameworks we were using.

SM: What's your current thinking on HTML5?

ESPN: HTML5 video has the promise of ubiquity and standardization if realized correctly. We'll continue to monitor it for the desktop experience.

Stream Details

I downloaded a number of files from the ESPN site, and compiled the stream information shown in Table 1 using MediaInfo and Bitrate Viewer to analyze the files. Note that I compiled this information after my email discussion with Joe Alicata, so I didn't get to ask him questions about the results.

Neither these tools nor any others that I typically use could tell me the audio bit rate of the ESPN encoded files -- not sure why -- though ESPN was producing stereo at 48 khz. MediaInfo indicates that the files were encoded using the x264 video codec, and all files used the .FLV extension.

It's interesting that ESPN used different profiles for the different streams. While I could see using the Main profile for the 720p stream for iPad/iPhone 4/iPod Touch 4 compatibility, if iOS compatibility was an issue, you would assume that the 640x360 stream would use the Baseline profile for compatibility with older iPhones and iPod Touches. So, I'm sure there's a reason for using different profiles for the different streams, but it's not jumping out at me.

ESPN also dropped the key frame interval from ten seconds for the VP6 files to two seconds for H.264. This is standard when encoding for adaptive streaming, since you can only switch streams on a key frame, and more frequent key frames enable more responsive switching. Similarly, constant bitrate encoding is the most conservative approach for adaptive streaming, and what I recommend to clients switching over from single file to adaptive streaming. On the other hand, If you're encoding files for single file streaming, a key frame interval of ten and variable bitrate encoding are the better techniques.

OK, now you know what I know about ESPN's new video scheme. For big producers, I think it's significant and not at all surprising that ESPN stuck with tried and true RTMP-based adaptive streaming. For all producers, the fact that ESPN's three highest streams average over 2 MBPS should tell you that the majority of Joe and Joette Six-Packs out there can retrieve and smoothly play high quality video, and ESPN is raising the bar for all consumer-oriented video streams.