The Player's the Thing...But So Is The Codec, Format, and Protocol
Both Inzerillo and Goldstein feel that HTTP delivers a higher-quality experience with faster stream switching and fewer playback interruptions when used with adaptive streaming technologies that distribute multiple bandwidth files to their viewers. This relates to the "chunking" used by Silverlight’s Smooth Streaming, as well as adaptive streaming technologies introduced by Apple and Akamai. Here’s a simplified explanation.
Assume that you were producing an event such as a baseball game. Traditionally, you would produce one stream to be delivered to all viewers. With adaptive bitrate technologies, you can create multiple streams in different configurations (MLB uses up to 10 different streams). With Adobe’s Dynamic Streaming, you would create a single file for each configuration. With Microsoft’s Smooth Streaming (and Apple’s and Akamai’s HTTP-based technologies), each configuration would be broken into multiple short chunks, which makes it easier for the respective players to nimbly switch streams on-the-fly.
MLB.com MLB.com uses Flash and HTTP via the Swarmcast plug-in.
MLB’s Inzerillo believes so heavily in HTTP delivery that he found a way to use it despite using Flash. Specifically, MLB transmits its games via HTTP using a Swarmcast plug-in that converts the HTTP data to an RTMP chunk that the Flash Player can understand. It’s an elegant solution that makes great sense in the context of MLB’s subscription service—although the developmental expense and the cost for Swarmcast may be out of reach for many nonsubscription websites.
Given all of these advantages, it’s no surprise that Apple adopted HTTP for its HTTP Live Streaming to iPhones technology, which was announced in June 2009. Akamai also tapped HTTP for its HD Network, which can deliver packets to the Flash Player via HTTP and deliver HTTP packets to Silverlight clients and to the iPhone. Given the momentum and mindshare enjoyed by HTTP in the streaming media marketplace, it came as no surprise in early October that Adobe announced support for HTTP with Flash Player 10.1, promising delivery during the first half of 2010.
Who Cares?OK, so the technology underpinning the world’s most dominant streaming technology is now considered second-rate. Does that mean that current Flash producers need to switch technologies en masse or hide in the closet until HTTP streaming from Adobe is available? Not quite. In the short term, HTTP packets aren’t cheaper to deliver; the quality of Flash video should be the equivalent of HTTP, so long as sufficient RTMP delivery capacity exists—and that capacity appears to be expanding, not contracting.
Regarding cost, HTTP’s ascension to the streaming protocol of choice hasn’t impacted CDN pricing yet; it may not impact pricing for a while. By way of background, when CDNs first started providing RTMP-based Flash distribution services, they charged more for the traffic because of the server costs I discussed previously. However, as Flash came to dominate the streaming marketplace, most CDNs eliminated the extra charge for RTMP-based streaming, or the so-called Flash Tax.
According to Ted Middleton, Level 3’s senior director of product management for content delivery, prices for HTTP-based streaming probably won’t drop in the short term. HTTP-based delivery isn’t burdened by server cost and administration; there are costs and complexities involved with transporting the myriad of chunked files. In addition, many HTTP producers also utilize adaptive streaming technologies, which involve more files to be cached, usually at higher data rates than single-file streaming. All of this makes it difficult to compute the actual savings enabled by HTTP streaming—although Level 3 and, presumably, other CDNs will continue to monitor this going forward.
What about HTTP’s cache-related savings? The ability for HTTP-based streaming technologies to utilize the web’s caching infrastructure should allow providers to serve the same number of viewers with less data delivered by the origin servers (which should lower CDN-related bandwidth costs), but this difference has never been quantified. So while HTTP-based technologies should be cheaper to deliver, no one can really say by how much. And because retention in the cache depends upon the popularity of the packet, only the highest volume streaming sites will see much benefit anyway—if you’re distributing a few hundred or even a few thousand streams a month, you’re likely to see little savings from caching.
In terms of quality, while favoring HTTP, Goldstein reports that MTV has had excellent results with Adobe’s Dynamic Streaming, delivered via RTMP, which MTV recently rolled out in North America. He attributes the consistent high quality to the extensive Flash Media Server (FMS) capacity available from his partner CDNs. Goldstein is concerned about quality in remote regions around the globe that may not have such extensive FMS capacity. But if you’re distributing in North America, quality shouldn’t be an issue, unless you require more capacity than MTV.
Is RTMP-based capacity going away? Not in the short term. For example, while embracing HTTP on one hand, Level 3 also recently merged Adobe Flash Media Server software into its own HTTP delivery technology to form a "single multi-protocol platform" (www. level3.com/index.cfm?pageID=491&PR=823). I spoke with Level 3’s Mark Taylor, VP of product delivery and strategy, about this at Streaming Media West. He explained that the technology extension allows Level 3’s entire HTTP delivery platform to also deliver RTMP.
Will 2022 be the year UDP finally shows its streaming mettle? The Quick UDP Internet Connections (QUIC) protocol might make the difference. First, though, OTT platforms need to make technical decisions about HTTP/3 that could further fragment the market.