Streaming to the Apple iPhone, Part 1
Figure 1. The playoffs were a real hit on the Apple iPhone, with 10 percent of viewers watching on that platform.
A funny thing happened on the way to the World Series this year. Specifically, in the first round of the playoffs, Major League Baseball Advanced Media served an average of 350,000 streams per game, with 36,000 streamed to the Apple iPhone. At $10 a shot, that's a noticeable number. Not surprisingly, the NBA is also offering live games to the iPhone for the 2009-2010 season.
In terms of the iPhone market as whole, in April 2009, Nielsen estimated that there were 6.4 million active iPhone users in the United States, up from 2.1 million a year prior. According to the survey, 37 percent of iPhone users watch video on their phone, which is six times more than the typical cellular subscriber.
Whether you're a B2B or B2C operation, if distributing streaming media is mission-critical to your organization, streaming to the iPhone needs to be on your radar screen. In this edition of Final Cut Pro Insider, I'll provide a technology overview of streaming to the iPhone and your implementation options. In the next issue, I'll pull together some case studies for iPhone usage large and small to help illustrate how streaming to the iPhone could be useful to you.
Figure 2. Architecture overview from the Akamai white paper "Akamai HD for iPhone Encoding Best Practices."
Why the fuss?
Let's take a step back. Video on the iPhone isn't new, but at the Worldwide Developers Conference in June 2009, Apple introduced a new technology called HTTP Live Streaming. It's important for many reasons at multiple levels.
First, it lets potential video producers and distributors access the iPhone without creating a special branded application; instead, videos play directly in the Safari browser. Transmissions can occur via wireless or Wi-Fi, with seamless switching between the two in midstream.
| Related Links |
||||||
|
Delivery via HTTP makes it cheaper to distribute the video streams, since no special server is required to stream the data to the client—any old web server will do. Data transmitted via HTTP can also be stored in cache servers located in the premises of Internet service providers, cellular providers, and other organizations, which should improve video quality for viewers served from these caches. HTTP content is also firewall-friendly, an issue for those watching behind tightly controlled firewalls.
In addition, HTTP and the segmenting techniques deployed by Apple make it easier to implement adaptive-bit-rate streaming, which distributes multiple files to the iPhone to optimize quality at any connection speed. As an example, if you were connecting indoors via Wi-Fi, you might receive the highest-quality stream. Walk outside, and the connection would shift to cellular, and the iPhone will likely transition to a lower-quality, lower-bandwidth stream, but playback should continue without interruption.
On another level, Apple's selection of HTTP provided a compelling technology endorsement for Microsoft's HTTP-based Smooth Streaming (talk about strange bedfellows). This pretty much forced Adobe to implement HTTP-based streaming, announced in October 2009, in addition to its current RTMP-based technology.
To summarize, HTTP Live Streaming is cheaper to implement and distribute, offers higher quality than previous techniques, and helped consolidate the streaming video market around a single transmission standard. To be fair, the significance of this announcement was more about the announcer and the iPhone platform than the technology itself.
Adaptive-bit-rate streaming has been around since the last century, and Apple's implementation is very similar to Smooth Streaming (which is similar to Move Networks' Move Adaptive Stream). In addition, on the desktop, you can currently play back Apple's HTTP Live Streaming video only via QuickTime X, which is available only with Mac OS X Snow Leopard, and not at all on Windows.
So HTTP Live Streaming isn't an Adobe Flash or Microsoft Silverlight killer. On the other hand, Apple did release the specification as a proposed Internet Engineering Task Force (IETF) standard that should work with any player designed to play the stream (see a draft here). And as mentioned before, the iPhone/iPod touch platform, in itself, is big enough to put streaming to these devices on the short-term technology agenda for all but the most casual streamers.
Figure 3. Inlet Technologies' Spinnaker rackmount encoder, one of the two hardware encoders tested by Apple. From a presentation available here.
How does it work?
There's an old joke about how many [insert target group here]s does it take to change a light bulb? The answer, of course, is two: one to call the electrician, another to mix the daiquiris.
Yeah, I know, old and not funny. The point is that you don't have to pull the pieces together yourself to make it work; you can call your friendly content-delivery network (CDN) or online video platform (OVP) provider, write a check, and get started right away—which is easier, cheaper, and faster than rolling your own system. Still, it always helps to know a little bit about the plumbing, so here's a buzzword-level description. There won't be a pop quiz, but feel free to pay attention anyway.
First, HTTP Live Streaming works with both live and on-demand feeds. As mentioned, the iPhone can receive the stream via Wi-Fi or wireless, and can switch back and forth while playing back a single video. Though adaptive bit rate is used by many producers who distribute to the iPhone, you can distribute single-data-rate video files.
While HTTP Live Streaming is technically codec-agnostic, the current implementation requires H.264 video encoded using the Baseline profile Level 3 and HE-AAC or AAC-LC audio up to 48kHz stereo, muxed as an MPEG-2 transport stream that has a .ts extension. You can also stream an audio-only .mp3 file. Though any encoder capable of producing files to the specification should work, Apple has tested compatibility with only two hardware encoders: Inlet Technologies' Spinnaker 7000 and Envivio's 4Caster C4.
Figure 4. An index file example. Remove the technical gobbledygook, and it's a list of files and their location. For more details see the Apple white paper "HTTP Live Streaming Overview."
The .M3U8 index file
After encoding, a free stream segmenter (see Figure 2) available from Apple divides the encoded file into separate files of equal duration, usually 10 seconds, all with .ts extensions. The segmenter also creates an index file that contains a list of the media file segments and their location (see Figure 4). Index files have a .M3U8 extension, and they serve as the glue between the player and the segmented files.
During playback, the player downloads the index file first, then downloads and plays the media files in sequence. After playing segment1.ts, for example, the player can check the index file, see that segment2.ts is next, and determine its location.
In a live scenario, the index file is continually updated and downloaded by the player, so the player always knows which segments to retrieve and from where. If you leave references to all segments in the index file, latecomers can use the file to view the stream and catch up to current playback. If desired, this index file can also be used for immediate on-demand playback after the end of the live event.
Figure 5. With adaptive-bit-rate streaming, a master index file points to alternative index files for each stream.
For more details see the Apple white paper "HTTP Live Streaming Overview"
Implementing adaptive-bit-rate streaming
For adaptive-bit-rate streaming of multiple files, the segmenter creates alternative index files for each stream, with one master index file pointing to the alternates. Apple doesn't detail the heuristic data that dictates how and when the iPhone switches streams, but these technologies typically monitor factors such as buffer levels, replenishment times, and CPU load.
When these factors dictate a switch, the player simply retrieves the appropriate segment from the alternate stream and plays it next. From the player's perspective, this is really no different than retrieving and playing a chunk from the stream it was playing, so switching between streams should be seamless.
Figure 6. When switching streams, the player just chooses the next sequential chunk from a different stream.
Image courtesy Inlet Technologies
When distributing multiple streams, you must encode them uniformly to enable seamless switching. All segments should be the same size (Apple recommends 10-second segments), and keyframe settings should be uniform within the chunks and an even divisor of the segment length (2 seconds or 5 seconds in a 10-second segment). Apple also recommends that the audio stream be exactly the same in all streams to ensure seamless playback.
Just as an example, in its HTTP Live Streaming white paper, Apple recommended this configuration for alternative streams:
- Low: 96kbps video, 64kbps audio
- Medium: 256kbps video, 64kbps audio
- High: 800kbps video, 64kbps audio.
Failover and encryption
Apple's HTTP Live Streaming supports three modes of encryption so publishers can protect their content. In addition, publishers can implement "failover protection" by producing redundant parallel streams transmitted from different servers and including this information in the index file. If the player can't retrieve a stream from the first server on the list, it will look for the content on the fallback server listed in the index file.
Implementing HTTP Live Streaming
As mentioned, if your company is large enough, you can buy your own rackmounted encoders, generate your streams internally, and send them off to Akamai or another CDN for mass-market delivery. If you belong to a smaller organization looking for more of a turnkey service, find an online video platform provider that streams to the iPhone. Two providers that come immediately to mind are Brightcove and Multicast Media Technologies.
That's the overview. Back in two weeks with some compelling case studies.
Middle Ad
CPN Newsletter
FREE eNewsletter
Subscribe to our FREE eNewsletter
Subscribe to our FREE eNewsletter
Middle1 Ad
print edition
