Article

HLS Authoring Specification for Apple Devices

Describes the requirements for live and VOD audio-video content delivery using HTTP Live Streaming (HLS) to Apple devices.

Overview

For a deeper discussion of the features available in HLS, please refer to Apple’s streaming resource page at http://developer.apple.com/streaming/, which contains pointers to the overview document, the HLS specification, technical notes, FAQs, presentations, and examples.

About HLS Authoring

The HLS specification is a published RFC [RFC8216]. However, HLS continues to evolve, so there is an updated draft specification - draft-pantos-hls-rfc8216bis [HLS2]. This document always uses the most recent version of the draft standard.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Testing Your Streams

Apple provides several command-line tools for HTTP Live Streaming. These can be obtained from https://developer.apple.com/download/more. (Once on that page, do a search for “http live streaming tools”.)

To assist in validating your streams use the command-line tools mediastreamvalidator and hlsreport.py. While these tools are unable to check everything about your streams, the checks they do are fairly comprehensive and we continue to improve the tools.

You should check the video quality of your streams by visual inspection. The mediastreamvalidator tool does not check video quality.

You should check playback of your streams under a variety of network conditions.

Using hlsreport

The script hlsreport.py is used to generate an HTML summary report from a JSON file that was generated by mediastreamvalidator. The report includes several tables with details about variants, renditions, and I-frame variants. Each table entry has a unique ‘stream ID’ number. A list of issues is included, divided into 'Must Fix' and 'Should Fix' categories according to this specification. The issues cross-reference individual variants and renditions using the unique stream IDs.

The simplest way to call it is:

hlsreport.py validation_data.json

where validation_data.json is the JSON file produced by mediastreamvalidator. This will produce a file called validation_data.html that is the report. You can change the name of the report file with the -o option:

hlsreport.py -o my_report.html validation_data.json

For further information, see the hlsreport(1) man page.

General Authoring Requirements

A stream that matches these requirements should be compatible with iOS, tvOS, or macOS.

Video

1. Video encoding requirements

1.1. All video MUST be encoded using H.264/AVC or HEVC/H.265.

1.2. The container format for H.264 video MUST be fragmented MP4 (fMP4) files or MPEG transport streams.

1.3. Profile and Level for H.264 MUST be less than or equal to High Profile, Level 4.2.

1.4. For H.264 you SHOULD use High Profile in preference to Main or Baseline Profile.

1.5. The container format for HEVC video MUST be fMP4.

1.6. Profile, Level, and Tier for HEVC MUST be less than or equal to Main10 Profile, Level 5.0, High Tier.

1.7. High Dynamic Range (HDR) HEVC video MUST be HDR10 or DolbyVision.

1.8. For HDR10 video, the SEI NAL units (i.e. static metadata) SHOULD be in the HEVC Configuration Box (‘hvcC’) and not in the individual sample data.

1.9. Profile and Level for Dolby Vision MUST be Profile 5 (single layer 10-bit HEVC) and less than or equal to Level 7.

1.10. You SHOULD use video formats in which the parameter sets are stored in the sample descriptions, rather than the samples. (i.e., Use ‘avc1’, ‘hvc1’, or ‘dvh1’ rather than ‘avc3’, ‘hev1’, or ‘dvhe’.)

1.11. For backward compatibility, content SHOULD NOT use a higher level than required by the content resolution and frame rate.

1.12. For backward compatibility, some video content SHOULD be encoded with H.264.

1.13. Key frames (IDRs) SHOULD be present every two seconds.

1.14. All interlaced source content MUST be de-interlaced.

1.15. You SHOULD de-interlace 30i content to 60p instead of 30p.

1.16. Live/linear video from NTSC or ATSC source SHOULD be 60 or 59.94 fps.

1.17. Live/linear video from PAL source SHOULD be 50 fps.

1.18. VOD content SHOULD use a natural frame rate for the content. Any of the typical frame rates: 23.976, 24, 25, 29.97, 30, 50, 59.94, and 60 fps are supported.

1.19. Frame rates above 60 fps SHALL NOT be used.

1.20. For HDR content, frame rates less than or equal to 30 fps SHOULD be provided.

1.21. Streams SHOULD use a single color space: one of either Rec. 601, Rec. 709, DCI-P3, or Rec. 2020.

1.22. For VOD, the color space SHOULD be the original color space of the material.

1.23. If multiple video streams are provided (H.264, HEVC, HDR), then each stream SHOULD provide all anticipated bandwidths. Clients SHOULD NOT be required to switch codecs.

1.24. For backward compatibility, SDR streams MUST be provided. (See also item 6.16)

1.25. There are many possible choices of bit rates for variants. The following tables provide one possible set of bit rate variants. (See On bit rates for variants for additional considerations.):

Table 8

Video average bit rate (kb/s) table 1

16:9 aspect ratio

H.264/AVC

Frame rate

416 x 234

145

≤ 30 fps

640 x 360

365

≤ 30 fps

768 x 432

730

≤ 30 fps

768 x 432

1100

≤ 30 fps

960 x 540

2000

same as source

1280 x 720

3000

same as source

1280 x 720

4500

same as source

1920 x 1080

6000

same as source

1920 x 1080

7800

same as source

Table 9

Video average bit rate (kb/s) table 2

16:9 aspect ratio

HEVC/H.265 30 fps

HDR (HEVC) 30 fps

Frame rate

640 x 360

145

160

≤ 30 fps

768 x 432

300

360

≤ 30 fps

960 x 540

600

730

≤ 30 fps

960 x 540

900

1090

≤ 30 fps

960 x 540

1600

1930

same as source

1280 x 720

2400

2900

same as source

1280 x 720

3400

3850

same as source

1920 x 1080

4500

5400

same as source

1920 x 1080

5800

7000

same as source

2560 x 1440

8100

9700

same as source

3840 x 2160

11600

13900

same as source

3840 x 2160

16800

20000

same as source

1.26. For VOD content, the average segment bit rate MUST be within 10% of the AVERAGE-BANDWIDTH attribute. (See Declared versus measured values of bandwidths.)

1.27. For VOD content, the measured peak bit rate MUST be within 10% of the BANDWIDTH attribute.

1.28. For live/linear content, the average segment bit rate over a long (~1 hour) period of time MUST be less than 110% of the AVERAGE-BANDWIDTH attribute.

1.29. For live/linear content, the measured peak bit rate MUST be less than 125% of the BANDWIDTH attribute.

1.30. For VOD content the peak bit rate SHOULD be no more than 200% of the average bit rate.

1.31. Different variants MAY have different frame rates.

1.32. The default video variant(s) SHOULD be the 2000 kb/s (average bit rate) variant. (Defaults are the first variant listed in the master playlist within a group of variants having compatible audio.)

1.33. All video variants SHOULD have identical aspect ratios.

Audio

2. Audio encoding requirements

2.1. Audio data SHOULD be provided as an elementary audio stream or in fMP4.

2.2. Stereo audio formats are:

  • AAC-LC

  • HE-AAC v1

  • HE-AAC v2

  • Multichannel formats that only carry stereo

2.3. Stereo audio in some AAC format MUST be provided.

2.4. You SHOULD NOT use HE-AAC if your audio bit rate is above 64 kb/s.

2.5. Supported multichannel audio formats are:

  • Dolby Digital (AC-3)

  • Dolby Digital Plus (E-AC-3)

  • Dolby Digital Plus with Dolby Atmos

2.6. If Dolby Digital Plus is provided and your streams are delivered to devices that do not support Dolby Digital Plus then Dolby Digital MUST be provided also. See Audio Compatibility.

2.7. Stereo audio MAY be provided at multiple bit rates

2.8. Multichannel audio MUST be provided at a single bit rate. (For example, don’t provide Dolby Digital 5.1 at two bit rates, but you may provide Dolby Digital 5.1 and Dolby Digital Plus 5.1.)

2.9. Overall bit rate recommendations are as follows:

Audio channels

Format

Total (kb/s)

2.0 (stereo)

AAC

32 to 160

2.0 (stereo)

Dolby Digital Plus

96 to 160

5.1 (surround)

Dolby Digital

384

5.1 (surround)

Dolby Digital Plus

192

7.1 (surround)

Dolby Digital Plus

384

Nominally 16

Dolby Digital Plus with Dolby Atmos

384 to 768

2.10. You MAY change channel layout within a stream.

2.11. Channel layout changes MUST be in conjunction with an EXT-X-DISCONTINUITY tag.

2.12. If you provide Descriptive Video Service (DVS), also called Audio Description, it MUST be marked with the attribute CHARACTERISTICS="public.accessibility.describes-video".

2.13. If you provide DVS, the AUTOSELECT attribute MUST have a value of “YES”.

2.14. The name of DVS audio SHOULD indicate that the stream is DVS content.

2.15. If you provide alternate audio or DVS, you MUST provide it for the entire content duration even if it only really exists for a portion of the main content.

2.16. Alternate audio or DVS MAY reuse the audio segments of regular content when the alternate content is not available.

2.17. A single media segment MUST NOT contain multiple audio streams.

2.18. Loudness management/Dynamic Range Control SHOULD be present unless all content (including ads) has been encoded at the same audio levels.

2.19. Dolby Digital and Dolby Digital Plus loudness SHOULD be specified by the dialnorm field (ATSC A/52:2012). 

2.20. AAC dialog loudness SHOULD be specified by either AAC prog_ref_level (ISO 14496-3 sub-clause 4.5.2.7), as specified by SCTE 193-1 section 7.4.1; OR by the loudnessInfo() payload as specified by ISO 23003-4, in which case samplePeakLevel or truePeakLevel MUST be present, measurementSystem MUST be 2, and methodDefinition MUST be 1 or 2.

2.21. HE-AAC in fMP4 files MUST use explicit signaling of SBR data.

Ads and Pre-/Mid-/Post-Rolls

3. Ad requirements (see also Media Playlists section)

3.1. Your ads and other inserted media SHOULD be included in the media playlists.

3.2. Inserted media SHOULD be encoded with the same codecs and aspect ratio as the other content in the Media Playlist.

3.3. Inserted media SHOULD be at or under the specified bandwidths for that variant.

Accessibility

4. Accessibility requirements

4.1. Captions SHOULD be provided with your streams to make content accessible to the deaf or hard of hearing.

4.2. Supported caption formats are:

  • CEA-608 closed captions

  • CEA-708 closed captions

  • WebVTT subtitles

  • IMSC1 subtitles (text profile only)

4.3. Closed captions (if any) MUST be included in the video media segments.

4.4. The presence of closed captions MUST be declared via an EXT-X-MEDIA tag that contains a LANGUAGE attribute.

4.5. If a subtitles track is intended to provide accessibility for the deaf and hard of hearing it MUST be marked with the attribute CHARACTERISTICS="public.accessibility.describes-music-and-sound". (Subtitles with this attribute value are treated the same as closed captions.)

4.6. If a subtitles track is intended to provide accessibility for the deaf and hard of hearing the AUTOSELECT attribute MUST have a value of “YES”.

4.7. The LANGUAGE attribute MUST be included in the EXT-X-MEDIA tag for a subtitles track.

4.8. For information on including Audio Descriptions with your streams, see items 2.12 through 2.16.

Subtitles

5. Subtitle requirements

5.1. Subtitles MAY be provided.

5.2. Subtitles MUST be WebVTT (according to the HLS specification) or IMSC1 in fMP4.

5.3. WebVTT subtitles MUST be in text files, with an X-TIMESTAMP-MAP according to the HLS specification.

5.4. IMSC1 subtitles MUST be in fMP4 files.

5.5. The subtitle playlist MUST exist for the entirety of the main content, even if the actual subtitles only exist for a portion of the content.

5.6. For live/linear content, target durations for subtitle playlists MUST be identical to other media.

5.7. For VOD content, target durations of subtitle playlists MAY be longer than the other media.

5.8. If the content has forced subtitles and regular subtitles in a given language, the regular subtitles track in that language MUST contain both the forced subtitles and the regular subtitles for that language.

5.9. If your videos contain text burnt into the video and you have access to a version without the burn-in, you SHOULD use Forced Subtitles instead. (This allows you to easily translate into multiple languages. An example of when you might use forced subtitles is a science fiction film, where alien languages are translated into English.)

5.10. The kind of subtitles SHOULD be specified in the CODECS attribute of the associated EXT-X-STREAM-INF tags. You SHOULD use “stpp.ttml.im1t” to identify IMSC1 subtitles. You MAY use “wvtt" to identify WebVTT subtitles.

5.11. Forced subtitles SHOULD always have AUTOSELECT=YES.

Trick Play

6. Trick play requirements

6.1. I-frame playlists (EXT-X-I-FRAME-STREAM-INF) MUST be provided to support scrubbing and scanning UI.

6.2. You SHOULD have one frame per second “dense” I-frame renditions. These are dedicated renditions that only contain I-frames.

6.3. Alternatively, you MAY use the I-frames from your normal content, but trick play performance is improved with a higher density of I-frames.

6.4. If you provide multiple bit rates at the same spatial resolution for your regular video then you SHOULD create the I-frame playlist for that resolution from the same source used for the lowest bit rate in that group.

6.5. The bit rate of I-frame playlists SHOULD be the bit rate of a normal playlist of the same resolution times the fps of the I-frame playlist divided by eight. (See I-frame bit rates versus normal bit rates.)

6.6. You SHOULD provide multiple I-frame Media Playlists with different bit rates.

6.7. As with normal video, there are many possible choices of bit rates for dense I-frame variants. The following tables provide one possible set of variants. (See On bit rates for variants.):

Table 11

Trick play average video bit rate (kb/s) table 1

16:9 aspect ratio

H.264/AVC

640 x 360

45

768 x 432

90

960 x 540

250

1280 x 720

375

1920 x 1080

580

16:9 aspect ratio

HEVC/H.265

HDR (HEVC)

768 x 432

40

55

960 x 540

75

94

960 x 540

200

238

1280 x 720

300

360

1920 x 1080

525

650

6.8. I-frame playlists MUST contain the EXT-X-I-FRAMES-ONLY tag.

6.9. The peak segment bit rate MUST be calculated according to the HLS specification.

6.10. If using fMP4, I-frame segments MUST include the 'moof' header associated with the I-frame.

6.11. For live/linear content, target durations for I-frame playlists MUST be identical to other media.

6.12. For VOD content, target durations of I-frame playlists MAY be different from the other media.

6.13. I-frame playlists MAY use a different video codec than the normal video segments.

6.14. For backward compatibility, some trick play content SHOULD be encoded with H.264.

6.15. If HDR trick play streams are provided, then they SHOULD be provided at all resolutions.

6.16. For backward compatibility, SDR trick play streams MUST be provided.

Media Segmentation

7. Media segmentation requirements

7.1. Your media MUST be continuous across segments, with the exception of transitions for ads and other inserted material.

7.2. If using a transport stream, continuity counters and timestamps MUST be sequential.

7.3. If using fMP4, the track fragment decode time MUST be consistent with the decode time and duration of the previous segment.

7.4. Video segments MUST start with an IDR frame.

7.5. Target durations SHOULD be 6 seconds.

7.6. Segment durations SHOULD be nominally 6 seconds (e.g., NTSC 29.97 may be 6.006 seconds).

7.7. Media segments MUST NOT exceed the target duration by more than 0.5 seconds.

Media Playlists

8. Media playlist requirements

8.1. You MUST use sufficiently accurate segment durations to ensure that the sum of the EXTINF durations of any contiguous group of segments is within one video frame duration of the actual duration of the content.

8.2. Audio and video playlists MUST all use the same target duration.

8.3. Audio and video playlists MUST contain the same duration of the content.

8.4. The EXT-X-PROGRAM-DATE-TIME tag MUST be present in every live/linear media playlist.

8.5. The date-time value of an EXT-X-PROGRAM-DATE-TIME tag SHOULD be aligned with the airtime of the content.

8.6. If your media playlists are created from static source content (VOD), you MUST add the EXT-X-PLAYLIST-TYPE with the value VOD.

8.7. Within one asset, all media playlists with an EXT-X-PLAYLIST-TYPE of VOD MUST cover exactly the same media time range.

8.8. If your media playlists are event style (start from a fixed point with segments never removed), you MUST add the EXT-X-PLAYLIST-TYPE with the value EVENT.

8.9. Separate audio streams MUST be declared using EXT-X-MEDIA tags.

8.10. The LANGUAGE attribute MUST be included in every EXT-X-MEDIA tag that does not have TYPE=VIDEO.

8.11. You MUST provide at least 6 segments in a live/linear playlist.

8.12. You SHOULD provide at least 15 minutes of content in a live/linear playlist.

8.13. Breaks of encoding continuity MUST be indicated with the EXT-X-DISCONTINUITY tag.

8.14. Video frame rate changes MUST be marked as a discontinuity using EXT-X-DISCONTINUITY tags.

8.15. All variants and renditions MUST have discontinuities at the same points in time.

8.16. You SHOULD avoid switching codecs at discontinuities. For example, switching between HEVC and H.264, or between AAC and Dolby Digital.

8.17. If live/linear content will ever contain an EXT-X-DISCONTINUITY tag then the EXT-X-DISCONTINUITY-SEQUENCE tag MUST always be present.

8.18. Your media requests MUST NOT use HTTP redirects, with the exception of ad content to allow dynamic selection of ads.

8.19. You SHOULD identify interstitial and program boundaries using the EXT-X-DATERANGE tag.

8.20. If using fMP4, EXT-X-MAP tags MUST be present.

8.21. Metadata SHOULD be in the playlist (using EXT-X-DATERANGE) rather than in the media (using Timed Metadata).

Master Playlist

9. Master playlist requirements

9.1. Your EXT-X-STREAM-INF tag MUST always provide the CODECS attribute.

9.2. Your EXT-X-STREAM-INF tag MUST always provide the RESOLUTION attribute if the rendition(s) include video.

9.3. Your EXT-X-I-FRAME-STREAM-INF tag MUST always provide the CODECS attribute.

9.4. Your EXT-X-I-FRAME-STREAM-INF tag MUST always provide the RESOLUTION attribute.

9.5. You SHOULD deliver video and audio as separate streams.

9.6. If you have multichannel audio, you MUST use separate audio streams.

9.7. If you have alternate audio content (languages/commentary/DVS), you MUST use separate audio streams.

9.8. If you have different video angles, you MUST use separate audio streams.

9.9. You MUST provide multiple bit rates of video (aka variants).

9.10. For HD content, there SHOULD be at least two variants encoded at the highest-available resolution.

9.11. If your video segments start with an IDR then you SHOULD use the EXT-X-INDEPENDENT-SEGMENTS tag in the master playlist. (See item 7.4.)

9.12. If your video segments start with an IDR and the EXT-X-INDEPENDENT-SEGMENTS tag is not in the master playlist, then you MUST use the EXT-X-INDEPENDENT-SEGMENTS tag in all video media playlists. (See item 7.4.)

9.13. The BANDWIDTH attribute MUST be the largest sum of peak segment bit rates that is produced by any playable combination of renditions.

9.14. You MUST include the AVERAGE-BANDWIDTH attribute.

9.15. Each EXT-X-STREAM-INF tag MUST have a FRAME-RATE attribute.

9.16. The VIDEO-RANGE attribute MUST be specified unless all variants and renditions are SDR.

Delivery

10. Delivery requirements

10.1. The server MUST deliver playlists using gzip content-encoding.

10.2. You SHOULD support stream failover, for example by listing duplicate streams in the Master Playlist.

10.3. Media data SHOULD NOT be delivered to the application through a local server.

Privacy

11. Privacy requirements

11.1. Master playlists SHOULD be delivered using Transport Layer Security (TLS).

11.2. Media playlists SHOULD be delivered using TLS.

11.3. Media Segments SHOULD be delivered using TLS.

11.4. Media Segment URLs requested over unencrypted transport SHOULD NOT contain revealing strings such as movie title, show title, episode name, episode number, genre, advertiser, or product.

Security

12. Security requirements

12.1. Transport Layer Security (TLS) MUST be version 1.2 with forward security.

12.2. TLS MUST NOT use known-insecure cryptographic primitives (e.g., RC4 encryption, SHA-1 certificate signatures).

12.3. Within TLS, key sizes MUST be 2048 bits for RSA and 256 bits for EC.

12.4. The URLs for Media Segments SHOULD not be completely static. URLs should be issued per device or changed over time.

Content Protection

13. Content protection requirements

13.1. Content protection of video and audio SHOULD follow the FairPlay Streaming (FPS) specification.

13.2. If the content is encrypted with FPS the method MUST be SAMPLE-AES.

13.3. If the content is encrypted with FPS  the key format MUST be "com.apple.streamingkeydelivery".

13.4. The IV attribute SHOULD NOT be used with FPS unless necessary for interoperability.

13.5. Content with HD resolutions SHOULD use HDCP-LEVEL of TYPE-0.

13.6. Content with greater than HD resolutions SHOULD use HDCP-LEVEL of TYPE-1.

Amended Requirements for tvOS

All general rules apply except as expressly modified by a rule with the same number in this section.

Video

1. Video encoding requirements

1.20. For HDR content, frame rates less than or equal to 30 fps MUST be provided.

1.25. The 145 kb/s variant SHOULD NOT be provided.

Trick Play

6. Trick play requirements

6.16. SDR trick play streams MUST be provided.

Media Playlists

8. Media playlist requirements

8.12. You SHOULD provide at least 120 minutes of content in a live/linear playlist.

Master Playlist

9. Master playlist requirements

9.17. You MUST have no audio-only variants listed in the Master playlist.

Amended Requirements for iOS

All general rules apply except as expressly modified by a rule with the same number in this section.

Video

1. Video encoding requirements

1.3. Profile and Level for H.264 MUST be less than or equal to High Profile, Level 5.0.

1.32.

1.32.a. For WiFi delivery, the default video variant(s) SHOULD be the 2000 kb/s (average bit rate) variant.

1.32.b. For cellular delivery, the default video variant(s) SHOULD be the 730 kb/s (average bit rate) variant.

Master Playlist

9. Master playlist requirements

9.18. Master playlists that are delivered over cellular networks MUST contain a variant whose peak BANDWIDTH is less than or equal to 192kb/s.

9.19. For backward compatibility, a peak 192kb/s H.264 variant packaged in a transport stream SHOULD be provided for cellular.

Amended Requirements for macOS

All general rules apply except as expressly modified by a rule with the same number in this section.

Video

1. Video encoding requirements

1.3. Profile and Level for H.264 MUST be less than or equal to High Profile, Level 5.0.

Declared versus measured values of bandwidths

VOD bit rates are measured over the entirety of the content.

Live/linear bit rates are measured over ~1 hour of content.

Table 1

Measured average bit rate versus AVERAGE-BANDWIDTH (attribute)

VOD

live/linear

Measured average bit rate

within 10% of attribute value

< 110% of attribute value

Table 2

Measured peak bit rate versus BANDWIDTH (attribute)

VOD

live/linear

Measured peak bit rate

within 10% of attribute value

< 125% of attribute value

Table 3

Measured peak bit rate versus measured average bit rate

VOD

live/linear

Measured peak bit rate

< 200% of measured average

no rule

Audio Compatibility

Additional information about device and audio format compatibility.

Device(s)

Pass-through AC-3

AC-3/E-AC-3

Dolby Digital Plus with Dolby Atmos

AppleTV (3rd Gen), iPhone 5, and iPhone 5C

Yes

No

No

iOS and tvOS devices A7-based or later*

Yes

Yes

Apple TV 4K only, otherwise plays as E-AC-3

All other iOS and tvOS devicesN

No

No

No

macOS devices

App specific

Yes

Plays as E-AC-3

See https://support.apple.com/specs/ for actual technical specifications.

*Complete support requires iOS 9.3 or tvOS 9.2 or later. Dolby Digital Plus with Dolby Atmos requires tvOS 12.0 or later.

On bit rates for variants

A number of factors affect the bit rate needed to encode video:

  • Codec (e.g., H.264 or HEVC)

  • Specific encoder implementation and features used

  • Resolution (e.g., 1920x1080,1280x720, and so on)

  • Frame rate (e.g., 24, 25, 30, 50, 60)

  • Bits per pixel (e.g., HDR typically uses more bits than SDR)

  • Complexity of the content

  • Desired subjective quality

These factors make universal encoding recommendations for content difficult. This specification includes initial bit rate recommendations that should be evaluated against your content, constraints and encoding workflow.

I-frame bit rates versus normal bit rates

The formula in 6.5 (for I-frame bit rates) requires some explanation.

During trick play, the player tries to deliver eight frames per second. If the playback rate implies a higher frame rate then frames will be dropped in order to keep the frame rate at eight frames per second. If fewer frames are available then it will play at a lower frame rate.

The I-frame bit rate is the bit rate of the rendition if it were played at normal speed.The I-frame rendition may be 2 fps, 1 fps, 0.5 fps, 0.2 fps, or something else. Let F be the frame rate of the I-frame rendition. Then, 8/F is the multiplier, that is, how much the bit rate is increased by playing the rendition at eight frames per second. The bit rate will never increase by more than this factor because we will never play more than eight frames per second.

We want the I-frame rendition to have an effective bit rate similar to the normal content.

So the normal bit rate divided by the multiplier should be the bit rate for the I-frame. Dividing by a fraction is the same as multiplying by its inverse, so we end up with 6.5 - “the bit rate of a normal playlist of the same resolution times the fps of the I-frame playlist divided by eight.”

Values for the CODECS attribute.

The CODECS attribute of the EXT-X-STREAM-INF tag (and EXT-X-I-FRAME-STREAM-INF) allows you specify media sample types. The value is a quoted-string containing a comma-separated list of formats, where each format specifies a media sample type that is present in a media segment of the playlist or in a media segment of some rendition that the tag references.

Valid format identifiers are those in the ISO File Format Name Space defined by RFC 6381. A format identifier is a sequence of elements separated by periods. The first element is the base sample type. The following values for the base sample type are currently recognized by Apple HLS:

Base Sample Type

Description

ac-3

AC-3 audio

avc1

H.264 (Advanced Video Coding)

dvh1

Dolby Vision (based on hvc1)

ec-3

Enchanced AC-3 audio

hvc1

HEVC (High Efficiency Video Coding)

mp4a

MPEG-4 audio

stpp

Subtitles (Timed Text)

wvtt

WebVTT data

The MP4 registration authority (mp4ra.org) lists a value of ec+3 for “Enhanced AC-3 audio with JOC”. That value is not used by HLS. Instead ec-3 is used and the presence of the additional JOC content is marked by the addition of JOC in the CHANNELS attribute of the audio rendition. For example, CHANNELS=“16/JOC".

The following table lists some example format values:

Sample Type

Description

ac-3

AC-3 audio

avc1.4200lf

H.264 Baseline Profile, Level 3.1 video

avc1.4d0028

H.264 Main Profile, Level 4.0 video

avc1.640029

H.264 High Profile, Level 4.1 video

dvh1.05.01

Dolby Vision Profile 5 (10-bit HEVC), Level 1 (720p24) video

dvh1.05.06

Dolby Vision Profile 5 (10-bit HEVC), Level 6 (2160p24) video

ec-3

Enhanced AC-3 audio

hvc1.1.4.L126.B0

HEVC Main Profile, Main Tier, Level 4.2 video

hvc1.2.4.L123.B0

HEVC Main-10 Profile, Main Tier, Level 4.1 video

hvc1.2.4.L150.B0

HEVC Main-10 Profile, Main Tier, Level 5.0 video

mp4a.40.2

AAC-LC audio

mp4a.40.5

HE-AAC audio

mp4a.40.29

HE-AACv2 audio

mp4a.40.34

MP3 audio

stpp.ttml.im1t

IMSC1 text-only subtitles

wvtt

WebVTT subtitles

Example playlist

Example of a playlist with Dolby Vision, HDR10, and SDR content, at resolutions from 720p to 4K.

#EXTM3U
#EXT-X-VERSION:7
#EXT-X-INDEPENDENT-SEGMENTS
#EXT-X-STREAM-INF:AVERAGE-BANDWIDTH=2778321,BANDWIDTH=3971374,VIDEO-RANGE=SDR,CODECS="hvc1.2.4.L123.B0",RESOLUTION=1280x720,FRAME-RATE=23.976,CLOSED-CAPTIONS=NONE,HDCP-LEVEL=NONE
sdr_720/prog_index.m3u8
#EXT-X-STREAM-INF:AVERAGE-BANDWIDTH=6759875,BANDWIDTH=10022043,VIDEO-RANGE=SDR,CODECS="hvc1.2.4.L123.B0",RESOLUTION=1920x1080,FRAME-RATE=23.976,CLOSED-CAPTIONS=NONE,HDCP-LEVEL=TYPE-0
sdr_1080/prog_index.m3u8
#EXT-X-STREAM-INF:AVERAGE-BANDWIDTH=20985770,BANDWIDTH=28058971,VIDEO-RANGE=SDR,CODECS="hvc1.2.4.L150.B0",RESOLUTION=3840x2160,FRAME-RATE=23.976,CLOSED-CAPTIONS=NONE,HDCP-LEVEL=TYPE-1
sdr_2160/prog_index.m3u8
#EXT-X-STREAM-INF:AVERAGE-BANDWIDTH=3385450,BANDWIDTH=5327059,VIDEO-RANGE=PQ,CODECS="dvh1.05.01",RESOLUTION=1280x720,FRAME-RATE=23.976,CLOSED-CAPTIONS=NONE,HDCP-LEVEL=NONE
dolby_720/prog_index.m3u8
#EXT-X-STREAM-INF:AVERAGE-BANDWIDTH=7999361,BANDWIDTH=12876596,VIDEO-RANGE=PQ,CODECS="dvh1.05.03",RESOLUTION=1920x1080,FRAME-RATE=23.976,CLOSED-CAPTIONS=NONE,HDCP-LEVEL=TYPE-0
dolby_1080/prog_index.m3u8
#EXT-X-STREAM-INF:AVERAGE-BANDWIDTH=24975091,BANDWIDTH=30041698,VIDEO-RANGE=PQ,CODECS="dvh1.05.06",RESOLUTION=3840x2160,FRAME-RATE=23.976,CLOSED-CAPTIONS=NONE,HDCP-LEVEL=TYPE-1
dolby_2160/prog_index.m3u8
#EXT-X-STREAM-INF:AVERAGE-BANDWIDTH=3320040,BANDWIDTH=5280654,VIDEO-RANGE=PQ,CODECS="hvc1.2.4.L123.B0",RESOLUTION=1280x720,FRAME-RATE=23.976,CLOSED-CAPTIONS=NONE,HDCP-LEVEL=NONE
hdr10_720/prog_index.m3u8
#EXT-X-STREAM-INF:AVERAGE-BANDWIDTH=7964551,BANDWIDTH=12886714,VIDEO-RANGE=PQ,CODECS="hvc1.2.4.L123.B0",RESOLUTION=1920x1080,FRAME-RATE=23.976,CLOSED-CAPTIONS=NONE,HDCP-LEVEL=TYPE-0
hdr10_1080/prog_index.m3u8
#EXT-X-STREAM-INF:AVERAGE-BANDWIDTH=24833402,BANDWIDTH=29983769,VIDEO-RANGE=PQ,CODECS="hvc1.2.4.L150.B0",RESOLUTION=3840x2160,FRAME-RATE=23.976,CLOSED-CAPTIONS=NONE,HDCP-LEVEL=TYPE-1
hdr10_2160/prog_index.m3u8
#EXT-X-I-FRAME-STREAM-INF:AVERAGE-BANDWIDTH=248586,BANDWIDTH=593626,VIDEO-RANGE=SDR,CODECS="hvc1.2.4.L123.B0",RESOLUTION=1280x720,HDCP-LEVEL=NONE,URI="sdr_720/iframe_index.m3u8"
#EXT-X-I-FRAME-STREAM-INF:AVERAGE-BANDWIDTH=399790,BANDWIDTH=956552,VIDEO-RANGE=SDR,CODECS="hvc1.2.4.L123.B0",RESOLUTION=1920x1080,HDCP-LEVEL=TYPE-0,URI="sdr_1080/iframe_index.m3u8"
#EXT-X-I-FRAME-STREAM-INF:AVERAGE-BANDWIDTH=826971,BANDWIDTH=1941397,VIDEO-RANGE=SDR,CODECS="hvc1.2.4.L150.B0",RESOLUTION=3840x2160,HDCP-LEVEL=TYPE-1,URI="sdr_2160/iframe_index.m3u8"
#EXT-X-I-FRAME-STREAM-INF:AVERAGE-BANDWIDTH=232253,BANDWIDTH=573073,VIDEO-RANGE=PQ,CODECS="dvh1.05.01",RESOLUTION=1280x720,HDCP-LEVEL=NONE,URI="dolby_720/iframe_index.m3u8"
#EXT-X-I-FRAME-STREAM-INF:AVERAGE-BANDWIDTH=365337,BANDWIDTH=905037,VIDEO-RANGE=PQ,CODECS="dvh1.05.03",RESOLUTION=1920x1080,HDCP-LEVEL=TYPE-0,URI="dolby_1080/iframe_index.m3u8"
#EXT-X-I-FRAME-STREAM-INF:AVERAGE-BANDWIDTH=739114,BANDWIDTH=1893236,VIDEO-RANGE=PQ,CODECS="dvh1.05.06",RESOLUTION=3840x2160,HDCP-LEVEL=TYPE-1,URI="dolby_2160/iframe_index.m3u8"
#EXT-X-I-FRAME-STREAM-INF:AVERAGE-BANDWIDTH=232511,BANDWIDTH=572673,VIDEO-RANGE=PQ,CODECS="hvc1.2.4.L123.B0",RESOLUTION=1280x720,HDCP-LEVEL=NONE,URI="hdr10_720/iframe_index.m3u8"
#EXT-X-I-FRAME-STREAM-INF:AVERAGE-BANDWIDTH=364552,BANDWIDTH=905053,VIDEO-RANGE=PQ,CODECS="hvc1.2.4.L123.B0",RESOLUTION=1920x1080,HDCP-LEVEL=TYPE-0,URI="hdr10_1080/iframe_index.m3u8"
#EXT-X-I-FRAME-STREAM-INF:AVERAGE-BANDWIDTH=739757,BANDWIDTH=1895477,VIDEO-RANGE=PQ,CODECS="hvc1.2.4.L150.B0",RESOLUTION=3840x2160,HDCP-LEVEL=TYPE-1,URI="hdr10_2160/iframe_index.m3u8"

The HEVC codec values are described in ISO/IEC 14496-15.

A short description is “Codec.Profile.Flags.TierLevel.Constraints”, so in “hvc1.2.4.L123.B0”, the “2” means Main 10 profile, and the “L123” means normal tier, level 4.1.

The Dolby Video codec values are described in the document Dolby Vision streams within the HTTP Live Streaming format v1.1.

A short description is “Codec.Profile.Level”, so in “dvh1.05.03” the Profile is 5 and the Level is 3.

Revision History

The following table describes the changes to the HLS Authoring Specification for Apple Devices.

Date

Notes

2018/06/18

Added Dolby Digital Plus with Dolby Atmos information. Added codec value section.

2018/04/09

Made several minor changes to individual spec points. Updated the variant bit-rate table and broke it into two separate tables.

2018/01/16

Fixed several typos and made a couple of minor changes to audio encoding requirements.

2017/09/19

Updated document with HDR (HEVC) information.

2017/06/06

Updated document with HEVC/H.265 information.

2016/09/13

Added rules for fragmented MP4 files.

2016/06/13

Updated for iOS and macOS specifications.

2016/03/21

Updated Dolby Digital bit-rate recommendation to 384 kpbs.

2016/01/11

Fixed typo in section 10.2.

2015/12/17

Added section on using the hlsreport tool.

2015/12/08

Corrects a mistake in Table 2-3, Column 2 heading. Changed to 16:9 aspect from 19:0.

2015/10/21

New document describing the HTTP Live Streaming specifications for audio and video content delivery for Apple TV.

See Also

Specifications and Other Documents

About the Common Media Application Format with HTTP Live Streaming

Understand the Common Media Application Format as it applies to HTTP Live Streaming

Links to Additional Specifications and Videos

Contains links to additional specifications and documents.

Videos about HLS

Contains links to informational videos.