Informational
`Internet -Draft
`Intended status: Informational
`Expires: October 2, 2011
`
`R. Pantos, Ed.
`W. May
`Apple Inc.
`March 31, 2011
`
`HTTP Live Streaming
`draft -pantos -http-live-streaming -06
`
`Abstract
`
`This document describes a protocol for transferring unbounded streams
`of multimedia data.
`It specifies the data format of the files and
`the actions to be taken by the server (sender) and the clients
`(receivers) of the streams.
`It describes version 3 of this protocol.
`
`Status of this Memo
`
`This Internet-Draft is submitted in full conformance with the
`
`provisions of BCP 78 and BCP 79. This document may not be modified,
`and derivative works of it may not be created, and it may not be
`published except as an Internet-Draft.
`
`Internet-Drafts are working documents of the Internet Engineering
`Task Force (IETF). Note that other groups may also distribute
`working documents as Internet-Drafts.
`The list of current Internet-
`Drafts is at http://datatracker.ietf.org/drafts/current/.
`
`Internet-Drafts are draft documents valid for a maximum of six months
`and may be updated, replaced, or obsoleted by other documents at any
`time.
`It is inappropriate to use Internet-Drafts as reference
`material or to cite them other than as "work in progress."
`
`This Internet-Draft will expire on October 2, 2011.
`
`Copyright Notice
`
`(c) 2011 IETF Trust and the persons identified as the
`Copyright
`document authors. All rights reserved.
`
`This document is subject to BCP 78 and the IETF Trust's Legal
`Provisions Relating to IETF Documents
`(http: //trustee.ietf.org/license-info) in effect on the date of
`publication of this document. Please review these documents
`carefully, as they describe your rights and restrictions with respect
`to this document.
`
`This Informational Internet Draft is submitted as an RFC Editor
`
`Pantos & May
`
`Expires October 2, 2011
`
`[Page 1]
`
`Google Exhibit 1018
`Google Exhibit 1018
`Google v. Ericsson
`Google v. Ericsson
`
`

`

`Internet -Draft
`
`HTTP Live Streaming
`
`March 2011
`
`IETF
`Contribution and/or non-IETF Document (not as a Contribution,
`
`nor IETF Document)
`in accordance with BCP 78 and BCP
`Contribution,
`79.
`
`Table of Contents
`
`[Wo[NoTE
`
`Jun|
`
`looINI
`
`Introduction .
`
`.
`
`Introduction .
`3.1.
`3.2. Attribute Lists
`.
`3.
`New Tags...
`EXT-X- TARGETDURATION .
`3.3.1.
`EXT-X-MEDIA-SEQUENCE .
`3.3.2.
`3.3.3.
`EXT-X-KEY ...
`3.3.4.
`EXT-X-PROGRAM- DATE- TIME
`3.3.5.
`EXT-X-ALLOW-CACHE
`.
`3.3.6.
`EXT-X-PLAYLIST-TYPE
`3.3.7.
`EXT-X-ENDLIST
`..
`3.3.8.
`EXT-X-STREAM-INF .
`3.3.9.
`EXT-X-DISCONTINUITY
`
`3.3.10. EXT-X-VERSION
`Media files
`.
`Key files
`5.1.
`Introduction .
`5.2.
`IV for AES-128 .
`. Client/Server Actions
`6.1.
`Introduction .
`6.2.
`Server Process .
`6.2.1,
`Introduction .
`.
`6.2.2. Sliding Window Playlists .
`6.2.3. Encrypting media files .
`6.2.4,
`Providing variant streams
`6.3. Client Process .
`6.3.1.
`Introduction...
`6.3.2.
`Loading the Playlist file.
`6.3.3.
`Playing the Playlist file
`6.3.4. Reloading the Playlist file
`6.3.5. Determining the next file to load
`
`6.3.6. Decrypting encrypted media files .
`Protocol version compatibility .
`Examples .
`coe ee
`8.1.
`Introduction.
`.
`.
`.
`8.2.
`Simple Playlist File tee
`.
`8.3. Sliding Window Playlist, using HTTPS .
`8.4. Playlist file with encrypted media files .
`
`IslsIS1S|S[0[WO|JW[OO[Co[SI[OD[Ov|[1[UTFBININDINOIN)ININ[|[FHISIS[0[0[0[00[00INIINIININ[0[BSIBIBIBISISISiskolololeloKlalsBIGGERKREISKREE
`
`
`
`
`
`
`Pantos & May
`
`Expires October 2, 2011
`
`[Page 2]
`
`

`

`Internet -Draft
`
`HTTP Live Streaming
`
`March 2011
`
`1file
`
`8.5. Variant Playlist
`9. Contributors .
`1@.
`IANA Considerations
`11. Security Considerations
`Be. References .
`.
`12.1. Normative References .
`12.2.
`Informative References .
`Authors' Addresses .
`
`INOJN2[NY[NYINOJNINQ[loIeIeIsIsISISININ
`
`Pantos & May
`
`Expires October 2, 2011
`
`[Page 3]
`
`

`

`Internet -Draft
`
`HTTP Live Streaming
`
`March 2011
`
`1.
`
`Introduction
`
`This document describes a protocol for transferring unbounded streams
`of multimedia data.
`The protocol supports the encryption of media
`data and the provision of alternate versions (e.g. bitrates) of a
`stream. Media data can be transferred soon after it is created,
`allowing it to be played in near real-time. Data is usually carried
`over HTTP [RFC2616].
`
`External references that describe related standards such as HTTP are
`listed in Section 11.
`
`2.
`
`Summary
`
`[RFC3986]
`A multimedia presentation is specified by a URI
`Playlist file, which is an ordered list of media URIs and
`informational tags.
`Each media URI refers to a media file which is a
`segment of a single contiguous stream.
`
`to a
`
`the client first obtains the Playlist file and
`To play the stream,
`then obtains and plays each media file in the Playlist.
`It reloads
`the Playlist file as described in this document to discover
`additional segments.
`
`"SHALL NOT",
`"SHALL",
`"REQUIRED",
`"MUST NOT",
`The key words "MUST",
`"SHOULD",
`"SHOULD NOT",
`"RECOMMENDED",
`"MAY", and "OPTIONAL"
`in this
`document are to be interpreted as described in RFC 2119 [RFC2119].
`
`3.
`
`The Playlist file
`
`3.1.
`
`Introduction
`
`Playlists MUST be Extended M3U Playlist files [M3U]. This document
`extends the M3U file format by defining additional tags.
`
`An M3U Playlist is a text file that consists of individual lines.
`Lines are terminated by either a single LF character or a CR
`character followed by an LF character.
`Each line is a URI, a blank,
`or starts with the comment character ‘'#'. Blank lines are ignored.
`White space MUST NOT be present, except for elements in which it is
`explicitly specified.
`
`A URI line identifies a media file or a variant Playlist file (see
`Section 3.3.8).
`
`URIs MAY be relative.
`
`A relative URI MUST be resolved against the
`
`Pantos & May
`
`Expires October 2, 2011
`
`[Page 4]
`
`

`

`Internet -Draft
`
`HTTP Live Streaming
`
`March 2011
`
`URI of the Playlist file that contains it.
`
`Lines that start with the comment character '#' are either comments
`or tags.
`Tags begin with #EXT. All other lines that begin with '#'
`are comments and SHOULD be ignored.
`
`The duration of a Playlist file is the sum of the durations of the
`media files within it.
`
`M3U Playlist files whose names end in .m3u8 and/or have the HTTP
`Content-Type "“application/vnd.apple.mpegur1l" are encoded in UTF-8
`[REC3629]. Files whose names end with .m3u and/or have the HTTP
`Content-Type [RFC2616] "audio/mpegurl" are encoded in US-ASCII
`[US ASCIT].
`
`Playlist files MUST have names that end in .m3u8 and/or have the
`Content-Type "“application/vnd.apple.mpegur1" (if transferred over
`HTTP), or have names that end in .m3u and/or have the HTTP Content-
`Type type "audio/mpegurl" (for compatibility) .
`
`An
`The Extended M3U file format defines two tags: EXTM3U and EXTINF.
`Extended M3U file is distinguished from a basic M3U file by its first
`line, which MUST be #EXTM3U.
`
`EXTINF is a record marker that describes the media file identified by
`the URI that follows it.
`Each media file URI MUST be preceded by an
`EXTINF tag.
`Its format is:
`
`#EXTINF: <duration>,<title>
`
`"duration" is an integer or floating-point number in decimal
`positional notation that specifies the duration of the media file in
`seconds.
`Integer durations SHOULD be rounded to the nearest integer.
`Durations MUST be integers if the protocol version of the Playlist
`file is less than 3.
`The remainder of the line following the comma
`is the title of the media file, which is an optional human-readable
`informative title of the media segment.
`
`This document defines the following new tags: EXT-X-TARGETDURATION,
`EXT-X-MEDIA-SEQUENCE, EXT-X-KEY, EXT-X-PROGRAM-DATE-TIME, EXT-X-
`ALLOW-CACHE, EXT-X-PLAYLIST-TYPE, EXT-X-STREAM-INF, EXT-X-ENDLIST,
`EXT-X-DISCONTINUITY, and EXT-X-VERSION.
`
`3.2. Attribute Lists
`
`Certain extended M3U tags have values which are Attribute Lists.
`Attribute List is a comma-separated list of attribute/value pairs
`with no whitespace.
`
`An
`
`Pantos & May
`
`Expires October 2, 2011
`
`[Page 5]
`
`

`

`Internet -Draft
`
`HTTP Live Streaming
`
`March 2011
`
`An attribute/value pair has the following syntax:
`
`AttributeName=AttributeValue
`
`An AttributeName is an unquoted string containing characters from the
`set
`[A-Z].
`
`An AttributeValue is one of the following:
`
`o decimal-integer: an unquoted string of characters from the set
`[@-9] expressing an integer in base-1@ arithmetic.
`
`o hexadecimal-integer: an unquoted string of characters from the set
`[@-9] and [A-F]
`that is prefixed with @x or @X and which expresses
`an integer in base-16 arithmetic.
`
`o decimal-floating-point: an unquoted string of characters from the
`set
`[@-9] and '.' which expresses a floating-point number in
`decimal positional notation.
`
`o quoted-string: a string of characters within a pair of double-
`quotes (").
`The set of characters allowed in the string and any
`rules for escaping special characters are specified by the
`Attribute definition, but any double-quote (") character and any
`carriage-return or linefeed will always be replaced by an escape
`sequence.
`
`Oo
`
`enumerated-string: an unquoted character string from a set which
`is explicitly defined by the Attribute.
`An enumerated-string will
`never contain double-quotes ("), commas (,), or whitespace.
`
`two decimal-integers separated by the "x"
`o decimal-resolution:
`character,
`indicating horizontal and vertical pixel dimensions.
`
`The type of the AttributeValue for a given AttributeName is specified
`by the Attribute definition.
`
`A given AttributeName MUST NOT appear more than once in a given
`Attribute List.
`
`An Attribute/value pair with an unrecognized AttributeName MUST be
`ignored by the client.
`
`Attribute/value pairs of type enumerated-string that contain
`unrecognized values SHOULD be ignored by the client.
`
`Pantos & May
`
`Expires October 2, 2011
`
`[Page 6]
`
`

`

`Internet -Draft
`
`HTTP Live Streaming
`
`March 2011
`
`3.3.
`
`New Tags
`
`3.3.1.
`
`EXT-X-TARGETDURATION
`
`The EXT-X-TARGETDURATION tag specifies the maximum media file
`duration.
`The EXTINF duration of each media file in the Playlist
`file MUST be less than or equal to the target duration. This tag
`MUST appear once in the Playlist file.
`Its format is:
`
`#EXT -X-TARGETDURATION: <s>
`
`where s is an integer indicating the target duration in seconds.
`
`3.3.2.
`
`EXT-X-MEDIA-SEQUENCE
`
`Each media file URI in a Playlist has a unique integer sequence
`number.
`The sequence number of a URI is equal to the sequence number
`of the URI that preceded it plus one.
`The EXT-X-MEDIA-SEQUENCE tag
`indicates the sequence number of the first URI that appears in a
`Playlist file.
`Its format is:
`
`#EXT -X-MEDIA- SEQUENCE : <number>
`
`A Playlist file MUST NOT contain more than one EXT-X-MEDIA-SEQUENCE
`tag.
`If the Playlist file does not contain an EXT-X-MEDIA-SEQUENCE
`tag then the sequence number of the first URI in the playlist SHALL
`be considered to be @.
`
`A media file's sequence number is not required to appear in its URI.
`
`See Section 6.3.2 and Section 6.3.5 for information on handling the
`EXT-X-MEDIA-SEQUENCE tag.
`
`3.3.3.
`
`EXT-X-KEY
`
`The EXT-X-KEY tag provides information
`Media files MAY be encrypted.
`necessary to decrypt media files that follow it.
`Its format is:
`
`#EXT-X-KEY:<attribute-list>
`
`The following attributes are defined:
`
`It is of type
`The METHOD attribute specifies the encryption method.
`enumerated-string.
`Each EXT-X-KEY tag MUST contain a METHOD
`attribute.
`
`Two methods are defined: NONE and AES-128.
`
`Pantos & May
`
`Expires October 2, 2011
`
`[Page 7]
`
`

`

`Internet -Draft
`
`HTTP Live Streaming
`
`March 2011
`
`An encryption method of NONE means that media files are not
`encrypted.
`If the encryption method is NONE,
`the URI and the IV
`attributes MUST NOT be present.
`
`An encryption method of AES-128 means that media files are encrypted
`using the Advanced Encryption Standard [AES 128] with a 128-bit key
`and PKCS7 padding [RFC5652].
`If the encryption method is AES-128,
`the URI attribute MUST be present.
`The IV attribute MAY be present;
`see Section 5.2.
`
`Its value is a
`The URI attribute specifies how to obtain the key.
`quoted-string that contains a URI
`[RFC3986] for the key.
`
`The IV attribute, if present, specifies the Initialization Vector to
`be used with the key.
`Its value is a hexadecimal-integer.
`The IV
`attribute appeared in protocol version 2.
`
`A new EXT-X-KEY supersedes any prior EXT-X-KEY.
`
`If the Playlist file does not contain an EXT-X-KEY tag then media
`files are not encrypted.
`
`See Section 5 for the format of the key file, and Section 5.2,
`Section 6.2.3 and Section 6.3.6 for additional information on media
`file encryption.
`
`3.3.4.
`
`EXT-X-PROGRAM-DATE-TIME
`
`The EXT-X-PROGRAM-DATE-TIME tag associates the beginning of the next
`media file with an absolute date and/or time.
`The date/time
`representation is ISO/IEC 86@1:2004 [ISO 8601] and SHOULD indicate a
`time zone.
`For example:
`
`#EXT -X-PROGRAM-DATE-TIME: <YYYY-MM-DDThh: mm: ssZ>
`
`See Section 6.2.1 and Section 6.3.3 for more information on the EXT-
`X-PROGRAM-DATE-TIME tag.
`
`3.3.5.
`
`EXT-X-ALLOW-CACHE
`
`The EXT-X-ALLOW-CACHE tag indicates whether the client MAY or MUST
`NOT cache downloaded media files for later replay.
`It MAY occur
`anywhere in the Playlist file; it MUST NOT occur more than once.
`EXT-X-ALLOW-CACHE tag applies to all segments in the playlist.
`format is:
`
`The
`Its
`
`#EXT -X-ALLOW- CACHE : <YES | NO>
`
`Pantos & May
`
`Expires October 2, 2011
`
`[Page 8]
`
`

`

`Internet -Draft
`
`HTTP Live Streaming
`
`March 2011
`
`See Section 6.3.3 for more information on the EXT-X-ALLOW-CACHE tag.
`
`3.3.6.
`
`EXT-X-PLAYLIST-TYPE
`
`The EXT-X-PLAYLIST-TYPE tag provides mutability information about the
`Playlist file.
`It is optional.
`Its format is:
`
`#EXT-X-PLAYLIST-TYPE: <EVENT| VOD>
`
`Section 6.2.1 defines the implications of the EXT-X-PLAYLIST-TYPE
`tag.
`
`3.3.7.
`
`EXT-X-ENDLIST
`
`The EXT-X-ENDLIST tag indicates that no more media files will be
`added to the Playlist file.
`It MAY occur anywhere in the Playlist
`file; it MUST NOT occur more than once.
`Its format is:
`
`#EXT-X-ENDLIST
`
`3.3.8.
`
`EXT-X-STREAM-INF
`
`in the Playlist
`The EXT-X-STREAM-INF tag indicates that the next URI
`file identifies another Playlist file.
`Its format is:
`
`#EXT -X-STREAM- INF: <attribute-list>
`<URI>
`
`The following attributes are defined:
`
`BANDWIDTH
`
`It MUST be an
`The value is a decimal-integer of bits per second.
`upper bound of the overall bitrate of each media file, calculated to
`include container overhead, that appears or will appear in the
`Playlist.
`
`Every EXT-X-STREAM-INF tag MUST include the BANDWIDTH attribute.
`
`PROGRAM-ID
`
`The value is a decimal-integer that uniquely identifies a particular
`presentation within the scope of the Playlist file.
`
`A Playlist file MAY contain multiple EXT-X-STREAM-INF tags with the
`same PROGRAM-ID to identify different encodings of the same
`presentation. These variant playlists MAY contain additional EXT-X-
`STREAM-INF tags.
`
`Pantos & May
`
`Expires October 2, 2011
`
`[Page 9]
`
`

`

`Internet -Draft
`
`HTTP Live Streaming
`
`March 2011
`
`CODECS
`
`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 file in the Playlist file. Valid format
`identifiers are those in the ISO File Format Name Space defined by
`RFC 4281 [RFC4281].
`
`Every EXT-X-STREAM-INF tag SHOULD include a CODECS attribute.
`
`RESOLUTION
`
`The value is a decimal-resolution describing the approximate encoded
`horizontal and vertical resolution of video within the stream.
`
`3.3.9.
`
`EXT-X-DISCONTINUITY
`
`The EXT-X-DISCONTINUITY tag indicates an encoding discontinuity
`between the media file that follows it and the one that preceded it.
`The set of characteristics that MAY change is:
`
`o
`
`o
`
`o
`
`Oo
`
`o
`
`file format
`
`number and type of tracks
`
`encoding parameters
`
`encoding sequence
`
`timestamp sequence
`
`Its format is:
`
`#EXT-X-DISCONTINUITY
`
`See Section 4, Section 6.2.1, and Section 6.3.3 for more information
`about the EXT-X-DISCONTINUITY tag.
`
`3.3.10.
`
`EXT-X-VERSION
`
`The EXT-X-VERSION tag indicates the compatibility version of the
`Playlist file.
`The Playlist file, its associated media, and its
`server MUST comply with all provisions of the most-recent version of
`this document describing the protocol version indicated by the tag
`value.
`
`Pantos & May
`
`Expires October 2, 2011
`
`[Page 10]
`
`

`

`Internet -Draft
`
`HTTP Live Streaming
`
`March 2011
`
`Its format is:
`
`#EXT-X-VERSION: <n>
`
`where n is an integer indicating the protocol version.
`
`A
`A Playlist file MUST NOT contain more than one EXT-X-VERSION tag.
`Playlist file that does not contain an EXT-X-VERSION tag MUST comply
`with version 1 of this protocol.
`
`[ss
`
`Media files
`
`Each media file URI in a Playlist file MUST identify a media file
`which is a segment of the overall presentation.
`Each media file MUST
`be formatted as an MPEG-2 Transport Stream or an MPEG-2 audio
`elementary stream [ISO 13818].
`
`Transport Stream files MUST contain a single MPEG-2 Program. There
`SHOULD be a Program Association Table and a Program Map Table at the
`start of each file.
`A file that contains video SHOULD have at least
`one key frame and enough information to completely initialize a video
`decoder.
`
`A media file in a Playlist MUST be the continuation of the encoded
`stream at the end of the media file with the previous sequence number
`unless it was the first media file ever to appear in the Playlist
`file or it is prefixed by an EXT-X-DISCONTINUITY tag.
`
`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 one with the lowest numerical PID that it can play.
`
`Clients MUST ignore private streams inside Transport Streams that
`they do not recognize.
`
`The encoding parameters for samples within a stream inside a media
`file and between corresponding streams across multiple media files
`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.
`
`5.
`
`Key files
`
`Pantos & May
`
`Expires October 2, 2011
`
`[Page 11]
`
`

`

`Internet -Draft
`
`HTTP Live Streaming
`
`March 2011
`
`5.1.
`
`Introduction
`
`A Key
`An EXT-X-KEY tag with the URI attribute identifies a Key file.
`file contains the cipher key that MUST be used to decrypt subsequent
`media files in the Playlist.
`
`The format of the
`The AES-128 encryption method uses 16-octet keys.
`Key file is simply a packed array of these 16 octets in binary
`format.
`
`5.2.
`
`IV for AES-128
`
`128-bit AES requires the same 16-octet Initialization Vector (IV)
`be supplied when encrypting and decrypting. Varying this IV
`increases the strength of the cipher.
`
`to
`
`implementations MUST use
`If the EXT-X-KEY tag has the IV attribute,
`the attribute value as the IV when encrypting or decrypting with that
`key.
`The value MUST be interpreted as a 128-bit hexadecimal number
`and MUST be prefixed with @x or @X.
`
`implementations
`If the EXT-X-KEY tag does not have the IV attribute,
`MUST use the sequence number of the media file as the IV when
`encrypting or decrypting that media file.
`The big-endian binary
`representation of the sequence number SHALL be placed in a 16-octet
`buffer and padded (on the left) with zeros.
`
`6. Client/Server Actions
`
`6.1.
`
`Introduction
`
`This section describes how the server generates the Playlist and
`media files and how the client should download and play them.
`
`6.2. Server Process
`
`6.2.1.
`
`Introduction
`
`The production of the MPEG-2 stream is outside the scope of this
`document, which simply presumes a source of a continuous stream
`containing the presentation.
`
`The server MUST divide the stream into individual media files whose
`duration is less than or equal to a constant target duration.
`The
`server SHOULD attempt to divide the stream at points that support
`effective decode of individual media files, e.g. on packet and key
`frame boundaries.
`
`Pantos & May
`
`Expires October 2, 2011
`
`[Page 12]
`
`

`

`Internet -Draft
`
`HTTP Live Streaming
`
`March 2011
`
`The server MUST create a URI for each media file that will allow its
`clients to obtain the file.
`
`The Playlist file MUST
`The server MUST create a Playlist file.
`conform to the format described in Section 3.
`A URI for each media
`file that the server wishes to make available MUST appear in the
`Playlist in the order in which it is to be played.
`The entire media
`file MUST be available to clients if its URI is in the Playlist file.
`
`Its
`The Playlist file MUST contain an EXT-X-TARGETDURATION tag.
`value MUST be equal to or greater than the EXTINF value of any media
`file that appears or will appear in the Playlist file.
`Its value
`MUST NOT change.
`A typical target duration is 1@ seconds.
`
`The Playlist file SHOULD contain one EXT-X-VERSION tag which
`indicates the compatibility version of the stream.
`Its value MUST be
`the lowest protocol version with which the server, Playlist file, and
`associated media files all comply.
`
`The server MUST create a URI for the Playlist file that will allow
`its clients to obtain the file.
`
`the server SHOULD
`If the Playlist file is distributed by HTTP,
`support client requests to use the "gzip" Content-Encoding.
`
`Changes to the Playlist file MUST be made atomically from the point
`of view of the clients.
`
`The server MUST NOT change the Playlist file, except to:
`
`Append lines to it (Section 6.2.1).
`
`Remove media file URIs from the Playlist in the order that they
`appear, along with any tags that apply only to those media files
`(Section 6.2.2).
`
`Change the value of the EXT-X-MEDIA-SEQUENCE tag (Section 6.2.2).
`
`Add or remove EXT-X-STREAM-INF tags (Section 6.2.4). Note that
`clients are not required to reload variant Playlist files, so
`changing them may not have immediate effect.
`
`Add an EXT-X-ENDLIST tag to the Playlist (Section 6.2.1).
`
`the Playlist file MAY contain an EXT-X-PLAYLIST-TYPE tag
`Furthermore,
`with a value of either EVENT or VOD.
`If the tag is present and has a
`value of EVENT,
`the server MUST NOT change or delete any part of the
`Playlist file (although it MAY append lines to it).
`If the tag is
`
`Pantos & May
`
`Expires October 2, 2011
`
`[Page 13]
`
`

`

`Internet -Draft
`
`HTTP Live Streaming
`
`March 2011
`
`present and has a value of VOD,
`
`the Playlist file MUST NOT change.
`
`in a Playlist MUST be prefixed with an EXTINF
`Every media file URI
`tag indicating the duration of the media file.
`
`The server MAY associate an absolute date and time with a media file
`by prefixing its URI with an EXT-X-PROGRAM-DATE-TIME tag.
`The value
`of the date and time provides an informative mapping of the timeline
`of the media to an appropriate wall-clock time, which may be used as
`a basis for seeking, for display, or for other purposes.
`If a server
`provides this mapping, it SHOULD place an EXT-X-PROGRAM-DATE-TIME tag
`after every EXT-X-DISCONTINUITY tag in the Playlist file.
`
`If the Playlist contains the final media file of the presentation
`then the Playlist file MUST contain the EXT-X-ENDLIST tag.
`
`the server
`If the Playlist does not contain the EXT-X-ENDLIST tag,
`MUST make a new version of the Playlist file available that contains
`at least one new media file URI.
`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.
`
`If the server wishes to remove an entire presentation, it MUST make
`the Playlist file unavailable to clients.
`It SHOULD ensure that all
`media files in the Playlist file remain available to clients for at
`least the duration of the Playlist file at the time of removal.
`
`6.2.2. Sliding Window Playlists
`
`The server MAY limit the availability of media files to those which
`have been most recently added to the Playlist.
`To do so the Playlist
`file MUST ALWAYS contain exactly one EXT-X-MEDIA-SEQUENCE tag.
`Its
`value MUST be incremented by 1 for every media file URI that is
`removed from the Playlist file.
`
`Media file URIs MUST be removed from the Playlist file in the order
`in which they were added.
`
`The server MUST NOT remove a media file URI from the Playlist file if
`the duration of the Playlist file minus the duration of the media
`file is less than three times the target duration.
`
`the media
`When the server removes a media file URI from the Playlist,
`file SHOULD remain available to clients for a period of time equal to
`the duration of the media file plus the duration of the longest
`Playlist file in which the media file has appeared.
`
`Pantos & May
`
`Expires October 2, 2011
`
`[Page 14]
`
`

`

`Internet -Draft
`
`HTTP Live Streaming
`
`March 2011
`
`If a server plans to remove a media file 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.
`
`6.2.3. Encrypting media files
`
`If media files are to be encrypted the server MUST define a URI which
`will allow authorized clients to obtain a Key file containing a
`decryption key.
`The Key file MUST conform to the format described in
`Section 5.
`
`The server MAY set the HTTP Expires header in the key response to
`indicate that the key may be cached.
`
`If the encryption METHOD is AES-128, AES-128 CBC encryption SHALL be
`applied to individual media files.
`The entire file MUST be
`encrypted. Cipher Block Chaining MUST NOT be applied across media
`files.
`The IV used for encryption MUST be either the sequence number
`of the media file or the value of the IV attribute of the EXT-X-KEY
`tag, as described in Section 5.2.
`
`The server MUST encrypt every media file in a Playlist using the
`method and other attributes specified by the EXT-X-KEY tag that most
`immediately precedes its URI
`in the Playlist file. Media files
`preceded by an EXT-X-KEY tag whose METHOD is NONE, or not preceded by
`any EXT-X-KEY tag, MUST NOT be encrypted.
`
`The server MUST NOT remove an EXT-X-KEY tag from the Playlist file if
`the Playlist file contains a URI to a media file encrypted with that
`key.
`
`6.2.4. Providing variant streams
`
`A server MAY offer multiple Playlist files to provide different
`encodings of the same presentation.
`If it does so it SHOULD provide
`a variant Playlist file that lists each variant stream to allow
`clients to switch between encodings dynamically.
`
`Variant Playlists MUST contain an EXT-X-STREAM-INF tag for each
`variant stream.
`Each EXT-X-STREAM-INF tag for the same presentation
`MUST have the same PROGRAM-ID attribute value.
`The PROGRAM-ID value
`for each presentation MUST be unique within the variant Playlist.
`
`the
`If an EXT-X-STREAM-INF tag contains the CODECS attribute,
`attribute value MUST include every format defined by [RFC4281]
`is present in any media file that appears or will appear in the
`Playlist file.
`
`that
`
`Pantos & May
`
`Expires October 2, 2011
`
`[Page 15]
`
`

`

`Internet -Draft
`
`HTTP Live Streaming
`
`March 2011
`
`The server MUST meet the following constraints when producing variant
`streams:
`
`Each variant stream MUST present the same content,
`stream discontinuities.
`
`including
`
`Each variant Playlist file MUST have the same target duration.
`
`Content that appears in one variant Playlist file but not in
`another MUST appear either at the beginning or at the end of the
`Playlist file and MUST NOT be longer than the target duration.
`
`Matching content in variant streams MUST have matching timestamps.
`This allows clients to synchronize the streams.
`
`Elementary Audio Stream files MUST signal the timestamp of the
`first sample in the file by prepending an ID3 PRIV tag [ID3] with
`an owner identifier of
`The binary data
`"com.apple.streaming.transportStreamTimestamp".
`MUST be a 33-bit MPEG-2 Program Elementary Stream timestamp
`expressed as a big-endian eight-octet number, with the upper 31
`bits set to zero.
`
`In addition, all variant streams SHOULD contain the same encoded
`audio bitstream. This allows clients to switch between streams
`without audible glitching.
`
`6.3. Client Process
`
`6.3.1.
`
`Introduction
`
`How the client obtains the URI to the Playlist file is outside the
`scope of this document; it is presumed to have done so.
`
`If the
`The client MUST obtain the Playlist file from the URI.
`Playlist file so obtained is a variant Playlist,
`the client MUST
`obtain the Playlist file from the variant Playlist.
`
`This document does not specify the treatment of variant streams by
`clients.
`
`6.3.2. Loading the Playlist file
`
`Every time a Playlist file is loaded or reloaded from the Playlist
`URI:
`
`The client MUST ensure that the Playlist file begins with the
`EXTM3U tag and that the EXT-X-VERSION tag, if present, specifies a
`
`Pantos & May
`
`Expires October 2, 2011
`
`[Page 16]
`
`

`

`Internet -Draft
`
`HTTP Live Streaming
`
`March 2011
`
`protocol version supported by the client; if not,
`NOT attempt to use the Playlist.
`
`the client MUST
`
`The client SHOULD ignore any tags and attributes it does not
`recognize.
`
`The client MUST determine the next media file to load as described
`in Section 6.3.5.
`
`the client
`If the Playlist contains the EXT-X-MEDIA-SEQUENCE tag,
`SHOULD assume that each media file in it will become unavailable at
`the time that the Playlist file was loaded plus the duration of the
`Playlist file.
`The duration of a Playlist file is the sum of the
`durations of the media files within it.
`
`6.3.3. Playing the Playlist file
`
`The client SHALL choose which media file to play first from the
`Playlist when playback starts.
`If the EXT-X-ENDLIST tag is not
`in
`present and the client intends to play the media regularly (i.e.
`playlist order at the nominal playback rate),
`the client SHOULD NOT
`choose a file which starts less than three target durations from the
`end of the Playlist file. Doing so can trigger playback stalls.
`
`To achieve regular playback, media files MUST be played in the order
`that they appear in the Playlist file.
`The client MAY present the
`available media in any way it wishes,
`including regular playback,
`random access, and trick modes.
`
`The client MUST be prepared to reset its parser(s) and decoder(s)
`before playing a media file that is preceded by an EXT-X-
`DISCONTINUITY tag.
`
`The client SHOULD attempt to load media files in advance of when they
`will be required for uninterrupted playback to compensate for
`temporary variations in latency and throughput.
`
`If the Playlist file contains the EXT-X-ALLOW-CACHE tag and its value
`is NO,
`the client MUST NOT cache downloaded media files after they
`have been played. Otherwise the client MAY cache downloaded media
`files indefinitely for later replay.
`
`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,
`but if it does not the client MUST NOT infer an originating time
`zone.
`
`Pantos & May
`
`Expires October 2, 2011
`
`[Page 17]
`
`

`

`Internet -Draft
`
`HTTP Live Streaming
`
`March 2011
`
`The client MUST NOT depend upon the correctness or the consistency of
`the value of the EXT-X-PROGRAM-DATE-TIME tag.
`
`6.3.4. Reloading the Playlist file
`
`The client MUST periodically reload the Playlist file unless it
`contains the EXT-X-ENDLIST tag.
`
`However the client MUST NOT attempt to reload the Playlist file more
`frequently than specified by this section.
`
`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 a period of time before
`attempting to reload the Playlist file again. This period is called
`the initial minimum reload delay.
`It is measured from the time that
`the client began loading the Playlist file.
`
`The initial minimum reload delay is the duration of the last media
`file in the Playlist. Media file duration is specified by the EXTINF
`tag.
`
`If the client reloads a Playlist file and finds that it has not
`The
`changed then it MUST wait for a period of time before retrying.
`minimum delay is a multiple of the target duration. This multiple is
`@.5 for the first attempt, 1.5 for the second, and 3.@ thereafter.
`
`the client SHOULD NOT reload the
`In order to reduce server load,
`Playlist files of variant streams that are not currently being
`played.
`If it decides to switch playback to a different variant, it
`SHOULD stop reloading the Playlist of the old variant and begin
`loading the Playlist of the new variant.
`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 has been loaded,
`the timestamps in the media files can be
`used to synchronize the old and new timelines precisely.
`
`6.3.5. Determining the next file to load
`
`The client MUST examine the Playlist file every time it is loaded or
`reloaded to determine the next media file to load.
`
`The first file to load MUST be the file that the client has chosen to
`play first, as described in Section 6.3.3.
`
`If the first file to be played has been loaded and the Playlist file
`does not contain the EXT-X-MEDIA-SEQUENCE tag then the client MUST
`verify that the current Playlist file contains the URI of the last
`
`Pantos & May
`
`Expires October 2, 2011
`
`[Page 18]
`
`