Detailed instructions for use are in the User's Guide.
HTTP Live Streaming Overview
2009-09-09
Apple Inc. © 2009 Apple Inc. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, mechanical, electronic, photocopying, recording, or otherwise, without prior written permission of Apple Inc., with the following exceptions: Any person is hereby authorized to store documentation on a single computer for personal use only and to print copies of documentation for personal use provided that the documentation contains Apple's copyright notice. The Apple logo is a trademark of Apple Inc. Use of the "keyboard" Apple logo (Option-Shift-K) for commercial purposes without the prior written consent of Apple may constitute trademark infringement and unfair competition in violation of federal and state laws. No licenses, express or implied, are granted with respect to any of the technology described in this document. Apple retains all intellectual property rights associated with the technology described in this document. This document is intended to assist application developers to develop applications only for Apple-labeled computers. Every effort has been made to ensure that the information in this document is accurate. Apple is not responsible for typographical errors. Apple Inc. 1 Infinite Loop Cupertino, CA 95014 408-996-1010 Apple, the Apple logo, iPod, Leopard, Mac, QuickTime, Safari, and WebObjects are trademarks of Apple Inc., registered in the United States and other countries. iPhone and Snow Leopard are trademarks of Apple Inc. Intel and Intel Core are registered trademarks of Intel Corportation or its subsidiaries in the United States and other countries. Simultaneously published in the United States and Canada.
Even though Apple has reviewed this document, APPLE MAKES NO WARRANTY OR REPRESENTATION, EITHER EXPRESS OR IMPLIED, WITH RESPECT TO THIS DOCUMENT, ITS QUALITY, ACCURACY,
MERCHANTABILITY, OR FITNESS FOR A PARTICULAR PURPOSE. AS A RESULT, THIS DOCUMENT IS PROVIDED "AS IS," AND YOU, THE READER, ARE ASSUMING THE ENTIRE RISK AS TO ITS QUALITY AND ACCURACY. IN NO EVENT WILL APPLE BE LIABLE FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES RESULTING FROM ANY DEFECT OR INACCURACY IN THIS DOCUMENT, even if advised of the possibility of such damages. THE WARRANTY AND REMEDIES SET FORTH ABOVE ARE EXCLUSIVE AND IN LIEU OF ALL OTHERS, ORAL OR WRITTEN, EXPRESS OR IMPLIED. No Apple dealer, agent, or employee is authorized to make any modification, extension, or addition to this warranty. Some states do not allow the exclusion or limitation of implied warranties or liability for incidental or consequential damages, so the above limitation or exclusion may not apply to you. This warranty gives you specific legal rights, and you may also have other rights which vary from state to state.
Contents
Introduction
Introduction 7
Organization of This Document 7 See Also 7
Chapter 1
HTTP Streaming Architecture 9
Overview 9 Server Components 10 Media Encoder 11 Stream Segmenter 11 Media Segment Files 12 Distribution Components 12 Client Component 12
Chapter 2
Using HTTP Live Streaming 13
Session Types 13 Content Protection 13 Caching and Delivery Protocols 14 Stream Alternates 14 Failover Protection 15 Sample Streams 16
Chapter 3
Frequently Asked Questions 17 Document Revision History 21
3
2009-09-09 | © 2009 Apple Inc. All Rights Reserved.
CONTENTS
4
2009-09-09 | © 2009 Apple Inc. All Rights Reserved.
Figures
Chapter 1
HTTP Streaming Architecture 9
Figure 1-1 A basic configuration 10
Chapter 2
Using HTTP Live Streaming 13
Figure 2-1 Stream alternates 15
5
2009-09-09 | © 2009 Apple Inc. All Rights Reserved.
FIGURES
6
2009-09-09 | © 2009 Apple Inc. All Rights Reserved.
INTRODUCTION
Introduction
HTTP Live Streaming allows you to send live or prerecorded audio and video to iPhone or other devices, such as desktop computers, using an ordinary Web server. Playback requires iPhone OS 3.0 or later on iPhone or iPod touch; QuickTime X or later is required on the desktop. Support is included for both encryption and authentication. The HTTP Live Streaming specification is an IETF Internet-Draft. If you are interested in streaming live events to iPhone, streaming live events without special server software, or in sending video on demand with encryption and authentication, you should read this document. Note: This document was formerly tltled "iPhone Streaming Media Guide for Web Developers."
Organization of This Document
This document contains three chapters:
"HTTP Streaming Architecture" (page 9)--how the technology works, what formats are supported, what you need on the server, and what clients are available. "Using HTTP Live Streaming" (page 13)--how to set up live broadcast or video on demand sessions, how to implement encryption and authentication, and how to set up alternate bandwidth streams. Links to sample streams are included. "Frequently Asked Questions" (page 17)--common questions about HTTP Live Streaming, and their answers: format details, tips, where to go for support, and so on.
See Also
Safari Web Content Guide--how to design web content for iPhone. HTTP Live Streaming protocol--the IETF Internet-Draft of the HTTP Live Streaming specification.
Organization of This Document
2009-09-09 | © 2009 Apple Inc. All Rights Reserved.
7
INTRODUCTION
Introduction
8
See Also
2009-09-09 | © 2009 Apple Inc. All Rights Reserved.
CHAPTER 1
HTTP Streaming Architecture
Starting with iPhone OS version 3.0 and QuickTime X, you can send streaming audio and video over HTTP from an ordinary web server for playback on iPhone, iPod touch, or other devices, such as desktop computers. This is called HTTP Live Streaming. Because it uses HTTP, this kind of streaming is automatically supported by nearly all edge servers, media distributors, caching systems, routers, and firewalls. HTTP Live Streaming also provides for media encryption and user authentication over HTTPS, allowing publishers to protect their work. Note: Many existing streaming services require specialized servers to distribute content to end users. These servers require specialized skills to set up and maintain, and in a large-scale deployment this can be costly. HTTP Live Streaming avoids this by using standard HTTP to deliver the media. Additionally, HTTP Live Streaming is designed to work seamlessly in conjunction with media distribution networks for large scale operations.
Overview
Conceptually, HTTP Live Streaming consists of three parts: the server component, the distribution component, and the client software. The server component is responsible for taking input streams of media and encoding them digitally, encapsulating them in a format suitable for delivery, and preparing the encapsulated media for distribution. The distribution component consists of standard web servers. They are responsible for accepting client requests and delivering prepared media and associated resources to the client. For large-scale distribution, edge networks or other content delivery networks can also be used. The client software is responsible for determining the appropriate media to request, downloading those resources, and then reassembling them so that the media can be presented to the user in a continuous stream. iPhone includes built-in client software: the media player, which is automatically launched when Safari encounters an or tag with a URL whose MIME type is one that the media player supports. The media player can also be launched from custom iPhone applications using the media player framework. QuickTime X can also play HTTP Live Streams, enabling playback on the desktop. Developers can use the QuickTime framework to create desktop applications that play HTTP Live Streams. The QuickTime plug-in allows you to embedded streams in websites for playback through a browser without writing any application code. In a typical configuration, a hardware encoder takes audio-video input and turns it into an MPEG-2 Transport Stream, which is then broken into a series of short media files by a software stream segmenter. These files are placed on a web server.
Overview
2009-09-09 | © 2009 Apple Inc. All Rights Reserved.
9
CHAPTER 1
HTTP Streaming Architecture
The segmenter also creates and maintains an index file containing a list of the media files. The URL of the index file is published on the web server. Client software reads the index, then requests the listed media files in order and displays them without any pauses or gaps between segments. An example of a simple HTTP streaming configuration is shown in "A basic configuration." Figure 1-1 A basic configuration
Server media encoder stream segmenter Distribution origin web server
Index file
MPEG-2 transport stream
.ts
Audio/Video inputs
HTTP
Client
Input can be live or from a prerecorded source. It is typically encoded into an MPEG-2 Transport Stream by off-the-shelf hardware. The MPEG2 stream is then broken into segments and saved as a series of one or more .ts media files. This is typically accomplished using a software tool such as the Apple stream segmenter. Audio-only streams can be a series of MPEG elementary audio files formatted as either AAC with ADTS headers or MP3. The segmenter also creates an index file. The index file contains a list of media files. The index file also contains metadata. The index file is in .M3U8 format. The URL of the index file is accessed by clients, which then request the indexed files in sequence.
Server Components
The server requires a media encoder, which can be off-the-shelf hardware, and a way to break the encoded media into segments and save them as files, which can be software such as the media stream segmenter provided by Apple (available in beta for download from the Apple Developer Connection member download site at https://connect.apple.com/cgi-bin/WebObjects/MemberSite.woa/wa/getSoftware?bundleID=20333).
10
Server Components
2009-09-09 | © 2009 Apple Inc. All Rights Reserved.
CHAPTER 1
HTTP Streaming Architecture
Media Encoder
The media encoder takes a real-time signal from an audio-video device, encodes the media, and encapsulates it for delivery. Currently, the supported format is MPEG-2 Transport Streams for audio-video, or MPEG elementary streams for audio. The encoder delivers an MPEG-2 Transport Stream over the local network to the stream segmenter. Note: The protocol specification is capable of accommodating other formats, but only MPEG-2 video streams (with H.264 video and AAC audio) or MPEG elementary audio streams (in AAC format with HTDS headers or in MP3 format) are supported at this time.
Important: The video encoder should not change stream settings--such as video dimensions or codec type--in the midst of encoding a stream.
Stream Segmenter
The stream segmenter is a process--typically software--that reads the Transport Stream from the local network and divides it into a series of small media files of equal duration. Even though each segment is in a separate file, video files are made from a continuous stream which can be reconstructed seamlessly. The segmenter also creates an index file containing references to the individual media files. Each time the segmenter completes a new media file, the index file is updated. The index is used to track the availability and location of the media files. The segmenter may also encrypt each media segment and create a key file as part of the process. Media segments are saved as .ts files (MPEG-2 streams) and index files are saved as .M3U8 files, an extension of the .m3u format used for MP3 playlists. Note: Because the index file format is an extension of the .m3u file format, and because the system also supports .mp3 audio media files, the client software may also be compatible with typical MP3 playlists used for streaming Internet radio. Here is a very simple example of an .M3U8 file a segmenter might produce if the entire stream were contained in three unencrypted 10-second media files:
#EXTM3U #EXT-X-MEDIA-SEQUENCE:0 #EXT-X-TARGETDURATION:10 #EXTINF:10, http://media.example.com/segment1.ts #EXTINF:10, http://media.example.com/segment2.ts #EXTINF:10, http://media.example.com/segment3.ts #EXT-X-ENDLIST
The index file may also contain URLs for encryption key files or alternate index files for different bandwidths. For details of the index file format, see the IETF Internet-Draft of the HTTP Live Streaming specification.
Server Components
2009-09-09 | © 2009 Apple Inc. All Rights Reserved.
11
CHAPTER 1
HTTP Streaming Architecture
Media Segment Files
The media segment files are normally produced by the stream segmenter, based on input from the encoder, and consist of a series of .ts files containing segments of an MPEG-2 Transport Stream. For an audio-only broadcast, the segmenter can produce MPEG elementary audio streams containing either AAC audio with ADTS headers or MP3 audio. Alternatively, it is possible to create the .M3U8 file and the media segment files independently, provided they conform the published specification. For audio-only broadcasts, for example, you could create an .M38U file using a text editor, listing a series of existing .MP3 files.
Distribution Components
The distribution system is a web server or a web caching system that delivers the media files and index files to the client over HTTP. No custom server modules are required to deliver the content, and typically very little configuration is needed on the web server. Recommended configuration is typically limited to specifying MIME-type associations for .M3U8 files and .ts files. File extension MIME type
.M3U8
application/x-mpegURL video/MP2T
.ts
Tuning time-to-live (TTL) values for .M3U8 files may also be necessary to achieve desired caching behavior for downstream web caches, as these files are frequently overwritten, and the latest version should be downloaded for each request.
Client Component
The client software begins by fetching the index file, based on a URL identifying the stream. The index file in turn specifies the location of the available media files, decryption keys, and any alternate streams available. For the selected stream, the client downloads each available media file in sequence. Each file contains a consecutive segment of the stream. Once it has a sufficient amount of data downloaded, the client begins presenting the reassembled stream to the user. The client is responsible for fetching any decryption keys, authenticating or presenting a user interface to allow authentication, and decrypting media files as needed. This process continues until the client encounters the #EXT-X-ENDLIST tag in the index file. If no #EXT-X-ENDLIST tag is encountered, the index file is part of an ongoing broadcast. The client loads a new version of the index file periodically. The client looks for new media files and encryption keys in the updated index and adds these URLs to its queue.
12
Media Segment Files
2009-09-09 | © 2009 Apple Inc. All Rights Reserved.
CHAPTER 2
Using HTTP Live Streaming
Session Types
The HTTP Live Streaming protocol supports live broadcast sessions and video on demand (VOD) sessions. For live sessions, as new media files are created and made available the index file is updated. The new index file includes the new media files; older files are typically removed. The updated index file presents a moving window into a continuous stream. This type of session is suitable for continuous broadcasts. For VOD sessions, media files are available representing the entire duration of the presentation. The index file is static and contains a complete list of all files created since the beginning of the presentation. This kind of session allows the client full access to the entire program. It is possible to create a live broadcast of an event that is instantly available for video on demand. To convert a live broadcast to VOD, do not remove the old media files from the server or delete their URLs from the index file, and add an #EXT-X-ENDLIST tag to the index when the broadcast ends. This allows clients to join the broadcast late and still see the entire event. It also allows an event to be archived for rebroadcast with no additional time or effort. VOD can also be used to deliver "canned" media. It is typically more efficient to deliver such media as a single QuickTime movie or MPEG-4 file, but HTTP Live Streaming offers some advantages, such as support for media encryption and dynamic switching between streams of different data rates in response to changing connection speeds. (QuickTime also supports multiple-data-rate movies using progressive download, but QuickTime movies do not support dynamically switching between data rates in mid-movie.)
Content Protection
Media files containing stream segments may be individually encrypted. When encryption is employed, references to the corresponding key files appear in the index file so that the client can retrieve the keys for decryption. When a key file is listed in the index file, the key file contains a cipher key that must be used to decrypt subsequent media files listed in the index file. Currently HTTP Live Streaming supports AES-128 encryption using 16-octet keys. The format of the key file is a packed array of these 16 octets in binary format. The media stream segmenter available from Apple provides encryption and supports three modes for configuring encryption. The first mode allows you to specify a path to an existing key file on disk. In this mode the segmenter inserts the URL of the existing key file in the index file. It encrypts all media files using this key. The second mode instructs the segmenter to generate a random key file, save it in a specified location, and reference it in the index file. All media files are encrypted using this randomly generated key.
Session Types
2009-09-09 | © 2009 Apple Inc. All Rights Reserved.
13
CHAPTER 2
Using HTTP Live Streaming
The third mode instructs the segmenter to generate a random key file, save it in a specified location, reference it in the index file, and then regenerate and reference a new key file every n files. This mode is referred to as key rotation. Each group of n files is encrypted using a different key. Note: All media files may be encrypted using the same key, or new keys may be required at intervals. The theoretical limit is one key per media file, but because each media key adds a file request and transfer to the overhead for presenting the following media segments, changing to a new key periodically is less likely to impact system performance than changing keys for each segment. You can serve key files using either HTTP or HTTPS. You may also choose to protect the delivery of the key files using your own session-based authentication scheme.
Caching and Delivery Protocols
HTTPS is commonly used to deliver key files. It may also be used to deliver the content files and index files, but this is not recommended when scalability is important, since HTTPS requests often bypass web server caches, causing all content requests to be routed through your server and defeating the purpose of edge network distribution systems. For this very reason, however, it is important to make sure that any content delivery network you use understands that the .M3U8 index files are not to be cached for longer than one media segment duration.
Stream Alternates
Index files may reference alternate streams of content. References can be used to support delivery of multiple streams of the same content with varying quality levels for different bandwidths or devices. The client software uses heuristics to determine appropriate times to switch between the alternates. Currently, these heuristics are based on recent trends in measured network throughput. The index file points to alternate streams of media by including a specially tagged list of other index files, as illustrated in xName-No-Link
14
Caching and Delivery Protocols
2009-09-09 | © 2009 Apple Inc. All Rights Reserved.
CHAPTER 2
Using HTTP Live Streaming
Figure 2-1
Stream alternates
Alternate-A Index file
.ts
Index file
Alternate-B Index file
.ts
Alternate-C Index file
.ts
Note that the client may choose to change to an alternate stream at any time, such as when a mobile device enters or leaves a WiFi hotspot.
Failover Protection
If your playlist contains alternate streams, they can not only operate as bandwidth or device alternates, but as failure fallbacks. Starting with iPhone OS 3.1, if the client is unable to reload the index file for a stream (due to a 404 error, for example), the client attempts to switch to an alternate stream. In the event of an index load failure on one stream, the client chooses the highest bandwidth alternate stream that the network connection supports. If there are multiple alternates at the same bandwidth, the client chooses among them in the order listed in the playlist. You can use this feature to provide redundant streams that will allow media to reach clients even in the event of severe local failures, such as a server crashing or a content distributor node going down. To implement failover protection, create a stream, or multiple alternate bandwidth streams, and generate a playlist file as you normally would. Then create a parallel stream, or set of streams, on a separate server or content distribution service. Add the list of backup streams to the playlist file, so that the backup stream at each bandwidth is listed after the primary stream. For example, if the primary stream comes from server ALPHA, and the backup stream is on server BETA, your playlist file might look something like this:
#EXTM3U #EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=200000 http://ALPHA.mycompany.com/lo/prog_index.m3u8 #EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=200000 http://BETA.mycompany.com/lo/prog_index.m3u8 #EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=500000 http://ALPHA.mycompany.com/md/prog_index.m3u8 #EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=500000 http://BETA.mycompany.com/md/prog_index.m3u8
Failover Protection
2009-09-09 | © 2009 Apple Inc. All Rights Reserved.
15
CHAPTER 2
Using HTTP Live Streaming
Note that the backup streams are intermixed with the primary streams in the playlist, with the backup at each bandwidth listed after the primary for that bandwidth. You are not limited to a single backup stream set. In the example above, ALPHA and BETA could be followed by GAMMA, for instance. Similarly, you need not provide a complete parallel set of streams. You could provide a single low-bandwidth stream on a backup server, for example.
Sample Streams
There are a series of HTTP streams available for testing on Apple's developer site. These examples show proper formatting of HTML to embed streams, .M3U8 files to index the streams, and .ts media segment files. The streams can be accessed at the following URLs:
http://devimages.apple.com/iphone/samples/bipbopall.html http://devimages.apple.com/iphone/samples/bipbopgear1.html http://devimages.apple.com/iphone/samples/bipbopgear2.html http://devimages.apple.com/iphone/samples/bipbopgea3.html http://devimages.apple.com/iphone/samples/bipbopgear4.html
You must install iPhone OS version 3.0 or later in order to play these samples on your iPhone.
16
Sample Streams
2009-09-09 | © 2009 Apple Inc. All Rights Reserved.
CHAPTER 3
Frequently Asked Questions
1.
What kinds of encoders are supported? The protocol specification does not limit the encoder selection. However, the current Apple implementation should interoperate with encoders that produce MPEG-2 Transport Streams containing H.264 video and AAC audio (HE-AAC or AAC-LC). Encoders that are capable of broadcasting the output stream over UDP should also be compatible with the current implementation of the Apple provided segmenter software. Apple has tested the current implementation with the following commercial encoders:
Inlet Technologies Spinnaker 7000 Envivio 4Caster C4
2.
What are the specifics of the video and audio formats supported? Although the protocol specification does not limit the video and audio formats, the current Apple implementation supports the following formats:
Video: H.264 Baseline Level 3.0 Audio:
HE-AAC or AAC-LC up to 48 kHz, stereo audio MP3 (MPEG-1 Audio Layer 3) 8 kHz to 48 kHz, stereo audio
3.
What duration should media files be? The main point to consider is that shorter segments result in more frequent refreshes of the index file, which might create unnecessary network overhead for the client. Longer segments will extend the inherent latency of the broadcast and initial startup time. A duration of 10 seconds of media per file seems to strike a reasonable balance for most broadcast content.
4.
How many files should be in listed in the index file during a continuous, ongoing session? The client identifies an ongoing session by the lack of an #EXT-X-ENDLIST tag in the index file. The client does not allow the user to seek into the last two files in the index for ongoing broadcasts. When it begins loading the third-to-last file, it requests a new copy of the index. The specification therefore requires at least 3 media files be listed in the index file at all times. The important point to consider when choosing the optimum number is that the number of files available during a live session constrains the client's behavior when doing play/pause and seeking operations. The longer the list, the longer the client can be paused without losing its place in the broadcast, the further back in the broadcast a new client begins, and the wider the time range within which the client can seek. The trade-off is that a longer index file adds to network overhead--during live broadcasts, the clients are all refreshing the index file regularly, so it does add up, even when the index file is small.
17
2009-09-09 | © 2009 Apple Inc. All Rights Reserved.
CHAPTER 3
Frequently Asked Questions
Another point to consider is that clients typically request new copies of the index file at higher rate when the index contains a shorter list of files. Example: Assuming files are of 10-second duration, maintaining an index with 182 entries allows the client to seek within a 30 minute window. If the user watches the media files in sequence, without seeking ahead, the client requests a new index file every half hour. Similarly, an index with 3 entries gives the user a 10 second window and the client requests a new index file every 10 seconds. 5. What data rates are supported? The current implementation has been tested using audio-video streams with data rates as low as 100 Kbps and as high as 1.6 Mbps to iPhone. The data rate that a content provider chooses for a stream is most influenced by the target client platform and the expected network topology. The streaming protocol places no limitations on the data rates that can be used. Note: If the data rate exceeds the available bandwidth, there is more latency before startup and the client may have to pause to buffer more data periodically. During a broadcast using an index file that provides a moving window into the content, the client will eventually fall behind in such cases, causing one or more segments to be dropped. In the case of VOD, no segments are lost, but inadequate bandwidth does cause slower startup and periodic stalling while data buffers. 6. What is a .ts file? A .ts file contains an MPEG-2 Transport Stream. This file format encapsulates a series of encoded media samples--typically audio and video. The file format supports a variety of compression formats, such as MP3, AAC, H.264, MPEG-2 video, and so on. Not all possible formats are currently supported in the Apple HTTP streaming implementation, however. (For a list of currently supported formats, see "Media Encoder" (page $@).) 7. What is an .M3U8 file? An .M3U8 file is a extensible playlist file format. It is an m3u playlist containing UTF-8 encoded text. The m3u file format is a de facto standard playlist format suitable for carrying lists of media file URLs. This is the format used as the index file for NRT streaming over HTTP. For details, see IETF Internet-Draft of the HTTP Live Streaming specification. 8. How does the client software determine when to switch streams? The current implementation of the client observes the effective bandwidth while playing a stream. If a higher-quality stream is available and the bandwidth appears sufficient to support it, the client switches to a higher quality. If a lower-quality stream is available and the current bandwidth appears insufficient to support the current stream, the client switches to a lower quality. Note: For seamless transitions between alternate streams, the audio portion of the stream should be identical in both versions. 9. Where can I download a copy of the media stream segmenter from Apple? A beta version can be downloaded from the Apple Developer Connection member download site, at https://connect.apple.com/cgi-bin/WebObjects/MemberSite.woa/wa/getSoftware?bundleID=20389.
18
2009-09-09 | © 2009 Apple Inc. All Rights Reserved.
CHAPTER 3
Frequently Asked Questions
10. What settings are recommended for a typical HTTP stream, with alternates, using the media segmenter from Apple?
ouput .ts files 10s segments H.264 Baseline 3.0 video Keyframes every 3 seconds HE-AAC (version 1) stereo audio at 44.1 kHz Three streams: Low--96 Kbps video, 64 Kbps audio Medium--256 Kbps video, 64 Kbps audio High--800 Kbps video, 64 Kbps audio
Note: For concerts or broadcasts where audio quality is paramount, you might substitute an audio data rate of 128 Kpbs, reducing video bandwidth proportionally. Examples of typical command line arguments for the media stream segmenter from Apple are included in the read me file downloaded with the segmenter. Note: If you are participating in the Snow Leopard seed program, there are man pages for the segmenter tool. 11. What are the hardware requirements or recommendations for servers? See question #1 for encoder hardware recommendations. The Apple stream segmenter is capable of running on any Intel-based Mac. We recommend using a Mac with two Ethernet network interfaces, such as a Mac Pro or an XServe. One network interface can be used to obtain the encoded stream from the local network, while the second network interface can provide access to a wider network. 12. Does the Apple implementation of HTTP Live Streaming support DRM? No. However, media can be encrypted and key access can be limited using HTTPS authentication. 13. What client platforms are supported? iPhone and iPod touch (requires iPhone OS version 3.0 or later) or any device with QuickTime X or later installed. 14. Is the protocol specification available? Yes. The protocol specification is an IETF Internet-Draft, at http://tools.ietf.org/html/draft-pantos-httplive-streaming. 15. Does the client cache content? The index file can contain an instruction to the client that content should not be cached. Otherwise, the client may cache data for performance optimization when seeking within the media.
19
2009-09-09 | © 2009 Apple Inc. All Rights Reserved.
CHAPTER 3
Frequently Asked Questions
16. Is this a real-time delivery system? No. It has inherent latency corresponding to the size and duration of the media files containing stream segments. At least one segment must fully download before it can be viewed by the client, and two may be required to ensure seamless transitions between segments. In addition, the encoder and segmenter must create a file from the input; the duration of this file is the minimum latency before media is available for download. Typical latency with recommended settings is in the neighborhood of 30 seconds. 17. What is the latency? Approximately 30 seconds, with recommended settings. See question #15. 18. Do I need to use a hardware encoder? No. Using the protocol specification, it is possible to implement a software encoder. 19. What advantages does this approach have over RTP/RTSP? HTTP is less likely to be disallowed by routers, NAT, or firewall settings. No ports need to be opened that are commonly closed by default. Content is therefore more likely to get through to the client in more locations and without special settings. HTTP is also supported by more content-distribution networks, which can affect cost in large distribution models. In general, more available hardware and software works unmodified and as intended with HTTP than with RTP/RTSP. Expertise in customizing HTTP content delivery using tools such as PHP is also more widespread. 20. Why is my stream's overall bit rate higher than the sum of the audio and video bitrates? MPEG-2 transport streams can include substantial overhead. They utilize fixed packet sizes that are padded when the packet contents are smaller than the default packet size. Encoder and multiplexer implementations vary in their efficiency at packing media data into these fixed packet sizes. The amount of padding can vary with frame rate, sample rate, and resolution. Using a more efficient encoder can reduce the amount of overhead, as can tuning the encoder settings. 21. Where can I get help or advice on setting up an HTTP audio/video server? You can visit the Apple Developer Forum at http://devforums.apple.com/.
20
2009-09-09 | © 2009 Apple Inc. All Rights Reserved.
REVISION HISTORY
Document Revision History
This table describes the changes to HTTP Live Streaming Overview. Date 2009-09-09 2009-06-04 2009-05-22 Notes Updated to include failover support. Added sample code, QuickTime X support. Reorganized document for readability. Changed title from iPhone Streaming Media Guide for Web Developers. Added URL for downloading media segmenter. New document that describes live streaming of audio and video over HTTP for iPhone.
2009-03-15
21
2009-09-09 | © 2009 Apple Inc. All Rights Reserved.
REVISION HISTORY
Document Revision History
22
2009-09-09 | © 2009 Apple Inc. All Rights Reserved.
If this document matches the user guide, instructions manual or user manual, feature sets, schematics you are looking for, download it now. Diplodocs provides you a fast and easy access to the user manual APPLE HTTP LIVE STREAMING .
APPLE offer a product for which we do not have the user manual? Let us know what you are looking for: user guide, owner's manual, online manual, operating instructions, quick start guide, mounting instructions, schematics, service manual, installation instructions, RTFM.
Diplodocs allows you to download user manual APPLE HTTP LIVE STREAMING, user guide APPLE HTTP LIVE STREAMING, instructions APPLE HTTP LIVE STREAMING, owner's manual APPLE HTTP LIVE STREAMING, online manual APPLE HTTP LIVE STREAMING.
APPLE HTTP LIVE STREAMING, APEL, APLE, APPLE COMPUTER, Desktop PC, Mini PC & Mac Desktop Computer.
