The Player's the Thing...But So Is The Codec, Format, and Protocol

In the beginning, streaming technologies such as Real Media, Windows Media, and QuickTime used the Real Time Streaming Protocol (RTSP) to communicate between servers and players, to provide features such as multiple bitrate files, and to more efficiently distribute bulky video files to multiple players. Adobe modified RTSP to create the Real Time Messaging Protocol (RTMP), which provided many of the same functions.

 At some point in 2008, however, RTMP and RTSP became four-letter words in the streaming video space. This distaste for RTMP and RTSP coincided with a push for distribution via HTTP, which was simpler for content delivery networks (CDNs) to incorporate, more firewall-friendly, and more cache-efficient. Suddenly, the evaluation of a streaming video technology factored in not only player and codec-related functionality but also the available transport protocols.

In this regard, HTTP re-emerged as the "it" protocol for large event streaming, with high-profile proponent Microsoft benefiting from Apple’s HTTP Live Streaming announcement and Adobe’s end of the year capitulation to HTTP.

Microsoft has also made some headway in the Flash/Silverlight war with some high-profile design-ins and live event successes, but the installed base remains well below 50%. In the codec market, H.264 continued to gain steam in the Flash and the iPhone and iPod touch markets—the midyear launch of Silverlight 3 with H.264 playback compatibility positioned the standard-based codec for widespread use in the Silverlight market.

Still, Google’s acquisition of On2 may give VP8 the muscle to make waves in the codec market, particularly if Google donates it royalty-free for use with HTML5. At the very least, it will tighten the sphincters of the H.264 patent group a bit and make its members a little less confident about the power of their H.264 monopoly, particularly if Google flipped a switch and converted YouTube’s 59% share of all internet streams from Spark/VP6/H.264 to VP8. Though it’s unlikely that VP8 will be an H.264 killer (or even chiller), it’s a whole lot more likely than it was before Google bought On2.

Finally, the use of multiple bitrate, adaptive streaming technologies was one of the strongest trends of 2009—Move Networks, Silverlight, Apple, and Adobe own and promote competing technologies. 2010 could be the year that H.264 Scalable Video Coding comes to the market with some clear technology advantages and the inherent power of a standards-based technology.

This article discusses all of these issues. And for a well-rounded perspective on them, I spoke with multiple representatives from content owners/ streamers, CDNs, and online video providers (OVP).

Protocols
The year started with Move Networks and Microsoft promoting HTTP as the optimal protocol for large event streaming and Adobe resolutely standing by RTMP. By the end of 2009, Move, Microsoft, Apple, Akamai, and Adobe were all squarely in the HTTP camp, though Adobe’s implementation may not appear until June 2010. While this represents a technological sea change, the implications of the shift for most users will be nominal, at least in the short term. More on that later.

Let’s start with a brief technology description. HTTP is the generic protocol used to deliver data from a web server, whether the data is text, JPEG images, PDF files, or video. RTSP is the industry-standard streaming protocol supported by most streaming servers, including Apple’s QuickTime Streaming Server and Microsoft’s Windows Media Services; and RTMP is the proprietary protocol developed by Adobe for Flash. Though you can deliver to the Silverlight player via RTSP and multicast, most large-scale Silverlight events deliver via HTTP.

HTTP has several well-known advantages over protocols like RTSP and RTMP. First, some firewalls block RTSP/RTMP packets, which is a problem for viewers behind a firewall. Second, RTSP/RTMP-based technologies typically require a streaming server to communicate with the player, whereas HTTP-based technologies don’t. This server requirement means that RTSP/RTMP-based technologies are more expensive to implement and maintain; there’s also inherently less RTSP/RTMP capacity than HTTP capacity.

Content delivery networks and other large-scale web delivery platforms are designed and created to deliver HTTP content because that type of content makes up the bulk of the data delivered over the internet. To deliver RTSP or RTMP packets, these organizations must install a streaming server that gives that server the ability to deliver these packets. In contrast, with HTTP-based streaming technologies, the entire HTTP-compatible infrastructure can deliver these packets, which typically means a far greater capacity, or "footprint," for HTTP than RTSP/RTMP.

Third, HTTP data is more cache-friendly than RTMP, which should translate to fewer streams delivered to satisfy the same number of viewers and a better quality of service to viewers retrieving data from the cache. For example, a viewer on a corporate LAN or watching via an ISP would retrieve the complete video from the origin server, which would be stored on the corporation’s or ISP’s cache server. Subsequent requests for the same data would be satisfied from the cache, so the producer doesn’t have to pay the CDN to send the streams again. Since the data is served locally, for all intents and purposes, the subsequent viewers should also have a better viewing experience.

The other advantage of HTTP relates to the quality of stream switching available using HTTP instead of RTSP. For example, I spoke with Joe Inzerillo, senior VP of multimedia and distribution at MLB.com. Inzerillo oversees the streaming of every regular season, postseason, and a few preseason baseball games on the MLB site. I also spoke with Glenn Goldstein, vice president of video technology strategy at MTV Networks, which pushes out more than 400 million streams per month to more than 13 million unique viewers.