December 31, 2010
By Jan Ozer Contributing Editor
Featured Articles

Adaptive Streaming in the Field

Other Approaches
Other producers take more of an experiential view. From Harvard, Bouthillier added that “the on-demand encodes at 768/384/256/128/64 were a semi-random selection to simply see what would actually get viewed. In fact, we never expected to see a roughly even distribution of streams delivered among the 256/128/64 bitrates. So for certain high-value on-demand content, we do continue to encode at all of them, for now. Though, sometimes we use one at 512 instead of having two at 768/384. Having this many options does make the adaptive streaming smooth and seamless when stream-switching happens.

“For live, we don’t have as much data or experience, but the difficulty of encoding to many bitrates at once leaves us to reason like this:

• 1Mbps for real broadband users who go full-screen (Flash detects this and does a stream-switch up.)
• 500Kbps for most people on either desktop or Wi-Fi/mobile devices
• 100Kbps for 3G mobile and web users with no broadband.”

Bouthillier also made some valuable comments in his “Dynamic Streaming With Flash Media Server” article, where he stated “Selection of available bitrates: The most successful tests I conducted include a number of streams with fairly close-together bitrates. When network conditions fluctuated, a stream switch that involved a large jump in bitrate or screen size was distracting. Stream switches between more similar bitrates were often barely noticeable and provided a more pleasant user experience.”

Finally, Indiana University had the most unusual data rate resolution schema: It used the same resolution for all three streams. When I asked Gunkel why, he explained that IU does this because the video files were primarily played on a projector in the classroom. IU experimented with smaller resolutions at the lower data rates, but after zooming the streams to full-screen display, videos encoded at 720p looked better than those encoded at smaller resolutions at the same data rate.

Which Configurations Were Most Watched
The next question relates to the streams actually watched by each site’s viewers. Goldstein at MTV had the most detailed statistics to share, including that 45% of viewers start at the 768x432 stream (at 1.7Mbps) and remain there for the duration of the stream.

An additional 19% click into full-screen mode and view at 720p@3.5Mbps, while 8.5% adaptively drop down to 960x540@2.2Mbps from the 720p stream due to bandwidth or CPU limitations. This means that more than 70% of MTV’s viewers are watching at 1.7Mbps or above. Beyond this, about 7% watch at 640x360 with the rest of the viewers evenly scattered in the bottom three stream categories.

With this year’s PGA Championship, Turner Broadcasting had a similar experience. Turner offered six different bitrates from 500Kbps to 2.5Mbps and found that 75% of viewers connected using the 1.5Mbps HD stream.

Despite a maximum stream bandwidth of 768Kbps, Harvard had almost the opposite experience, with more than half of its viewers streaming at 256Kbps or below.

Microsoft didn’t relate stream-specific information. But it did note that, for the Olympics, NBC streamed 24 concurrent live channels and reported 181,000 peak concurrent viewers for one single event. While few of us will ever come close to that number, it’s a nice affirmation that adaptive streaming can scale to massive viewing demand.

iOS Devices
Here are a couple of observations: First (and don’t get your dander up, Mac-heads), ignoring the iOS device market won’t doom you to failure, since neither the Olympics nor Sunday Night Football supports iOS devices at this point. However, as Microsoft and, no doubt, NBC realize, it probably isn’t in your best interest to ignore this market, since it represents so many potential viewers.

The other observation is that solutions for supporting computer and iOS device playback are shifting from separate, dedicated facilities to technologies/services that input an FMS or Silverlight stream and dynamically rewrap it for adaptive iOS delivery. To explain, while Flash, Silverlight, and iOS devices can all play H.264 encoded files, each has its own specific format for adaptive delivery. For example, Microsoft wraps all files in an adaptive streaming group into a single ISMV file, while Apple wants the files wrapped into an MPEG-2 transport stream. Adobe’s RTMP-based Dynamic Streaming uses separate MP4 or F4V files, though Zeri, Adobe’s HTTP-based solution, will wrap files in the F4F format.

When HTTP Live Streaming first became available, producers accessed it by adding separate encoding and server capabilities to complement their Flash or Silverlight offering. Now, we’re starting to see products and services that can input one format then “transux” or rewrap the video files for consumption in another. Wowza Media Server was one of the first to offer this capability, and it’s being used by one of our respondents.

MTV is using a new service offered by Akamai that accomplishes the same thing. Here’s a blurb from the Akamai press release: “Akamai Technologies … today announced new capabilities for its HD for iPhone solution designed to simplify delivery of standards-based, on-demand video to iPhone, iPad and iPod touch. Known as ‘in the network’ packaging, this capability will let content providers leverage their existing H.264 and MPEG4 video workflows and automatically package their content to the format required for playback on iOS devices.”

Several respondents noted that many smaller CDNs or OVPs are starting to offer similar services. Getting back to Microsoft and NBC, Microsoft is offering rewrapping capability similar to Wowza in the Internet Information Services 7 web server that’s part of the Windows Server 2008 R2 SP1 Beta. Once the product transitions from beta to final, you may see NBC moving to support iOS devices.

Overall, this trend should dramatically reduce the complexity and cost of supporting multiple adaptive formats for live and on-demand streams.

On the other hand, producers who go this route will have to factor in iDevice playback requirements and window sizes when creating their encoding configurations. As an example, most computer-targeted H.264 video files are produced using the Main or High Profile, which won’t play on pre-4G iPhone/iPod touch devices.

Customer Response
The final question pertained to the viewers’ responses to the availability of the adaptive streaming solution. To a degree, the streams watched by the viewers tend to speak for themselves. MTV couldn’t offer the 3.5Mbps stream that 19% of its viewers enjoyed unless there was a lower-quality stream available to serve to other users with slower connections and/or less powerful playback stations.

On the other hand, several respondents reported satisfaction at the other end of the spectrum as a key benefit to the use of adaptive streaming. For example, Harvard’s Bouthillier reported a substantial reduction in calls to the help desk because customers with poor connections could still retrieve and play one of its lower-quality streams without a problem. Indiana’s Gunkel reported similar benefits, relating one story where a grad student on a submarine could now watch his or her video live, where previously the school had to deliver DVDs to the student. Though adaptive streaming gets the most acclaim for enabling high-quality streams, don’t forget that it’s a boon at the low end as well.

Author’s note: I’d like to personally thank all respondents who graciously shared the fruits of their experience with me and with you. The process wasn’t a smooth one, as I asked lots of iterative questions over a protracted period, and I appreciate their time, attention, and patience.