RFC 8216
HTTP Live Streaming
6. Client/Server Responsibilities
6.1. Introduction
This section describes how the server generates the Playlist and Media Segments and how the client should download them for playback.6.2. Server Responsibilities
6.2.1. General Server Responsibilities
The production of the source media is outside the scope of this document, which simply presumes a source of continuous encoded media containing the presentation. The server MUST divide the source media into individual Media Segments whose duration is less than or equal to a constant target duration. Segments that are longer than the planned target duration can trigger playback stalls and other errors.
The server SHOULD attempt to divide the source media at points that support effective decode of individual Media Segments, e.g., on packet and key frame boundaries. The server MUST create a URI for every Media Segment that enables its clients to obtain the segment data. If a server supports partial loading of resources (e.g., via HTTP Range requests), it MAY specify segments as sub-ranges of larger resources using the EXT-X-BYTERANGE tag. Any Media Segment that is specified in a Playlist loaded by a client MUST be available for immediate download, or playback errors can occur. Once download starts, its transfer rate SHOULD NOT be constrained by the segment production process. HTTP servers SHOULD transfer text files -- such as Playlists and WebVTT segments -- using the "gzip" Content-Encoding if the client indicates that it is prepared to accept it. The server must create a Media Playlist file (Section 4) that contains a URI for each Media Segment that the server wishes to make available, in the order in which they are to be played. The value of the EXT-X-VERSION tag (Section 4.3.1.2) SHOULD NOT be greater than what is required for the tags and attributes in the Playlist (see Section 7). Changes to the Playlist file MUST be made atomically from the point of view of the clients, or playback errors MAY occur. The server MUST NOT change the Media Playlist file, except to: o Append lines to it (Section 6.2.1). o Remove Media Segment URIs from the Playlist in the order that they appear, along with any tags that apply only to those segments (Section 6.2.2). o Increment the value of the EXT-X-MEDIA-SEQUENCE or EXT-X- DISCONTINUITY-SEQUENCE tags (Section 6.2.2). o Add an EXT-X-ENDLIST tag to the Playlist (Section 6.2.1).
A Media Playlist has further constraints on its updates if it contains an EXT-X-PLAYLIST-TYPE tag. An EXT-X-PLAYLIST-TYPE tag with a value of VOD indicates that the Playlist file MUST NOT change. An EXT-X-PLAYLIST-TYPE tag with a value of EVENT indicates that the server MUST NOT change or delete any part of the Playlist file; it MAY append lines to it. The value of the EXT-X-TARGETDURATION tag in the Media Playlist MUST NOT change. A typical target duration is 10 seconds. Playlist changes other than those allowed here can trigger playback errors and inconsistent client behavior. Each Media Segment in a Media Playlist has an integer Discontinuity Sequence Number. The Discontinuity Sequence Number can be used in addition to the timestamps within the media to synchronize Media Segments across different Renditions. A segment's Discontinuity Sequence Number is the value of the EXT-X- DISCONTINUITY-SEQUENCE tag (or zero if none) plus the number of EXT- X-DISCONTINUITY tags in the Playlist preceding the URI line of the segment. The server MAY associate an absolute date and time with a Media Segment by applying an EXT-X-PROGRAM-DATE-TIME tag to it. This defines an informative mapping of the (wall-clock) date and time specified by the tag to the first media timestamp in the segment, which may be used as a basis for seeking, for display, or for other purposes. If a server provides this mapping, it SHOULD apply an EXT- X-PROGRAM-DATE-TIME tag to every segment that has an EXT- X-DISCONTINUITY tag applied to it. The Server MUST NOT add any EXT-X-PROGRAM-DATE-TIME tag to a Playlist that would cause the mapping between program date and Media Segment to become ambiguous. The server MUST NOT remove an EXT-X-DATERANGE tag from a Playlist if any date in the range maps to a Media Segment in the Playlist. The server MUST NOT reuse the ID attribute value of an EXT- X-DATERANGE tag for any new Date Range in the same Playlist. Once the Following Range of a Date Range with an END-ON-NEXT=YES attribute is added to a Playlist, the Server MUST NOT subsequently add a Date Range with the same CLASS attribute whose START-DATE is between that of the END-ON-NEXT=YES range and its Following Range.
For Date Ranges with a PLANNED-DURATION attribute, the Server SHOULD signal the actual end of the range once it has been established. It can do so by adding another EXT-X-DATERANGE tag with the same ID attribute value and either a DURATION or an END-DATE attribute or, if the Date Range has an END-ON-NEXT=YES attribute, by adding a Following Range. If the Media Playlist contains the final Media Segment of the presentation, then the Playlist file MUST contain the EXT-X-ENDLIST tag; this allows clients to minimize unproductive Playlist reloads. If a Media Playlist does not contain the EXT-X-ENDLIST tag, the server MUST make a new version of the Playlist file available that contains at least one new Media Segment. It MUST be made available relative to the time that the previous version of the Playlist file was made available: no earlier than one-half the target duration after that time, and no later than 1.5 times the target duration after that time. This allows clients to utilize the network efficiently. If the server wishes to remove an entire presentation, it SHOULD provide a clear indication to clients that the Playlist file is no longer available (e.g., with an HTTP 404 or 410 response). It MUST ensure that all Media Segments in the Playlist file remain available to clients for at least the duration of the Playlist file at the time of removal to prevent interruption of in-progress playback.6.2.2. Live Playlists
The server MAY limit the availability of Media Segments by removing Media Segments from the Playlist file (Section 6.2.1). If Media Segments are to be removed, the Playlist file MUST contain an EXT-X- MEDIA-SEQUENCE tag. Its value MUST be incremented by 1 for every Media Segment that is removed from the Playlist file; it MUST NOT decrease or wrap. Clients can malfunction if each Media Segment does not have a consistent, unique Media Sequence Number. Media Segments MUST be removed from the Playlist file in the order that they appear in the Playlist; otherwise, client playback can malfunction. The server MUST NOT remove a Media Segment from a Playlist file without an EXT-X-ENDLIST tag if that would produce a Playlist whose duration is less than three times the target duration. Doing so can trigger playback stalls.
When the server removes a Media Segment URI from the Playlist, the corresponding Media Segment MUST remain available to clients for a period of time equal to the duration of the segment plus the duration of the longest Playlist file distributed by the server containing that segment. Removing a Media Segment earlier than that can interrupt in-progress playback. If the server wishes to remove segments from a Media Playlist containing an EXT-X-DISCONTINUITY tag, the Media Playlist MUST contain an EXT-X-DISCONTINUITY-SEQUENCE tag. Without the EXT-X- DISCONTINUITY-SEQUENCE tag, it can be impossible for a client to locate corresponding segments between Renditions. If the server removes an EXT-X-DISCONTINUITY tag from the Media Playlist, it MUST increment the value of the EXT-X-DISCONTINUITY- SEQUENCE tag so that the Discontinuity Sequence Numbers of the segments still in the Media Playlist remain unchanged. The value of the EXT-X-DISCONTINUITY-SEQUENCE tag MUST NOT decrease or wrap. Clients can malfunction if each Media Segment does not have a consistent Discontinuity Sequence Number. If a server plans to remove a Media Segment after it is delivered to clients over HTTP, it SHOULD ensure that the HTTP response contains an Expires header that reflects the planned time-to-live. A Live Playlist MUST NOT contain the EXT-X-PLAYLIST-TYPE tag, as no value of that tag allows Media Segments to be removed.6.2.3. Encrypting Media Segments
Media Segments MAY be encrypted. Every encrypted Media Segment MUST have an EXT-X-KEY tag (Section 4.3.2.4) applied to it with a URI that the client can use to obtain a Key file (Section 5) containing the decryption key. A Media Segment can only be encrypted with one encryption METHOD, using one encryption key and IV. However, a server MAY offer multiple ways to retrieve that key by providing multiple EXT-X-KEY tags, each with a different KEYFORMAT attribute value. The server MAY set the HTTP Expires header in the key response to indicate the duration for which the key can be cached. Any unencrypted Media Segment in a Playlist that is preceded by an encrypted Media Segment MUST have an EXT-X-KEY tag applied to it with a METHOD attribute of NONE. Otherwise, the client will misinterpret those segments as encrypted.
If the encryption METHOD is AES-128 and the Playlist does not contain the EXT-X-I-FRAMES-ONLY tag, AES encryption as described in Section 4.3.2.4 SHALL be applied to individual Media Segments. If the encryption METHOD is AES-128 and the Playlist contains an EXT- X-I-FRAMES-ONLY tag, the entire resource MUST be encrypted using AES-128 CBC with PKCS7 padding [RFC5652]. Encryption MAY be restarted on 16-byte block boundaries, unless the first block contains an I-frame. The IV used for encryption MUST be either the Media Sequence Number of the Media Segment or the value of the IV attribute of the EXT-X-KEY tag, as described in Section 5.2. These constraints allow a client to load and decrypt individual I-frames specified as sub-ranges of regular encrypted Media Segments, and their Media Initialization Sections. If the encryption METHOD is SAMPLE-AES, media samples MAY be encrypted prior to encapsulation in a Media Segment. The server MUST NOT remove an EXT-X-KEY tag from the Playlist file if it applies to any Media Segment in the Playlist file, or clients who subsequently load that Playlist will be unable to decrypt those Media Segments.6.2.4. Providing Variant Streams
A server MAY offer multiple Media Playlist files to provide different encodings of the same presentation. If it does so, it SHOULD provide a Master Playlist file that lists each Variant Stream to allow clients to switch between encodings dynamically. Master Playlists describe regular Variant Streams with EXT-X-STREAM- INF tags and I-frame Variant Streams with EXT-X-I-FRAME-STREAM-INF tags. If an EXT-X-STREAM-INF tag or EXT-X-I-FRAME-STREAM-INF tag contains the CODECS attribute, the attribute value MUST include every media format [RFC6381] present in any Media Segment in any of the Renditions specified by the Variant Stream.
The server MUST meet the following constraints when producing Variant
Streams in order to allow clients to switch between them seamlessly:
o Each Variant Stream MUST present the same content.
o Matching content in Variant Streams MUST have matching timestamps.
This allows clients to synchronize the media.
o Matching content in Variant Streams MUST have matching
Discontinuity Sequence Numbers (see Section 4.3.3.3).
o Each Media Playlist in each Variant Stream MUST have the same
target duration. The only exceptions are SUBTITLES Renditions and
Media Playlists containing an EXT-X-I-FRAMES-ONLY tag, which MAY
have different target durations if they have an EXT-X-PLAYLIST-
TYPE of VOD.
o Content that appears in a Media Playlist of one Variant Stream but
not in another MUST appear either at the beginning or at the end
of the Media Playlist file and MUST NOT be longer than the target
duration.
o If any Media Playlists have an EXT-X-PLAYLIST-TYPE tag, all Media
Playlists MUST have an EXT-X-PLAYLIST-TYPE tag with the same
value.
o If the Playlist contains an EXT-X-PLAYLIST-TYPE tag with the value
of VOD, the first segment of every Media Playlist in every Variant
Stream MUST start at the same media timestamp.
o If any Media Playlist in a Master Playlist contains an EXT-X-
PROGRAM-DATE-TIME tag, then all Media Playlists in that Master
Playlist MUST contain EXT-X-PROGRAM-DATE-TIME tags with consistent
mappings of date and time to media timestamps.
o Each Variant Stream MUST contain the same set of Date Ranges, each
one identified by an EXT-X-DATERANGE tag(s) with the same ID
attribute value and containing the same set of attribute/value
pairs.
In addition, for broadest compatibility, Variant Streams SHOULD
contain the same encoded audio bitstream. This allows clients to
switch between Variant Streams without audible glitching.
The rules for Variant Streams also apply to alternative Renditions
(see Section 4.3.4.2.1).
6.3. Client Responsibilities
6.3.1. General Client Responsibilities
How the client obtains the URI to the Playlist file is outside the scope of this document; it is presumed to have done so. The client obtains the Playlist file from the URI. If the Playlist file so obtained is a Master Playlist, the client can select a Variant Stream to load from the Master Playlist. Clients MUST ensure that loaded Playlists comply with Section 4 and that the EXT-X-VERSION tag, if present, specifies a protocol version supported by the client; if either check fails, the client MUST NOT attempt to use the Playlist, or unintended behavior could occur. If any URI element in a Playlist contains an URI scheme that the client cannot handle, the client MUST stop playback. All clients MUST support HTTP schemes. To support forward compatibility, when parsing Playlists, clients MUST: o ignore any unrecognized tags. o ignore any attribute/value pair with an unrecognized AttributeName. o ignore any tag containing an attribute/value pair of type enumerated-string whose AttributeName is recognized but whose AttributeValue is not recognized, unless the definition of the attribute says otherwise. Algorithms used by the client to switch between Variant Streams are beyond the scope of this document.6.3.2. Loading the Media Playlist File
Every time a Media Playlist is loaded or reloaded from a Playlist URI, the client MUST determine the next Media Segment to load, as described in Section 6.3.5, if it intends to play the presentation normally (i.e., in Playlist order at the nominal playback rate). If the Media Playlist contains the EXT-X-MEDIA-SEQUENCE tag, the client SHOULD assume that each Media Segment in it will become unavailable at the time that the Playlist file was loaded plus the duration of the Playlist file.
A client MAY use the segment Media Sequence Number to track the location of a Media Segment within a Playlist when the Playlist is reloaded. A client MUST NOT assume that segments with the same Media Sequence Number in different Variant Streams or Renditions have the same position in the presentation; Playlists MAY have independent Media Sequence Numbers. Instead, a client MUST use the relative position of each segment on the Playlist timeline and its Discontinuity Sequence Number to locate corresponding segments. A client MUST load the Media Playlist file of every Rendition selected for playback in order to locate the media specific to that Rendition. But, to prevent unnecessary load on the server, it SHOULD NOT load the Playlist file of any other Rendition. For some Variant Streams, it is possible to select Renditions that do not include the Rendition specified by the EXT-X-STREAM-INF tag. As noted above, the client SHOULD NOT load that Rendition in those cases.6.3.3. Playing the Media Playlist File
The client SHALL choose which Media Segment to play first from the Media Playlist when playback starts. If the EXT-X-ENDLIST tag is not present and the client intends to play the media normally, the client SHOULD NOT choose a segment that starts less than three target durations from the end of the Playlist file. Doing so can trigger playback stalls. Normal playback can be achieved by playing the Media Segments in the order that they appear in the Playlist. The client MAY present the available media in any way it wishes, including normal playback, random access, and trick modes. The encoding parameters for samples in a Media Segment and across multiple Media Segments in a Media Playlist SHOULD remain consistent. However, clients SHOULD deal with encoding changes as they are encountered, for example, by scaling video content to accommodate a resolution change. If the Variant Stream includes a RESOLUTION attribute, clients SHOULD display all video within a rectangle with the same proportions as that resolution. Clients SHOULD be prepared to handle multiple tracks of a particular type (e.g., audio or video). A client with no other preference SHOULD choose the track with the lowest numerical track identifier that it can play.
Clients SHOULD ignore private streams inside Transport Streams that they do not recognize. Private streams can be used to support different devices with the same stream, although stream authors SHOULD be sensitive to the additional network load that this imposes. The client MUST be prepared to reset its parser(s) and decoder(s) before playing a Media Segment that has an EXT-X-DISCONTINUITY tag applied to it; otherwise, playback errors can occur. The client SHOULD attempt to load Media Segments in advance of when they will be required for uninterrupted playback to compensate for temporary variations in latency and throughput. The client MAY use the value of the EXT-X-PROGRAM-DATE-TIME tag to display the program origination time to the user. If the value includes time zone information, the client SHALL take it into account; if it does not, the client MAY assume the time to be local. Note that dates in Playlists can refer to when the content was produced (or to other times), which have no relation to the time of playback. If the first EXT-X-PROGRAM-DATE-TIME tag in a Playlist appears after one or more Media Segment URIs, the client SHOULD extrapolate backward from that tag (using EXTINF durations and/or media timestamps) to associate dates with those segments. To associate a date with any other Media Segment that does not have an EXT-X- PROGRAM-DATE-TIME tag applied to it directly, the client SHOULD extrapolate forward from the last EXT-X-PROGRAM-DATE-TIME tag appearing before that segment in the Playlist.6.3.4. Reloading the Media Playlist File
The client MUST periodically reload a Media Playlist file to learn what media is currently available, unless it contains an EXT-X- PLAYLIST-TYPE tag with a value of VOD, or a value of EVENT and the EXT-X-ENDLIST tag is also present. However, the client MUST NOT attempt to reload the Playlist file more frequently than specified by this section, in order to limit the collective load on the server. When a client loads a Playlist file for the first time or reloads a Playlist file and finds that it has changed since the last time it was loaded, the client MUST wait for at least the target duration before attempting to reload the Playlist file again, measured from the last time the client began loading the Playlist file.
If the client reloads a Playlist file and finds that it has not changed, then it MUST wait for a period of one-half the target duration before retrying. After reloading a Media Playlist, the client SHOULD verify that each Media Segment in it has the same URI (and byte range, if specified) as the Media Segment with the same Media Sequence Number in the previous Media Playlist. It SHOULD halt playback if it does not, as this normally indicates a server error. In order to reduce server load, the client SHOULD NOT reload the Playlist files of Variant Streams or alternate Renditions that are not currently being played. If it decides to switch playback to a different Variant Stream, it SHOULD stop reloading the Playlist of the old Variant Stream and begin loading the Playlist of the new Variant Stream. It can use the EXTINF durations and the constraints in Section 6.2.4 to determine the approximate location of corresponding media. Once media from the new Variant Stream has been loaded, the timestamps in the Media Segments can be used to synchronize the old and new timelines precisely. A client MUST NOT attempt to use the Media Sequence Number to synchronize between streams (see Section 6.3.2).6.3.5. Determining the Next Segment to Load
The client MUST examine the Media Playlist file every time it is loaded or reloaded to determine the next Media Segment to load, as the set of available media MAY have changed. The first segment to load is generally the segment that the client has chosen to play first (see Section 6.3.3). In order to play the presentation normally, the next Media Segment to load is the one with the lowest Media Sequence Number that is greater than the Media Sequence Number of the last Media Segment loaded.6.3.6. Decrypting Encrypted Media Segments
If a Media Playlist file contains an EXT-X-KEY tag that specifies a Key file URI, the client can obtain that Key file and use the key inside it to decrypt all Media Segments to which that EXT-X-KEY tag applies.
A client MUST ignore any EXT-X-KEY tag with an unsupported or unrecognized KEYFORMAT attribute, to allow for cross-device addressability. If the Playlist contains a Media Segment to which only EXT-X-KEY tags with unrecognized or unsupported KEYFORMAT attributes are applied, playback SHOULD fail. A client MUST NOT attempt to decrypt any segments whose EXT-X-KEY tag has a METHOD attribute that it does not recognize. If the encryption METHOD is AES-128, AES-128 CBC decryption SHALL be applied to individual Media Segments, whose encryption format is described in Section 4.3.2.4. If the encryption METHOD is AES-128 and the Media Segment is part of an I-frame Playlist (Section 4.3.3.6) and it has an EXT-X-BYTERANGE tag applied to it, special care needs to be taken in loading and decrypting the segment, because the resource identified by the URI is encrypted in 16-byte blocks from the start of the resource. The decrypted I-frame can be recovered by first widening its byte range, as specified by the EXT-X-BYTERANGE tag, so that it starts and ends on 16-byte boundaries from the start of the resource. Next, the byte range is widened further to include a 16-byte block at the beginning of the range. This 16-byte block allows the correct IV for the following block to be calculated. The widened byte range can then be loaded and decrypted with AES-128 CBC using an arbitrary IV. The number of bytes added to the beginning and the end of the original byte range are discarded from the decrypted bytes; what remains is the decrypted I-frame. If the encryption METHOD is SAMPLE-AES, AES-128 decryption SHALL be applied to encrypted media samples within the Media Segment. An EXT-X-KEY tag with a METHOD of NONE indicates that the Media Segments it applies to are not encrypted.7. Protocol Version Compatibility
Protocol compatibility is specified by the EXT-X-VERSION tag. A Playlist that contains tags or attributes that are not compatible with protocol version 1 MUST include an EXT-X-VERSION tag. A client MUST NOT attempt playback if it does not support the protocol version specified by the EXT-X-VERSION tag, or unintended behavior could occur.
A Media Playlist MUST indicate an EXT-X-VERSION of 2 or higher if it
contains:
o The IV attribute of the EXT-X-KEY tag.
A Media Playlist MUST indicate an EXT-X-VERSION of 3 or higher if it
contains:
o Floating-point EXTINF duration values.
A Media Playlist MUST indicate an EXT-X-VERSION of 4 or higher if it
contains:
o The EXT-X-BYTERANGE tag.
o The EXT-X-I-FRAMES-ONLY tag.
A Media Playlist MUST indicate an EXT-X-VERSION of 5 or higher if it
contains:
o The KEYFORMAT and KEYFORMATVERSIONS attributes of the EXT-X-KEY
tag.
o The EXT-X-MAP tag.
A Media Playlist MUST indicate an EXT-X-VERSION of 6 or higher if it
contains:
o The EXT-X-MAP tag in a Media Playlist that does not contain EXT-
X-I-FRAMES-ONLY.
A Master Playlist MUST indicate an EXT-X-VERSION of 7 or higher if it
contains:
o "SERVICE" values for the INSTREAM-ID attribute of the EXT-X-MEDIA
tag.
The EXT-X-MEDIA tag and the AUDIO, VIDEO, and SUBTITLES attributes of
the EXT-X-STREAM-INF tag are backward compatible to protocol version
1, but playback on older clients may not be desirable. A server MAY
consider indicating an EXT-X-VERSION of 4 or higher in the Master
Playlist but is not required to do so.
The PROGRAM-ID attribute of the EXT-X-STREAM-INF and the EXT-X-I-
FRAME-STREAM-INF tags was removed in protocol version 6.
The EXT-X-ALLOW-CACHE tag was removed in protocol version 7.
8. Playlist Examples
8.1. Simple Media Playlist
#EXTM3U #EXT-X-TARGETDURATION:10 #EXT-X-VERSION:3 #EXTINF:9.009, http://media.example.com/first.ts #EXTINF:9.009, http://media.example.com/second.ts #EXTINF:3.003, http://media.example.com/third.ts #EXT-X-ENDLIST8.2. Live Media Playlist Using HTTPS
#EXTM3U #EXT-X-VERSION:3 #EXT-X-TARGETDURATION:8 #EXT-X-MEDIA-SEQUENCE:2680 #EXTINF:7.975, https://priv.example.com/fileSequence2680.ts #EXTINF:7.941, https://priv.example.com/fileSequence2681.ts #EXTINF:7.975, https://priv.example.com/fileSequence2682.ts
8.3. Playlist with Encrypted Media Segments
#EXTM3U #EXT-X-VERSION:3 #EXT-X-MEDIA-SEQUENCE:7794 #EXT-X-TARGETDURATION:15 #EXT-X-KEY:METHOD=AES-128,URI="https://priv.example.com/key.php?r=52" #EXTINF:2.833, http://media.example.com/fileSequence52-A.ts #EXTINF:15.0, http://media.example.com/fileSequence52-B.ts #EXTINF:13.333, http://media.example.com/fileSequence52-C.ts #EXT-X-KEY:METHOD=AES-128,URI="https://priv.example.com/key.php?r=53" #EXTINF:15.0, http://media.example.com/fileSequence53-A.ts8.4. Master Playlist
#EXTM3U #EXT-X-STREAM-INF:BANDWIDTH=1280000,AVERAGE-BANDWIDTH=1000000 http://example.com/low.m3u8 #EXT-X-STREAM-INF:BANDWIDTH=2560000,AVERAGE-BANDWIDTH=2000000 http://example.com/mid.m3u8 #EXT-X-STREAM-INF:BANDWIDTH=7680000,AVERAGE-BANDWIDTH=6000000 http://example.com/hi.m3u8 #EXT-X-STREAM-INF:BANDWIDTH=65000,CODECS="mp4a.40.5" http://example.com/audio-only.m3u88.5. Master Playlist with I-Frames
#EXTM3U #EXT-X-STREAM-INF:BANDWIDTH=1280000 low/audio-video.m3u8 #EXT-X-I-FRAME-STREAM-INF:BANDWIDTH=86000,URI="low/iframe.m3u8" #EXT-X-STREAM-INF:BANDWIDTH=2560000 mid/audio-video.m3u8 #EXT-X-I-FRAME-STREAM-INF:BANDWIDTH=150000,URI="mid/iframe.m3u8" #EXT-X-STREAM-INF:BANDWIDTH=7680000 hi/audio-video.m3u8 #EXT-X-I-FRAME-STREAM-INF:BANDWIDTH=550000,URI="hi/iframe.m3u8" #EXT-X-STREAM-INF:BANDWIDTH=65000,CODECS="mp4a.40.5" audio-only.m3u8
8.6. Master Playlist with Alternative Audio
In this example, the CODECS attributes have been condensed for space. A '\' is used to indicate that the tag continues on the following line with whitespace removed: #EXTM3U #EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="aac",NAME="English", \ DEFAULT=YES,AUTOSELECT=YES,LANGUAGE="en", \ URI="main/english-audio.m3u8" #EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="aac",NAME="Deutsch", \ DEFAULT=NO,AUTOSELECT=YES,LANGUAGE="de", \ URI="main/german-audio.m3u8" #EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="aac",NAME="Commentary", \ DEFAULT=NO,AUTOSELECT=NO,LANGUAGE="en", \ URI="commentary/audio-only.m3u8" #EXT-X-STREAM-INF:BANDWIDTH=1280000,CODECS="...",AUDIO="aac" low/video-only.m3u8 #EXT-X-STREAM-INF:BANDWIDTH=2560000,CODECS="...",AUDIO="aac" mid/video-only.m3u8 #EXT-X-STREAM-INF:BANDWIDTH=7680000,CODECS="...",AUDIO="aac" hi/video-only.m3u8 #EXT-X-STREAM-INF:BANDWIDTH=65000,CODECS="mp4a.40.5",AUDIO="aac" main/english-audio.m3u88.7. Master Playlist with Alternative Video
This example shows three different video Renditions (Main, Centerfield, and Dugout) and three different Variant Streams (low, mid, and high). In this example, clients that did not support the EXT-X-MEDIA tag and the VIDEO attribute of the EXT-X-STREAM-INF tag would only be able to play the video Rendition "Main". Since the EXT-X-STREAM-INF tag has no AUDIO attribute, all video Renditions would be required to contain the audio.
In this example, the CODECS attributes have been condensed for space.
A '\' is used to indicate that the tag continues on the following
line with whitespace removed:
#EXTM3U
#EXT-X-MEDIA:TYPE=VIDEO,GROUP-ID="low",NAME="Main", \
DEFAULT=YES,URI="low/main/audio-video.m3u8"
#EXT-X-MEDIA:TYPE=VIDEO,GROUP-ID="low",NAME="Centerfield", \
DEFAULT=NO,URI="low/centerfield/audio-video.m3u8"
#EXT-X-MEDIA:TYPE=VIDEO,GROUP-ID="low",NAME="Dugout", \
DEFAULT=NO,URI="low/dugout/audio-video.m3u8"
#EXT-X-STREAM-INF:BANDWIDTH=1280000,CODECS="...",VIDEO="low"
low/main/audio-video.m3u8
#EXT-X-MEDIA:TYPE=VIDEO,GROUP-ID="mid",NAME="Main", \
DEFAULT=YES,URI="mid/main/audio-video.m3u8"
#EXT-X-MEDIA:TYPE=VIDEO,GROUP-ID="mid",NAME="Centerfield", \
DEFAULT=NO,URI="mid/centerfield/audio-video.m3u8"
#EXT-X-MEDIA:TYPE=VIDEO,GROUP-ID="mid",NAME="Dugout", \
DEFAULT=NO,URI="mid/dugout/audio-video.m3u8"
#EXT-X-STREAM-INF:BANDWIDTH=2560000,CODECS="...",VIDEO="mid"
mid/main/audio-video.m3u8
#EXT-X-MEDIA:TYPE=VIDEO,GROUP-ID="hi",NAME="Main", \
DEFAULT=YES,URI="hi/main/audio-video.m3u8"
#EXT-X-MEDIA:TYPE=VIDEO,GROUP-ID="hi",NAME="Centerfield", \
DEFAULT=NO,URI="hi/centerfield/audio-video.m3u8"
#EXT-X-MEDIA:TYPE=VIDEO,GROUP-ID="hi",NAME="Dugout", \
DEFAULT=NO,URI="hi/dugout/audio-video.m3u8"
#EXT-X-STREAM-INF:BANDWIDTH=7680000,CODECS="...",VIDEO="hi"
hi/main/audio-video.m3u8
8.8. Session Data in a Master Playlist
In this example, only the EXT-X-SESSION-DATA is shown:
#EXT-X-SESSION-DATA:DATA-ID="com.example.lyrics",URI="lyrics.json"
#EXT-X-SESSION-DATA:DATA-ID="com.example.title",LANGUAGE="en", \
VALUE="This is an example"
#EXT-X-SESSION-DATA:DATA-ID="com.example.title",LANGUAGE="es", \
VALUE="Este es un ejemplo"
8.9. CHARACTERISTICS Attribute Containing Multiple Characteristics
Certain characteristics are valid in combination, as in: CHARACTERISTICS= "public.accessibility.transcribes-spoken-dialog,public.easy-to-read"8.10. EXT-X-DATERANGE Carrying SCTE-35 Tags
This example shows two EXT-X-DATERANGE tags that describe a single Date Range, with an SCTE-35 "out" splice_insert() command that is subsequently updated with an SCTE-35 "in" splice_insert() command. #EXTM3U ... #EXT-X-DATERANGE:ID="splice-6FFFFFF0",START-DATE="2014-03-05T11: 15:00Z",PLANNED-DURATION=59.993,SCTE35-OUT=0xFC002F0000000000FF0 00014056FFFFFF000E011622DCAFF000052636200000000000A0008029896F50 000008700000000 ... Media Segment declarations for 60s worth of media #EXT-X-DATERANGE:ID="splice-6FFFFFF0",DURATION=59.993,SCTE35-IN= 0xFC002A0000000000FF00000F056FFFFFF000401162802E6100000000000A00 08029896F50000008700000000 ...9. IANA Considerations
IANA has registered the following media type [RFC2046]: Type name: application Subtype name: vnd.apple.mpegurl Required parameters: none Optional parameters: none Encoding considerations: encoded as UTF-8, which is 8-bit text. This media type may require encoding on transports not capable of handling 8-bit text. See Section 4 for more information. Security considerations: See Section 10. Compression: this media type does not employ compression.
Interoperability considerations: There are no byte-ordering issues, since files are 8-bit text. Applications could encounter unrecognized tags, which SHOULD be ignored. Published specification: see Section 4. Applications that use this media type: Multimedia applications such as the iPhone media player in iOS 3.0 and later and QuickTime Player in Mac OS X version 10.6 and later. Fragment identifier considerations: no Fragment Identifiers are defined for this media type. Additional information: Deprecated alias names for this type: none Magic number(s): #EXTM3U File extension(s): .m3u8, .m3u (see Section 4) Macintosh file type code(s): none Person & email address to contact for further information: David Singer, singer@apple.com. Intended usage: LIMITED USE Restrictions on usage: none Author: Roger Pantos Change Controller: David Singer10. Security Considerations
Since the protocol generally uses HTTP to transfer data, most of the same security considerations apply. See Section 15 of HTTP [RFC7230]. Media file parsers are typically subject to "fuzzing" attacks. Implementors SHOULD pay particular attention to code that will parse data received from a server and ensure that all possible inputs are handled correctly. Playlist files contain URIs, which clients will use to make network requests of arbitrary entities. Clients SHOULD range-check responses to prevent buffer overflows. See also the Security Considerations section of "Uniform Resource Identifier (URI): Generic Syntax" [RFC3986].
Apart from URL resolution, this format does not employ any form of
active content.
Clients SHOULD limit each playback session to a reasonable number of
concurrent downloads (e.g., four) to avoid contributing to denial-of-
service attacks.
HTTP requests often include session state ("cookies"), which may
contain private user data. Implementations MUST follow cookie
restriction and expiry rules specified by "HTTP State Management
Mechanism" [RFC6265] to protect themselves from attack. See also the
Security Considerations section of that document, and "Use of HTTP
State Management" [RFC2964].
Encryption keys are specified by URI. The delivery of these keys
SHOULD be secured by a mechanism such as HTTP Over TLS [RFC2818]
(formerly SSL) in conjunction with a secure realm or a session token.
11. References
11.1. Normative References
[AC_3] Advanced Television Systems Committee, "Digital Audio
Compression (AC-3) (E-AC-3) Standard", ATSC
Standard A/52:2010, November 2010, <http://atsc.org/
wp-content/uploads/2015/03/A52-201212-17.pdf>.
[AES_128] National Institute of Standards and Technology, "Advanced
Encryption Standard (AES)", FIPS PUB 197,
DOI 10.6028/NIST.FIPS.197, November 2001,
<http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.197.pdf>.
[CEA608] Consumer Electronics Association, "ANSI/CEA 608-E: Line 21
Data Services", April 2008.
[CEA708] Consumer Technology Association, "Digital Television (DTV)
Closed Captioning", ANSI/CTA Standard CEA-708-E, August
2013, <https://standards.cta.tech/kwspub/published_docs/
ANSI-CTA-708-E-Preview.pdf>.
[COMMON_ENC]
International Organization for Standardization,
"Information technology -- MPEG systems technologies --
Part 7: Common encryption in ISO base media file format
files", ISO/IEC 23001-7:2016, February 2016,
<http://www.iso.org/iso/
catalogue_detail.htm?csnumber=68042>.
[H_264] International Telecommunications Union, "Advanced video coding for generic audiovisual services", January 2012, <http://www.itu.int/rec/T-REC-H.264>. [HDCP] Digital Content Protection LLC, "High-bandwidth Digital Content Protection System - Mapping HDCP to HDMI", February 2013, <http://www.digital-cp.com/ sites/default/files/specifications/ HDCP%20on%20HDMI%20Specification%20Rev2_2_Final1.pdf>. [ISO_13818] International Organization for Standardization, "Generic coding of moving pictures and associated audio information", ISO/IEC International Standard 13818, October 2007, <http://www.iso.org/iso/catalogue_detail?csnumber=44169>. [ISO_13818_3] International Organization for Standardization, "ISO/IEC International Standard 13818-3:1998; Generic coding of moving pictures and associated audio information - Part 3: Audio", April 1998, <http://www.iso.org/iso/home/store/catalogue_tc/ catalogue_detail.htm?csnumber=26797>. [ISO_13818_7] International Organization for Standardization, "Generic coding of moving pictures and associated audio information - Part 7: Advanced Audio Coding (AAC)", ISO/IEC International Standard 13818-3:2006, January 2006, <http://www.iso.org/iso/home/store/catalogue_tc/ catalogue_detail.htm?csnumber=43345>. [ISO_14496] International Organization for Standardization, "Information technology -- Coding of audio-visual objects -- Part 3: Audio", ISO/IEC 14496-3:2009, 2009, <http://www.iso.org/iso/catalogue_detail?csnumber=53943>. [ISO_8601] International Organization for Standardization, "Data elements and interchange formats -- Information interchange -- Representation of dates and times", ISO/IEC International Standard 8601:2004, December 2004, <http://www.iso.org/iso/catalogue_detail?csnumber=40874>.
[ISOBMFF] International Organization for Standardization, "Information technology -- Coding of audio-visual objects -- Part 12: ISO base media file format", ISO/IEC 14496-12:2015, December 2015, <http://www.iso.org/iso/ catalogue_detail.htm?csnumber=68960>. [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, <https://www.rfc-editor.org/info/rfc2046>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <https://www.rfc-editor.org/info/rfc2818>. [RFC2964] Moore, K. and N. Freed, "Use of HTTP State Management", BCP 44, RFC 2964, DOI 10.17487/RFC2964, October 2000, <https://www.rfc-editor.org/info/rfc2964>. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>. [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, <https://www.rfc-editor.org/info/rfc5646>. [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <https://www.rfc-editor.org/info/rfc5652>. [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, DOI 10.17487/RFC6265, April 2011, <https://www.rfc-editor.org/info/rfc6265>.
[RFC6381] Gellens, R., Singer, D., and P. Frojdh, "The 'Codecs' and 'Profiles' Parameters for "Bucket" Media Types", RFC 6381, DOI 10.17487/RFC6381, August 2011, <https://www.rfc-editor.org/info/rfc6381>. [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, <https://www.rfc-editor.org/info/rfc7159>. [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. [SCTE35] Society of Cable Telecommunications Engineers, "Digital Program Insertion Cueing Message for Cable", ANSI/SCTE 35, August 2014, <http://www.scte.org/documents/pdf/Standards/ ANSI_SCTE%2035%202014.pdf>. [US_ASCII] American National Standard for Information Systems, "Coded Character Sets - 7-Bit American National Standard Code for Information Interchange (7-Bit ASCII)", ANSI X3.4, December 1986. [WebVTT] World Wide Web Consortium (W3C), "WebVTT: The Web Video Text Tracks Format", Draft Community Group Report, June 2017, <http://dev.w3.org/html5/webvtt/>.11.2. Informative References
[CMAF] International Organization for Standardization, "Information technology -- Multimedia application format (MPEG-A) -- Part 19: Common media application format (CMAF) for segmented media", ISO/IEC FDIS 23000-19, <https://www.iso.org/standard/71975.html>. [ID3] ID3.org, "The ID3 audio file data tagging format", <http://www.id3.org/Developer_Information>. [M3U] Nullsoft, Inc., "The M3U Playlist format, originally invented for the Winamp media player", <https://en.wikipedia.org/w/ index.php?title=M3U7amp;oldid=786631666>.
[SampleEnc] Apple Inc., "MPEG-2 Stream Encryption Format for HTTP Live Streaming", <https://developer.apple.com/library/ios/documentation/ AudioVideo/Conceptual/HLS_Sample_Encryption/>. [UNICODE] The Unicode Consortium, "The Unicode Standard", <http://www.unicode.org/versions/latest/>. [UTI] Apple Inc., "Uniform Type Identifier", <http://developer.apple.com/library/ios/#documentation/ general/conceptual/DevPedia-CocoaCore/ UniformTypeIdentifier.html>.Contributors
Significant contributions to the design of this protocol were made by Jim Batson, David Biderman, Bill May, Roger Pantos, Alan Tseng, and Eryk Vershen. Stuart Cheshire helped edit the specification.Authors' Addresses
Roger Pantos (editor) Apple, Inc. Cupertino, California United States of America Email: http-live-streaming-review@group.apple.com William May, Jr. Major League Baseball Advanced Media New York, New York United States of America Email: bill.may@mlb.com