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.
For the last decade, Apple has been selling QuickTime Streaming Server, which uses an RTSP (Real-Time Streaming Protocol) server to stream live or rebroadcast video feeds to viewers. Apple uses this technology to stream some of its own live events. However, despite offering royalty free streaming and also delivering it as an open source project, QuickTime’s RTSP streaming server hasn’t gained the traction it was once expected to achieve. A large part of this is due to the fact that RTSP traffic is blocked by many firewalls, making it difficult to deliver streams reliably. The audio and video conferencing used by iChat also relies on RTSP, causing some users frustrating problems for the same reason. Getting RTSP video streaming to work on the iPhone would be even more difficult, as it routinely moves between mobile and WiFi networks.
Apple’s HTTP Live Streaming proposed draft looks a lot like a method Microsoft began selling last year, called Smooth Streaming. The difference is that Apple’s proposed IETF standard can use anybody’s encoder and broadcast server, and will work with any client software designed to receive the stream. In contrast, Microsoft’s Smooth Streaming is of course designed to exclusively use Microsoft Expression Encoder, Microsoft Internet Information Server with a Smooth Streaming extension, and requires Microsoft’s Silverlight 2 on the client.
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.
Learn more about iPhone HTTP Streaming segments. Stop by Ankoder site where you can find out all about Online Video Encoding and what it can do for you.
Tags: encoding, ffmpeg, ffmpeg iphone, ffmpeg segment, http streaming, iphone, iphone video, iphone video streaming, streaming, transcode, video, video encoder, video encoding, Video Streaming, video transcoder
