Video Info

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.

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.

This is in contrast to real-time streaming, as there would necessarily be a minimum latency of whatever duration the server slices the stream into (Apple refers to 10 seconds as an example). As the server encodes the video and slices it into 10 second clips, for instance, it creates or updates a playlist for the stream with the URL of the next clip. The client begins by downloading one or more of the clips, playing them in order. As one clip plays, the client begins downloading the next specified clip until it reaches a tag in the playlist that signals the end of the stream.

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.

Looking to find the best tool for Ankoder – Online Video Encoding, then visit www.ankoder.com for a tutorial on iPhone HTTP Streaming segments.

Tags: encoding, ffmpeg, ffmpeg iphone, ffmpeg segment, http streaming, iPhone, iphone video, iphone video streaming, streaming, transcode, Video, video encoder, video encoding, video transcoder