Apple announced the new features of the iPhone OS 3.0, that the iPhone would be capable of streaming video and audio directly over HTTP. Apple also advertised HTTP streaming as a feature of QuickTime X, the update of its media architecture coming in Snow Leopard. What it failed to explain, at least publicly, is how this streaming would be accomplished. Fortunately, Apple submitted its proposed protocol last month to the Internet Engineering Task Force (IETF) in the hopes that it will become a ubiquitous standard.

The Real Time Streaming Protocol originally developed by Netscape and Real in the late ’90s. The biggest issue with RTSP is that the protocol or its necessary ports may be blocked by routers or firewall settings, preventing a device from accessing the stream. As the standard protocol for the Web, though, HTTP is generally accessible. Furthermore, no special server is required other than a standard HTTP server, which is more widely supported in content distribution networks, and more expertise in optimizing HTTP delivery is generally available than for RTSP.

Enter HTTP Live Streaming. The basic mechanics involve using software on the server to break an MPEG-2 transport stream into small chunks saved as separate files, and an extension to the .m3u playlist specification (.m3u8) to tell the client where to get the files that make up the complete stream. The media player client merely downloads and plays the small chunks in the order specified in the playlist, and in the case of a live stream, periodically refreshes the playlist to see if there have been any new chunks added to the stream.

Apple attempted to solve the RTSP problem long ago in QuickTime Streaming Server by creating an option to bundle up RTSP streaming video traffic into HTTP packets, which appear identical to standard web traffic and therefore are permitted through most firewalls. This involves a extra layer of overhead however, resulting in a greater demand for bandwidth. For the iPhone, Apple decided to pursue a different strategy, which it calls HTTP Live Streaming.

The real benefit to HTTP Live Streaming is that the server can maintain multiple versions of the clips in different formats. This allows an iPhone user with a WiFi connection to negotiate a higher quality version of the video than if only EDGE were available. Even better, the phone can renegotiate a higher or lower quality dynamically if it improves or loses signal. This enables the watcher to experience the best video quality possible at the current bandwidth available, continually optimized as new segments are requested. Unlike Microsoft’s Smooth Streaming trojan horse for Silverlight, HTTP Live Streaming works with any playback client on any platform and does not involve a layer of DRM, although it does support encryption, allowing broadcasters to limit access to their content. Because support is built directly into the iPhone’s embedded QuickTime player, users don’t even need to download apps for every broadcaster or channel; content creators can simply publish their feeds within a standard website, and iPhone can access them just like a desktop client. Other phones can similarly support the same interoperable standard, providing a leg up for mobile platforms with less commercial attraction or no ability to run real applications, like the Palm Pre.

For examples of iPhone HTTP Streaming segments, see Ankoder – Online Video Encoding. Viewing live streams requires iPhone 3.0 or Snow Leopard QuickTime X.

Stumble it!