29/6/2015

TechnicalNoteTN2224:BestPracticesforCreatingandDeployingHTTPLiveStreamingMediafortheiPhoneandiPad

Technical Note TN2224

Best Practices for Creating and Deploying HTTP Live Streaming Media
for the iPhone and iPad
This Technote discusses some best practices for creating and deploying HTTP Live Streaming Media for the iPhone and iPad.
Introduction
Getting Started
Workflow
Decide on Your Variants
Encoding Hardware, Budget Constraints
Ability to Switch
Device Capabilities
Network Capabilities
Bit rate recommendations
Special considerations for cellular
Encode your Variants
Recommended Encoding Settings for HTTP Live Streaming Media
How to create content with the recommended settings using QuickTime
Segment your Media
Media Stream Segmenter Tool
Creating an audio only stream
Media File Segmenter Tool
Transport Stream Structural Overhead
Use at least one IDR-frame per segment (preferably at the start)
Use 10 second Target Durations
Create Variant Playlist
Variant Playlist Creator Tool
Use Relative Path Names
Deploy Your Media
HTML5 video element
Web Server Configuration
Serve playlists using gzip
Keep Track of your Performance
Validate Your Media
Media Stream Validator Tool
References
Document Revision History

Introduction
This Technote describes the recommended practices for preparing and deploying your media for use with HTTP Live Streaming. HTTP Live Streaming
allows you to send live or prerecorded audio and video to iPhone, iPad, and other devices including desktop computers, using an ordinary Web server.
Playback requires iOS 3.0 or later on devices running iOS; QuickTime X or later is required on the desktop.
The HTTP Live Streaming Overview should be considered a prerequisite because it introduces the HTTP Live Streaming technology.
Important:This document is updated frequently. Please bookmark this page, and refer back to it for the most current recommendations before
starting your next project.

Getting Started
When working with video and audio a good general rule of thumb is to get the highest quality original source material as possible. When you compress,
very often some information gets lost or thrown away. Therefore, you should only compress material when encoding for the final destination, because
each process will lower the quality. Trying to compress from already heavily compressed source material may give poor results.
Always start with the highest quality source video & audio, and make lower bit rate movies from the original source.

Workflow
The typical workflow for preparing and deploying your media for use with HTTP Live Streaming consists of the following steps. The workflow for live
content is similar but requires you to create a workflow that will take care of all these steps in real-time.
Figure 1:Workflow for preparing and deploying media for use with HTTP Live Streaming.

https://developer.apple.com/library/ios/technotes/tn2224/_index.html#//apple_ref/doc/uid/DTS40009745CH1SETTINGSFILES

1/11

29/6/2015

TechnicalNoteTN2224:BestPracticesforCreatingandDeployingHTTPLiveStreamingMediafortheiPhoneandiPad

Here's a brief overview of the different steps:

Decide on your variants
We recommend you offer multiple playlist files to provide different encodings of the same presentation at different bit rates, rather than just a single
encoding. These encodings at different bit rates are called variants. That way, the client will switch to the most appropriate variant based on the
measured network bit rate. The clients player is tuned to minimize stalling of playback in order to give the user the best experience possible when
streaming. If you just provide a single encoding of your presentation your users will not get the best possible experience. See Decide on Your
Variants.
Encode your media variants
Based on the different variants you've decided to deploy, encode each of these from your high-quality source media. When encoding your variants
you must have at least one I-frame in each segment to facilitate fast startup and seek. See Encode your Variants to learn about providing different
encodings of the same presentation.
Segment the media
HTTP Live Streaming sends audio and video as a series of small files, typically of about 10 seconds duration, called media segment files. An index file,
or playlist, gives the clients the URLs of the media segment files.
For video on demand from prerecorded media, Apple provides a free tool to make media segment files and playlists from MPEG-4 video or QuickTime
movies with H.264 video compression, or audio files with AAC or MP3 compression. The playlists and media segment files can be used for video on
demand or streaming radio, for example.
For live streams, Apple provides a free tool to make media segment files and playlists from live MPEG-2 transport streams carrying H.264 video, AAC
audio, or MP3 audio. See also Segment your Media.
Create a variant playlist
A variant playlist can support delivery of multiple streams of the same content with varying quality levels for different bandwidths or devices. HTTP
Live Streaming supports switching between streams dynamically if the available bandwidth changes. 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. See
Create Variant Playlist.
Deploy the media
To deploy HTTP Live Streaming media, you need the use of a web server, and you need to create either an HTML page for browsers or a client app to
act as a receiver. You may want to encrypt your streams, in which case you should serve the encryption key files securely over HTTPS, so that only
your intended clients can decrypt them. See Deploy Your Media.
Validate the media
You should use the Apple-provided media stream validator prior to serving your streams, to ensure that they are fully compliant with HTTP Live
Streaming. See Validate Your Media.
Back to Top

Decide on Your Variants

Instead of offering just a single encoding of your presentation, you should offer multiple playlist files to provide different encodings of the same
presentation. The HTTP Live Streaming client will then switch among these stream alternates dynamically as the network bandwidth changes, providing
the best possible stream for the current network conditions.
When choosing the bit rates for your variant playlist there are a number of things to take into consideration. These are discussed below.

Encoding Hardware, Budget Constraints

You may have a limitation on the number of bit rates that your particular encoding hardware can produce. If your encoding system can only produce a
certain number of streams, you should choose variants that work for the most devices. For live streams delivered through a CDN, you should determine
how much bandwidth is necessary to get all of your streams up and running at the same time. You may also have financial constraints.

Ability to Switch
You should check the distance between the bitrates of your variants because this will determine the ability of the client to switch to a different bitrate.
See Bit rate recommendations for more information.

Device Capabilities
You should also learn as much as you can about the client devices you will be serving, because different devices may have different capabilities. Some

https://developer.apple.com/library/ios/technotes/tn2224/_index.html#//apple_ref/doc/uid/DTS40009745CH1SETTINGSFILES

2/11

29/6/2015

TechnicalNoteTN2224:BestPracticesforCreatingandDeployingHTTPLiveStreamingMediafortheiPhoneandiPad

may have different screen resolutions, some may support different versions of the H.264 profile levels. In certain cases, you might want to provide a
different playlist for different device models; for example, a different playlist to iPads vs. iPhones. These are discussed below:
Select Device based on Device Resolution
Different devices support different resolutions. Because of this, you may want to add the RESOLUTION attribute to the master playlist to allow the
client to select the playlist based on device resolution. Consider the following playlist:

#EXTXSTREAMINF:BANDWIDTH=1280000,RESOLUTION=640x360
#EXTXSTREAMINF:BANDWIDTH=1700000,RESOLUTION=1280x720
#EXTXSTREAMINF:BANDWIDTH=3500000,RESOLUTION=1920x1080
When delivering to an older device, such as an iPhone 3GS, the client will select the 640x360 playlist since these devices can't play 720p or 1080p
content. However, newer devices such as the new iPad support higher resolutions and will pick the 1080p stream (provided it can handle the bitrate).
Note that if you've got an app that is delivering video to a smaller 640x360 window and not the whole screen, the client will select the 640x360
stream. There's no advantage to getting the 1080p stream and downshifting it if you're only showing the video in a small window. This would waste
the user's bandwidth. However, if the app then goes to fullscreen the client will switch up to the 1080p stream, if possible.
Select Device based on Device codec
You can also add the CODECS attribute to your playlist to allow the client to filter based on the codec and the particular profile and level of encoding
supported by the device. Here's an example playlist. The first entry specifies the H.264 Baseline profile, the second entry specifies the H.264 Main
profile and the third specifies the H.264 High profile (Note: the comments are for illustrative purposes only, and would be considered illegal syntax in
an actual playlist):

#EXTXSTREAMINF:BANDWIDTH=1280000,CODECS="avc1.42001e"//Baseline
#EXTXSTREAMINF:BANDWIDTH=1280000,CODECS="avc1.4d001f"//Main
#EXTXSTREAMINF:BANDWIDTH=1280000,CODECS="avc1.64001f"//High
When serving such a playlist to a device like the iPhone 3GS that doesn't support the H.264 Main or High profile, the client will select the Baseline
profile and ignore the other two variants, whereas the iPhone 4 would select the Main profile.
Select based on Device Model
You can also select a playlist based on the device model (for example, the iPhone vs. iPad) by filtering on the HTTP Header field UserAgent
identification string. This is performed on the server side rather than the client side. Here's some example UserAgent strings. The first two strings
represent clients delivered over Safari, and the second two strings represent apps:

Mozilla/5.0(iPhoneCPUiPhoneOS5_1_1likeMacOSX)AppleWebKit/534.46(KHTML,likeGecko)Version/5.1
Mobile/9B206Safari/7534.48.3
Mozilla/5.0(iPadCPUOS5_1_1likeMacOSX)AppleWebKit/534.46(KHTML,likeGecko)Version/5.1Mobile/9B206
Safari/7534.48.3
AppleCoreMedia/1.0.0.9B176(iPhoneUCPUOS5_1likeMacOSXen_us)
AppleCoreMedia/1.0.0.9B176(iPadUCPUOS5_1likeMacOSXen_us)

Network Capabilities
You may also want to take into consideration your network capabilities when deciding on your variants.
You can use the SystemConfiguration framework to determine whether or not you are on a cellular or WiFi network (see the Reachability sample code for
an example of this). Once you determine what type of network you are on, you may want to request a different URL, or add this as extra information in
your request so that the server can provide a different playlist. This is particularly important because it allows you to specify an appropriate entry for the
first item in the playlist based on the network that you are on (see Bit rate recommendations to learn more about the importance of the first entry in the
playlist).

Bit rate recommendations

Here are some recommendations for choosing the bit rates in your variant playlist:
First bit rate should be one that most clients can sustain
The first entry in the variant playlist will be played at the initiation of a stream and is used as part of a test to determine which stream is most
appropriate. The order of the other streams is irrelevant. Therefore, the first bit rate in the playlist should be the one that most clients can sustain.
You should create multiple playlists that have the same set of streams, but each with a different first entry that is appropriate for the target network.
This ensures the user has a good experience when the stream is first played.
We recommend you point to a 150 Kbps stream for the cellular Variant Playlist.
We recommend you point to a 440 Kbps stream for the Wi-Fi Variant Playlist.
See Recommended Encoding Settings for HTTP Live Streaming Media.
Where possible, encode enough variants to provide the best quality stream across a wide range of connection speeds
For example, encode variants at 64 Kbps, 110 Kbps, 200 Kbps, 350 Kbps, 550 Kbps, 900 Kbps and 1500 Kbps.
Audio/Video Stream Considerations
Video aspect ratio must be exactly the same, but can be different dimensions.
We recommend 416 x 234 for 16:9 content and 400 x 300 for 4:3 content (see Recommended Encoding Settings for HTTP Live Streaming Media).

https://developer.apple.com/library/ios/technotes/tn2224/_index.html#//apple_ref/doc/uid/DTS40009745CH1SETTINGSFILES

3/11

29/6/2015

TechnicalNoteTN2224:BestPracticesforCreatingandDeployingHTTPLiveStreamingMediafortheiPhoneandiPad
Note:One easy way to synchronize different VOD stream files is to copy the audio track of one Variant Playlist member file into each of the other
member files.
Adjacent bit rates should be a factor of 1.5 to 2 apart
You should keep adjacent bit rates at a factor of 1.5 to 2 apart. If you put them too close together, you will waste bandwidth. For example, it won't
make much of a difference if you've got a 150 Kbps and a 180 Kbps stream. On the other hand, don't make them too far apart either. If they are too
far apart, the client may find itself in a situation where it could actually have gotten a better stream but there isn't one available. An example of this is
if the client is going from 100 Kbps to 300 Kbps. It's too big of a jump.
Keyframes (IDR frames)
You must include at least one keyframe per segment, preferably more. If you only include one, put it at the beginning of the segment.
Don't under report bit rate in master playlist
To prevent stalls, do not under-report the bit rate in the master playlist. The maximum bit rate should be specified based on the peak bit-rate in the
stream. For example, if you've declared a 200 Kbps variant in your playlist, then its maximum bitrate should be 200 Kbps. If your 200 Kbps stream
actually peaks at 300 Kbps, the client may stall because you misrepresented how much bandwidth is actually needed to play a given stream.

Special considerations for cellular

If you are using HTTP Live Streaming in iPhone and iPad applications sold on the App Store there are some special considerations for cellular:
Warning:These requirements apply to iOS apps submitted for distribution in the App Store for use on Apple products. Non-compliant apps may
be rejected or removed, at the discretion of Apple.
Provide a 192 Kbps stream
If your app uses HTTP Live Streaming over cellular networks, you are required to provide at least one stream at 192 Kbps or lower bandwidth (the
low-bandwidth stream may be audio-only, or audio with a still image).
Important:When you submit your app to the App Store you should specify a url to your cellular 192 Kbps stream so the app reviewers can test it.
Otherwise, the reviewers will need to sniff the network packets coming from your app to try and locate the stream. If your stream does not have a
measured bit rate of less than or equal to 192 Kbps, your app will be rejected.

We recommend you create a simple audio elementary stream, perhaps with a poster frame jpg image. The mediastreamsegmenter and

mediafilesegmenter tools (See Segment your Media) can produce an audio-only stream. See Creating an audio only stream. Alternately, create an
audio and video transport stream with a very low frame rate. However, it will be very difficult to create a stream with both audio and video that is
below 192 Kbps. Instead, we recommend you use audio only.
Remember the 192 Kbps is not the sum of the audio + video bandwidth, it is the bandwidth of the muxed stream. The 192 Kbps is the entire stream,
including overhead. If you are not using audio only, chances are you are over the 192 Kbps limit.
Some common mistakes when creating the 192 Kbps stream are:
Thinking you have a < 192 Kbps stream because the sum of your audio and video bitrates is < 192 Kbps, but not including transport stream
overhead.
Putting too large a JPG at the beginning of each segment.
Inaccurate EXTINF causing miscalculation.
Large segment EXTINFs.
As discussed above, we recommend using ADTS elementary streams. The mediastreamsegmenter and mediafilesegmenter tools can pull the
audio out of the transport stream for you.
Don't serve media segments from your app
Apps cannot grab media in some other format over the cellular network and run a local web server to translate and serve that content as an HTTP Live
stream. Your app will be rejected if you do.
Back to Top

Encode your Variants

Once you've decided on the different variants you'd like to deploy, encode each of these from your high-quality source media.
To deploy a video on demand (VOD) stream, you must create MP3 or MPEG-4 media files with H.264 and AAC encoding from your source material.
Always start with the highest quality source media, and make any lower bit rate movies from the original source, because subsequent re-encodings may
lower the quality.
Live streams must be encoded as MPEG-2 transport streams carrying H.264 video, AAC audio, or MP3 audio.

Recommended Encoding Settings for HTTP Live Streaming Media

Figure 2 contains recommended encoding settings to use when creating HTTP Live Streaming media.

https://developer.apple.com/library/ios/technotes/tn2224/_index.html#//apple_ref/doc/uid/DTS40009745CH1SETTINGSFILES

4/11

29/6/2015

TechnicalNoteTN2224:BestPracticesforCreatingandDeployingHTTPLiveStreamingMediafortheiPhoneandiPad
Important:These are recommended settings, not required settings. For example, if you are targeting movies that have very fast motion (such as
sporting events), or if you have concerns about bandwidth, you may need to perform additional compression on your video to get the desired results.
If this is the case, use these settings as a starting point, and recompress until you are satisfied with the results.

These settings apply to both live and prerecorded (video on demand, or VOD) encoding. The provided settings are grouped according to whether the
content is intended to be streamed over the cellular or Wi-Fi network, whether the content is for iPhone/iPod Touch or iPad, and whether the content is
4:3 or 16:9 aspect ratio.
The following audio and video formats are supported:
Video: H.264 Baseline Profile Level 3.0 (iPhone/iPod Touch), Main Profile Level 3.1 (iPad 1,2), High Profile Level 4.1 (new iPad), MPEG-4 Simple Profile
(iPhone/iPod Touch/iPad), Motion JPEG (M-JPEG) (iPod Touch 4th Gen, iPhone 4, iPad)
Audio: HE-AAC or AAC-LC up to 48 kHz, stereo audio OR
MP3 (MPEG-1 Audio Layer 3) 8 kHz to 48 kHz, stereo audio

Note:iPhone 3G supports H.264 Baseline Profile Level 3.1. If your app runs on older iPhones, however, you should use H.264 Baseline Profile 3.0 for
compatibility.

Important:Interlaced video is not supported on iOS devices.

Figure 2:Recommended Encoding Settings for HTTP Live Streaming Media.

Note:When streaming multimedia content across networks it is the maximum bit rate that is most important, not the average. Therefore, you should
pay particular attention to the maximum bit rate when encoding your media with your encoder because it will allow the client to choose the best
variant for the available network bandwidth.

How to create content with the recommended settings using QuickTime

https://developer.apple.com/library/ios/technotes/tn2224/_index.html#//apple_ref/doc/uid/DTS40009745CH1SETTINGSFILES

5/11

29/6/2015

TechnicalNoteTN2224:BestPracticesforCreatingandDeployingHTTPLiveStreamingMediafortheiPhoneandiPad

To learn how to export files with these settings using QuickTime, see Technical Note TN2218, 'Compressing QuickTime Movies for the Web'
Back to Top

Segment your Media

HTTP Live Streaming requires that a media stream or file be segmented into a series of small media files of approximately equal duration. This is usually
accomplished using a tool that will segment the individual files and create a playlist.
This architecture allows for a live stream that has already been segmented to be quickly converted to a VOD stream just by updating the playlist.
There are two command-line tools available to you from Apple for segmentation of HTTP Live Streaming media. The tools are:
Media Stream Segmenter
Media File Segmenter

Important:Both tools are frequently updated. If you are an iOS or Mac Developer Program member, you can download the latest versions from the
Apple Developer Connection website. To download, go to Downloads for Apple Developers, look for the 'HTTP Live Streaming Tools', download and
install the 'HTTP Live Streaming Tools'.

Media Stream Segmenter Tool

You can use the Media Stream Segmenter (mediastreamsegmenter) tool for deployment of HTTP Live Streaming Media.
The tool is installed to your system disk at /usr/bin/mediastreamsegmenter. (The /usr/bin directory is hidden from the Finder, but is accessible
using the Terminal application, located in the Utilities folder.)
This tool receives an MPEG-2 transport stream over a UDP network connection or from stdin and divides it into a series of small media segments of
equal duration. It then creates an index file containing references to the individual media segments. The index file and media segments can be deployed
using almost any web server infrastructure for streaming to iOS and OS X. The mediastreamsegmenter produces either live or Video on Demand (VOD)
streams.
The mediastreamsegmenter tool accepts different command line arguments (you can obtain a list of the command line arguments and their meanings
by typing manmediastreamsegmenter from the Terminal application, or see the online man page).
Here's an example showing how to use the mediastreamsegmenter to capture and create an unencrypted live stream:

mediastreamsegmenters3Df/Library/WebServer/Documents/stream239.4.1.5:20103
The s option defines the number of media file entries that should be kept in the index file. The default is 5. The D option (in a live stream) will specify
that the media files that are no longer in the index file will be removed after an expiry period. The f option specifies the directory to store the media
and index files.
In this example, the index file will contain 3 items. Media files will be removed after an expiry period. The media and index files will be stored in

/Library/WebServer/Documents/stream.

Creating an audio only stream

This tool can produce an audio-only stream if you specify the following argument:

a|audioonly
This strips the audio elementary stream (AAC/ADTS or MP3) and writes it into the media file. For example, you could run the mediastreamsegmenter
on an existing audio/video stream to get an audio-only stream.
If you'd also like to include a poster image in your audio only stream, just create a small jpg or png (20 to 30k), and use the audioonly setting of the

mediafilesegmenter, with the metafile and metatype=pictureset ( typing manmediafilesegmenter from the Terminal application will
give you details for all the options).

Media File Segmenter Tool

The media file segmenter (mediafilesegmenter) is a command-line tool that segments media files for deployment using HTTP Live Streaming. The

mediafilesegmenter takes media from the specified file, multiplexes it into MPEG-2 Transport streams if required, and divides it into a series of small
media files of approximately equal duration.
Note:The mediafilesegmenter accepts media from a file. Use the Media Stream Segmenter Tool to receive a stream over a network connection or
from stdin.
The mediafilesegmenter also creates an index file containing references to the individual media files. The index file and media files can then be
deployed as a VOD stream using common web server infrastructure.
Note:New in iOS 5, you can now specify a media segment as a byte range (subrange) of a larger URL. This allows you to consolidate your media
segments into larger files or a single large file. See Example Playlist Files for use with HTTP Live Streaming.

The mediafilesegmenter tool accepts many different command line arguments (you can obtain a list of the command line arguments and their
meanings by typing manmediafilesegmenter from the Terminal application).

https://developer.apple.com/library/ios/technotes/tn2224/_index.html#//apple_ref/doc/uid/DTS40009745CH1SETTINGSFILES

6/11

29/6/2015

TechnicalNoteTN2224:BestPracticesforCreatingandDeployingHTTPLiveStreamingMediafortheiPhoneandiPad
Note:Previous versions of the tool required you specify the O or optimize option to turn on optimization, otherwise it was off by default. With the
current tool, optimization is on by default:

[O|optimize[yes|no]]

Transport Stream Structural Overhead

MPEG transport streams contain a certain amount of overhead and padding. Depending upon how your transport stream is created, you might have
more overhead than in other cases. The Apple media file and stream segmenters have been optimized to produce very little overhead, typically less than
10% (and in most cases, less than 5%). Streams produced by some third-party encoders contain overhead as high as 45%.
To put that into perspective, if your stream is 100 Kbps, and you've got 45% overhead, only 55 Kbps of actual video data that is making it through. If
your overhead is 5%, then you have 95 Kbps of video. Obviously, you can produce a much better stream if you've got 95 Kbps of video data versus 55
Kbps, so you'll want to minimize that overhead if you can. If you are working with a third-party vendor, we suggest you take your original content,
encode it with the Apple stream segmenter, and compare to see what kind of overhead you are getting.

Use at least one IDR-frame per segment (preferably at the start)

In order to have fast startup and seek, you need to have an IDR frame in your segment. In H.264 video, IDR refers to Instantaneous Decoder Refresh
frames, a special kind of I-frame. These indicate to the decoder that no frame occurring after an IDR frame depends on any frame that occurs before it.
We recommend you have at least one IDR frame at the beginning of your segment, because when seeking or starting up partway through a live stream
the client needs an IDR frame to get started. If you put your IDR frames partway into the segment, the client cannot start until it finds an IDR frame.

Use 10 second Target Durations

The value you specify in the EXTXTARGETDURATION tag for the maximum media segment duration will have an effect on startup. We strongly
recommend a 10 second target duration. If you use a smaller target duration, you increase the likelihood of a stall. Here's why: if you've got live content
being delivered through a CDN, there will be propogation delays, and for this content to make it all the way out to the edge nodes on the CDN it will be
variable. In addition, if the client is fetching the data over the cellular network there will be higher latencies. Both of these factors make it much more
likely you'll encounter a stall if you use a small target duration.
Back to Top

Create Variant Playlist

A streaming multimedia presentation is specified by a Playlist file, which is a list of media file resources, each of which refers to a segment of a single
contiguous stream. A server may offer multiple Playlist files to provide different encodings of the same presentation when HTTP Live Streaming. If it
does, it should provide a Variant Playlist file that lists each variant stream to allow clients to switch between encodings dynamically if the available
bandwidth changes.
See the HTTP Live Streaming Overview and the HTTP Live Streaming Protocol Specification for additional information about Variant Playlists.

Variant Playlist Creator Tool

The Variant Playlist Creator (variantplaylistcreator) is a command line tool that will create a variant playlist in the m3u8 format for stream
switching for HTTP Live Streaming segments created by mediafilesegmenter. iPhone and Mac Developer Program members can download the tool as
part of the HTTP Live Streaming Tools package as described in Segment your Media.
The variantplaylistcreator takes pairs of URLs and plist files generated using the Igeneratevariantinfo option from

mediafilesegmenter and creates a variant stream playlist. You can obtain a list of all the command line arguments and their meanings by typing man
variantplaylistcreatorfrom the Terminal application.

Use Relative Path Names

When possible, use relative path names in Variant Playlists and in the individual .m3u8 Playlist files.
Relative path names are more portable than absolute path names. Using full path names for the individual playlist entries most often uses more text
than using a relative path name. In the case of a very long VOD playlist, or a very long duration Live playlist, this can create a significant file size
difference in the playlist file itself, increasing the download time of the playlist files.
Back to Top

Deploy Your Media

HTML5 video element
We recommend you use the HTML5 video element to display video in Safari on iOS. For more information about the video element, see the Safari Guide
to HTML5 Audio and Video and the HTMLMediaElement, HTMLVideoElement, and HTMLAudioElement class references in the Safari DOM Extensions
Reference.
The source code example in Listing 1 demonstrates how to use the video element to display HTTP Live Streaming video in a web page.

https://developer.apple.com/library/ios/technotes/tn2224/_index.html#//apple_ref/doc/uid/DTS40009745CH1SETTINGSFILES

7/11

29/6/2015

TechnicalNoteTN2224:BestPracticesforCreatingandDeployingHTTPLiveStreamingMediafortheiPhoneandiPad

Listing 1:HTML5 video element example.

<videosrc="http://devimages.apple.com/iphone/samples/bipbop/bipbopall.m3u8">
ThisbrowserdoesnotsupportHTML5video.
</video>

See also Technical Note TN2262, 'Preparing Your Web Content for iPad' which describes platform-specific considerations for web content in Safari on iOS
devices, with specific information for iPad.

Web Server Configuration

The distribution system for HTTP Live Streaming media is a web server or a web caching system that delivers the media files and index files to the client
over HTTP (see the HTTP Live Streaming Overview for more information). 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.

Table 1:MIME-type associations for .M3U8 files and .ts files.

File Extension

MIME Type

.M3U8

vnd.apple.mpegURL or application/x-mpegURL

.ts

video/MP2T

Servers that are constrained for compatibility can serve files ending in .m3u with MIME type audio/mpegURL.
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. Check with your content delivery service provider for specific
recommendations.

Serve playlists using gzip

You should always serve your playlist using gzip. VOD Playlists can have hundreds of entries. Even in a live playlist, you can have hundreds of entries if
you are delivering a large window of content. gzip reduces the size dramatically, and it is very easy to add to your server (it is typically a one line change
in your server configuration).

Keep Track of your Performance

After deploying your streams, you should track actual performance in the field to verify your assumptions about the bitrates you've chosen. Use the
MediaPlayer framework client access and error logs for this purpose. There are a number of different fields in the access log. You should pay attention to
the fields that tell you what streams you are actually getting, how long are they playing, where the stream switching is occurring, and whether or not you
are getting stalls.
See the MPMovieAccessLogEvent, MPMovieAccessLog and MPMovieErrorLogEvent classes for more information.
Back to Top

Validate Your Media

Media Stream Validator Tool
The Media Stream Validator (mediastreamvalidator) is a command-line tool to validate HTTP Live Streaming streams and servers. iPhone and Mac
Developer Program members can download the tool as part of the HTTP Live Streaming Tools package as described in Segment your Media.
This tool simulates an HTTP Live Streaming session and verifies that the index file and media segments conform to the HTTP Live Streaming
specification. It performs several checks to ensure reliable streaming. If any errors or problems are found, a detailed diagnostic report is displayed.
Important:You should always run the mediastreamvalidator tool on your stream to verify that it conforms to the HTTP Live Streaming
specification.
Here's example output from the mediastreamvalidator tool.

Listing 2:Example validator tool output.

Validatinghttps://devimages.apple.com.edgekey.net/resources/httpstreaming/examples/bipbop_4x3/bipbop_4x3_variant.m3u8
Validatingchildplaylistgear1/prog_index.m3u8
Validatingchildplaylistgear2/prog_index.m3u8
Validatingchildplaylistgear4/prog_index.m3u8
Validatingchildplaylistgear0/prog_index.m3u8
Validatingchildplaylistgear3/prog_index.m3u8

https://developer.apple.com/library/ios/technotes/tn2224/_index.html#//apple_ref/doc/uid/DTS40009745CH1SETTINGSFILES

8/11

29/6/2015

TechnicalNoteTN2224:BestPracticesforCreatingandDeployingHTTPLiveStreamingMediafortheiPhoneandiPad

https://devimages.apple.com.edgekey.net/resources/httpstreaming/examples/bipbop_4x3/bipbop_4x3_variant.m3u8

PlaylistValidation:

OK

Alternateplaylist(s):

gear1/prog_index.m3u8

PlaylistValidation:

OK

Segments:

OK

Averagesegmentduration:9.93seconds
Averagesegmentbitrate:231379.21bps
Averagesegmentstructuraloverhead:12107.10bps(5.23%)

gear2/prog_index.m3u8

PlaylistValidation:

OK

Segments:

OK

Averagesegmentduration:9.93seconds
Averagesegmentbitrate:646360.46bps
Averagesegmentstructuraloverhead:21147.77bps(3.27%)

gear3/prog_index.m3u8

PlaylistValidation:

OK

Segments:

OK

Averagesegmentduration:9.93seconds
Averagesegmentbitrate:983809.40bps
Averagesegmentstructuraloverhead:29737.85bps(3.02%)

gear4/prog_index.m3u8

PlaylistValidation:

OK

Segments:

OK

Averagesegmentduration:9.93seconds

https://developer.apple.com/library/ios/technotes/tn2224/_index.html#//apple_ref/doc/uid/DTS40009745CH1SETTINGSFILES

9/11

29/6/2015

TechnicalNoteTN2224:BestPracticesforCreatingandDeployingHTTPLiveStreamingMediafortheiPhoneandiPad
Averagesegmentbitrate:1496114.70bps
Averagesegmentstructuraloverhead:40250.70bps(2.69%)

gear0/prog_index.m3u8

PlaylistValidation:

OK

Segments:

OK

Averagesegmentduration:10.00seconds
Averagesegmentbitrate:41264.41bps

Note:The mediastreamvalidator will first show a listing of the streams you provide, followed by the timing results for each of those streams.
However, it may take a few minutes for the mediastreamvalidator to calculate the actual timing results.
For variant playlists, it is important that the bitrates specified in the playlist are very close to the actual measured rates. If not, a warning will be issued
by the mediastreamvalidator. The bitrates are specified in the EXTXSTREAMINF tag using the BANDWIDTH attribute.

Listing 3:Example Variant Playlist showing the BANDWIDTH attribute.

#EXTM3U
#EXTXSTREAMINF:PROGRAMID=1,BANDWIDTH=1280000
http://example.com/low.m3u8
#EXTXSTREAMINF:PROGRAMID=1,BANDWIDTH=2560000
http://example.com/mid.m3u8
#EXTXSTREAMINF:PROGRAMID=1,BANDWIDTH=7680000
http://example.com/hi.m3u8

See the HTTP Live Streaming Protocol Specification for more information about the BANDWIDTH attribute.
Back to Top

References
HTTP Live Streaming Resources
HTTP Live Streaming Overview
IETF Internet Draft of the HTTP Live Streaming Protocol Specification
Technical Note TN2218, 'Compressing QuickTime Movies for the Web'
Preparing Your Web Content for iPad
Example Playlist Files for use with HTTP Live Streaming
Safari Guide to HTML5 Audio and Video
Safari DOM Extensions Reference
Back to Top

Document Revision History

Date

Notes

2015-05-04

Updated special considerations for cellular section to reflect current App Store Review Guidelines.

2014-02-28

Updated the recommended encoding settings to include newer devices. Other miscellaneous changes.

2012-08-14

Includes new and updated recommendations for deciding on variants, encoding, segmenting and deploying your media.

2011-08-03

Editorial

2011-07-08

Revised encoder settings recommendations to include Apple TV.

2010-04-19

Updated recommended encoding settings to include iPad only values.

2010-03-19

New document that discusses best practices for creating and deploying HTTP Live Streaming Media for the iPhone and iPad

https://developer.apple.com/library/ios/technotes/tn2224/_index.html#//apple_ref/doc/uid/DTS40009745CH1SETTINGSFILES

10/11