https://developer.apple.com/library/ios/#technotes/tn2224/_index.html
This Technote discusses some best practices for creating and deploying HTTP Live Streaming Media for the iPhone and iPad.
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.
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 client’s 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. SeeEncode 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 alsoSegment 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. SeeCreate 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. SeeValidate Your Media.
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. SeeBit 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 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
RESOLUTIONattribute to the master playlist to allow the client to select the playlist based on device resolution. Consider the following playlist:#EXT-X-STREAM-INF:BANDWIDTH=1280000,RESOLUTION=640x360#EXT-X-STREAM-INF:BANDWIDTH=1700000,RESOLUTION=1280x720#EXT-X-STREAM-INF:BANDWIDTH=3500000,RESOLUTION=1920x1080When delivering to an older device, such as an iPhone 3GS or 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
CODECSattribute 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):#EXT-X-STREAM-INF:BANDWIDTH=1280000,CODECS="avc1.42001e" // Baseline#EXT-X-STREAM-INF:BANDWIDTH=1280000,CODECS="avc1.4d001f" // Main#EXT-X-STREAM-INF:BANDWIDTH=1280000,CODECS="avc1.64001f" // HighWhen 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
User-Agentidentification string. This is performed on the server side rather than the client side. Here's some exampleUser-Agentstrings. The first two strings represent clients delivered over Safari, and the second two strings represent apps:Mozilla/5.0 (iPhone; CPU iPhone OS 5_1_1 like Mac OS X) AppleWebKit/ 534.46 (KHTML, like Gecko) Version/5.1 Mobile/9B206 Safari/7534.48.3Mozilla/5.0 (iPad; CPU OS 5_1_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1 Mobile/9B206 Safari/7534.48.3AppleCoreMedia/1.0.0.9B176 (iPhone; U; CPU OS 5_1 like Mac OS X; en_us)AppleCoreMedia/1.0.0.9B176 (iPad; U; CPU OS 5_1 like Mac OS X; en_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).
-
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 64 Kbps stream
If your app uses HTTP Live Streaming over cellular networks, you are required to provide at least one stream at 64 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 64 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 64 Kbps, your app will be rejected.
We recommend you create a simple audio elementary stream, perhaps with a poster frame jpg image. The
mediastreamsegmenterandmediafilesegmentertools (See Segment your Media) can produce an audio-only stream. SeeCreating 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 64 Kbps. Instead, we recommend you use audio only.Remember the 64 Kbps is not the sum of the audio + video bandwidth, it is the bandwidth of the muxed stream. The 64 Kbps is the entire stream,including overhead. If you arenot using audio only, chances are you are over the 64 Kbps limit.
Some common mistakes when creating the 64 Kbps stream are:
-
Thinking you have a < 64 Kbps stream because the sum of your audio and video bitrates is < 64 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
mediastreamsegmenterandmediafilesegmentertools 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.
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.
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.
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
To learn how to export files with these settings using QuickTime, see Technical Note TN2218, 'Compressing QuickTime Movies for the Web'
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 iPhone or Mac Developer Program member, you can download the latest versions from the Apple Developer Connection website. To download, go toDownloads 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 theUtilities folder.)
This tool receives an MPEG-2 transport stream over a UDP network connection or fromstdin 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. Themediastreamsegmenter 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 typingman mediastreamsegmenter from the Terminal application, or see the onlineman page).
Here's an example showing how to use the mediastreamsegmenter to capture and create an unencrypted live stream:
mediastreamsegmenter -s 3 -D -f /Library/WebServer/Documents/stream 239.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 | -audio-only
This strips the audio elementary stream (AAC/ADTS or MP3) and writes it into the media file. For example, you could run themediastreamsegmenter 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-audio-only setting of themediafilesegmenter, with the--metafile and --meta-type=picture set ( typingman mediafilesegmenter 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. Themediafilesegmenter 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 afile. Use theMedia Stream Segmenter Tool to receive a stream over a network connection or fromstdin.
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. SeeTechnical Note TN2288, '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 typingman mediafilesegmenter from the Terminal application).
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 ison 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 EXT-X-TARGETDURATION tag for the maximum media segment duration will have an effect on startup. Westrongly 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.
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 bymediafilesegmenter. iPhone and Mac Developer Program members can download the tool as part of the HTTP Live Streaming Tools package as described inSegment your Media.
The variantplaylistcreator takes pairs of URLs and plist files generated using the-I -generate-variant-info option frommediafilesegmenter and creates a variant stream playlist. You can obtain a list of all the command line arguments and their meanings by typingman 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.
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 thevideo element, see theSafari Guide to HTML5 Audio and Video and the HTMLMediaElement, HTMLVideoElement, andHTMLAudioElement class references in theSafari DOM Extensions Reference.
The source code example in Listing 1 demonstrates how to use thevideo element to display HTTP Live Streaming video in a web page.
Listing 1 HTML5 video element example.
<video src="http://devimages.apple.com/iphone/samples/bipbop/bipbopall.m3u8"> |
This browser does not support HTML5 video. |
</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 theHTTP 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.
| 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.
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.
Validating https://devimages.apple.com.edgekey.net/resources/http-streaming/examples/bipbop_4x3/bipbop_4x3_variant.m3u8 |
Validating child playlist gear1/prog_index.m3u8 |
Validating child playlist gear2/prog_index.m3u8 |
Validating child playlist gear4/prog_index.m3u8 |
Validating child playlist gear0/prog_index.m3u8 |
Validating child playlist gear3/prog_index.m3u8 |
| |
-------------------------------------------------------------------------------- |
https://devimages.apple.com.edgekey.net/resources/http-streaming/examples/bipbop_4x3/bipbop_4x3_variant.m3u8 |
-------------------------------------------------------------------------------- |
| |
Playlist Validation: |
| |
OK |
| |
Alternate playlist(s): |
| |
-------------------------------------------------------------------------------- |
gear1/prog_index.m3u8 |
-------------------------------------------------------------------------------- |
| |
Playlist Validation: |
| |
OK |
| |
Segments: |
| |
OK |
| |
Average segment duration: 9.93 seconds |
Average segment bitrate: 231379.21 bps |
Average segment structural overhead: 12107.10 bps (5.23 %) |
| |
-------------------------------------------------------------------------------- |
gear2/prog_index.m3u8 |
-------------------------------------------------------------------------------- |
| |
Playlist Validation: |
| |
OK |
| |
Segments: |
| |
OK |
| |
Average segment duration: 9.93 seconds |
Average segment bitrate: 646360.46 bps |
Average segment structural overhead: 21147.77 bps (3.27 %) |
| |
-------------------------------------------------------------------------------- |
gear3/prog_index.m3u8 |
-------------------------------------------------------------------------------- |
| |
Playlist Validation: |
| |
OK |
| |
Segments: |
| |
OK |
| |
Average segment duration: 9.93 seconds |
Average segment bitrate: 983809.40 bps |
Average segment structural overhead: 29737.85 bps (3.02 %) |
| |
-------------------------------------------------------------------------------- |
gear4/prog_index.m3u8 |
-------------------------------------------------------------------------------- |
| |
Playlist Validation: |
| |
OK |
| |
Segments: |
| |
OK |
| |
Average segment duration: 9.93 seconds |
Average segment bitrate: 1496114.70 bps |
Average segment structural overhead: 40250.70 bps (2.69 %) |
| |
-------------------------------------------------------------------------------- |
gear0/prog_index.m3u8 |
-------------------------------------------------------------------------------- |
| |
Playlist Validation: |
| |
OK |
| |
Segments: |
| |
OK |
| |
Average segment duration: 10.00 seconds |
Average segment bitrate: 41264.41 bps |
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 themediastreamvalidator 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 themediastreamvalidator. The bitrates are specified in theEXT-X-STREAM INF tag using theBANDWIDTH attribute.
Listing 3 Example Variant Playlist showing the BANDWIDTH attribute.
#EXTM3U |
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1280000 |
http://example.com/low.m3u8 |
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=2560000 |
http://example.com/mid.m3u8 |
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=7680000 |
http://example.com/hi.m3u8 |
See the HTTP Live Streaming Protocol Specification for more information about theBANDWIDTH attribute.
References
-
IETF Internet Draft of the HTTP Live Streaming Protocol Specification
-
Technical Note TN2218, 'Compressing QuickTime Movies for the Web'
-
Technical Note TN2262, 'Preparing Your Web Content for iPad'
-
Technical Note TN2288, 'Example Playlist Files for use with HTTP Live Streaming'
Document Revision History
| Date | Notes |
|---|---|
| 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 |
1232
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
