Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 8216


HTTP Live Streaming

Part 4 of 4, p. 37 to 60
Prev Section


prevText      Top      ToC       Page 37 
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.

Top      Up      ToC       Page 38 
   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

   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 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).

Top      Up      ToC       Page 39 
   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

   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.

Top      Up      ToC       Page 40 
   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

   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

   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.

Top      Up      ToC       Page 41 
   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 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.

Top      Up      ToC       Page 42 
   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 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

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

   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.

Top      Up      ToC       Page 43 
   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

   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

   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

   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

   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

Top      Up      ToC       Page 44 
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

   o  ignore any unrecognized tags.

   o  ignore any attribute/value pair with an unrecognized

   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.

Top      Up      ToC       Page 45 
   A client MAY use the segment Media Sequence Number to track the
   location of a Media Segment within a Playlist when the Playlist is

   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

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.

Top      Up      ToC       Page 46 
   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

   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.

Top      Up      ToC       Page 47 
   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

Top      Up      ToC       Page 48 
   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

   If the encryption METHOD is AES-128 and the Media Segment is part of
   an I-frame Playlist (Section 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.

Top      Up      ToC       Page 49 
   A Media Playlist MUST indicate an EXT-X-VERSION of 2 or higher if it

   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

   o  Floating-point EXTINF duration values.

   A Media Playlist MUST indicate an EXT-X-VERSION of 4 or higher if it

   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

   o  The KEYFORMAT and KEYFORMATVERSIONS attributes of the EXT-X-KEY

   o  The EXT-X-MAP tag.

   A Media Playlist MUST indicate an EXT-X-VERSION of 6 or higher if it

   o  The EXT-X-MAP tag in a Media Playlist that does not contain EXT-

   A Master Playlist MUST indicate an EXT-X-VERSION of 7 or higher if it

   o  "SERVICE" values for the INSTREAM-ID attribute of the EXT-X-MEDIA

   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.

Top      Up      ToC       Page 50 
8.  Playlist Examples

8.1.  Simple Media Playlist


8.2.  Live Media Playlist Using HTTPS



Top      Up      ToC       Page 51 
8.3.  Playlist with Encrypted Media Segments






8.4.  Master Playlist


8.5.  Master Playlist with I-Frames


Top      Up      ToC       Page 52 
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:

   #EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="aac",NAME="Commentary", \

8.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.

Top      Up      ToC       Page 53 
   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:

   #EXT-X-MEDIA:TYPE=VIDEO,GROUP-ID="low",NAME="Centerfield", \


   #EXT-X-MEDIA:TYPE=VIDEO,GROUP-ID="mid",NAME="Centerfield", \


   #EXT-X-MEDIA:TYPE=VIDEO,GROUP-ID="hi",NAME="Centerfield", \


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.title",LANGUAGE="en", \
           VALUE="This is an example"
   #EXT-X-SESSION-DATA:DATA-ID="com.example.title",LANGUAGE="es", \
           VALUE="Este es un ejemplo"

Top      Up      ToC       Page 54 
8.9.  CHARACTERISTICS Attribute Containing Multiple Characteristics

   Certain characteristics are valid in combination, as in:


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.


   ... Media Segment declarations for 60s worth of media


9.  IANA Considerations

   IANA has registered the following media type [RFC2046]:

   Type name: application

   Subtype name:

   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.

Top      Up      ToC       Page 55 
   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

   Intended usage: LIMITED USE

   Restrictions on usage: none

   Author: Roger Pantos

   Change Controller: David Singer

10.  Security Considerations

   Since the protocol generally uses HTTP to transfer data, most of the
   same security considerations apply.  See Section 15 of HTTP

   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"

Top      Up      ToC       Page 56 
   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, <

   [AES_128]  National Institute of Standards and Technology, "Advanced
              Encryption Standard (AES)", FIPS PUB 197,
              DOI 10.6028/NIST.FIPS.197, November 2001,

   [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, <

              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,

Top      Up      ToC       Page 57 
   [H_264]    International Telecommunications Union, "Advanced video
              coding for generic audiovisual services", January 2012,

   [HDCP]     Digital Content Protection LLC, "High-bandwidth Digital
              Content Protection System - Mapping HDCP to HDMI",
              February 2013, <

              International Organization for Standardization, "Generic
              coding of moving pictures and associated audio
              information", ISO/IEC International Standard 13818,
              October 2007,

              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,

              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,

              International Organization for Standardization,
              "Information technology -- Coding of audio-visual objects
              -- Part 3: Audio", ISO/IEC 14496-3:2009, 2009,

   [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,

Top      Up      ToC       Page 58 
   [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,

   [RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part Two: Media Types", RFC 2046,
              DOI 10.17487/RFC2046, November 1996,

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,

   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818,
              DOI 10.17487/RFC2818, May 2000,

   [RFC2964]  Moore, K. and N. Freed, "Use of HTTP State Management",
              BCP 44, RFC 2964, DOI 10.17487/RFC2964, October 2000,

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
              2003, <>.

   [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,

   [RFC5646]  Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
              Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
              September 2009, <>.

   [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
              RFC 5652, DOI 10.17487/RFC5652, September 2009,

   [RFC6265]  Barth, A., "HTTP State Management Mechanism", RFC 6265,
              DOI 10.17487/RFC6265, April 2011,

Top      Up      ToC       Page 59 
   [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,

   [RFC7159]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
              2014, <>.

   [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,

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <>.

   [SCTE35]   Society of Cable Telecommunications Engineers, "Digital
              Program Insertion Cueing Message for Cable", ANSI/SCTE 35,
              August 2014, <

   [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, <>.

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,

   [ID3], "The ID3 audio file data tagging format",

   [M3U]      Nullsoft, Inc., "The M3U Playlist format, originally
              invented for the Winamp media player",

Top      Up      ToC       Page 60 
              Apple Inc., "MPEG-2 Stream Encryption Format for HTTP Live

   [UNICODE]  The Unicode Consortium, "The Unicode Standard",

   [UTI]      Apple Inc., "Uniform Type Identifier",


   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


   William May, Jr.
   Major League Baseball Advanced Media
   New York, New York
   United States of America