idnits 2.17.1 draft-pantos-http-live-streaming-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 31, 2011) is 4775 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'A-Z' is mentioned on line 204, but not defined == Missing Reference: '0-9' is mentioned on line 216, but not defined == Missing Reference: 'A-F' is mentioned on line 212, but not defined ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2965 (Obsoleted by RFC 6265) ** Obsolete normative reference: RFC 4281 (Obsoleted by RFC 6381) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Informational R. Pantos, Ed. 3 Internet-Draft W. May 4 Intended status: Informational Apple Inc. 5 Expires: October 2, 2011 March 31, 2011 7 HTTP Live Streaming 8 draft-pantos-http-live-streaming-06 10 Abstract 12 This document describes a protocol for transferring unbounded streams 13 of multimedia data. It specifies the data format of the files and 14 the actions to be taken by the server (sender) and the clients 15 (receivers) of the streams. It describes version 3 of this protocol. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. This document may not be modified, 21 and derivative works of it may not be created, and it may not be 22 published except as an Internet-Draft. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on October 2, 2011. 36 Copyright Notice 38 Copyright (c) 2011 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. 48 This Informational Internet Draft is submitted as an RFC Editor 49 Contribution and/or non-IETF Document (not as a Contribution, IETF 50 Contribution, nor IETF Document) in accordance with BCP 78 and BCP 51 79. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. The Playlist file . . . . . . . . . . . . . . . . . . . . . . 4 58 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.2. Attribute Lists . . . . . . . . . . . . . . . . . . . . . 5 60 3.3. New Tags . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 3.3.1. EXT-X-TARGETDURATION . . . . . . . . . . . . . . . . . 7 62 3.3.2. EXT-X-MEDIA-SEQUENCE . . . . . . . . . . . . . . . . . 7 63 3.3.3. EXT-X-KEY . . . . . . . . . . . . . . . . . . . . . . 7 64 3.3.4. EXT-X-PROGRAM-DATE-TIME . . . . . . . . . . . . . . . 8 65 3.3.5. EXT-X-ALLOW-CACHE . . . . . . . . . . . . . . . . . . 8 66 3.3.6. EXT-X-PLAYLIST-TYPE . . . . . . . . . . . . . . . . . 9 67 3.3.7. EXT-X-ENDLIST . . . . . . . . . . . . . . . . . . . . 9 68 3.3.8. EXT-X-STREAM-INF . . . . . . . . . . . . . . . . . . . 9 69 3.3.9. EXT-X-DISCONTINUITY . . . . . . . . . . . . . . . . . 10 70 3.3.10. EXT-X-VERSION . . . . . . . . . . . . . . . . . . . . 10 71 4. Media files . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 5. Key files . . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 12 74 5.2. IV for AES-128 . . . . . . . . . . . . . . . . . . . . . . 12 75 6. Client/Server Actions . . . . . . . . . . . . . . . . . . . . 12 76 6.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 12 77 6.2. Server Process . . . . . . . . . . . . . . . . . . . . . . 12 78 6.2.1. Introduction . . . . . . . . . . . . . . . . . . . . . 12 79 6.2.2. Sliding Window Playlists . . . . . . . . . . . . . . . 14 80 6.2.3. Encrypting media files . . . . . . . . . . . . . . . . 15 81 6.2.4. Providing variant streams . . . . . . . . . . . . . . 15 82 6.3. Client Process . . . . . . . . . . . . . . . . . . . . . . 16 83 6.3.1. Introduction . . . . . . . . . . . . . . . . . . . . . 16 84 6.3.2. Loading the Playlist file . . . . . . . . . . . . . . 16 85 6.3.3. Playing the Playlist file . . . . . . . . . . . . . . 17 86 6.3.4. Reloading the Playlist file . . . . . . . . . . . . . 18 87 6.3.5. Determining the next file to load . . . . . . . . . . 18 88 6.3.6. Decrypting encrypted media files . . . . . . . . . . . 19 89 7. Protocol version compatibility . . . . . . . . . . . . . . . . 19 90 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 91 8.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 19 92 8.2. Simple Playlist file . . . . . . . . . . . . . . . . . . . 20 93 8.3. Sliding Window Playlist, using HTTPS . . . . . . . . . . . 20 94 8.4. Playlist file with encrypted media files . . . . . . . . . 20 95 8.5. Variant Playlist file . . . . . . . . . . . . . . . . . . 21 96 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21 97 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 98 11. Security Considerations . . . . . . . . . . . . . . . . . . . 22 99 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 100 12.1. Normative References . . . . . . . . . . . . . . . . . . . 23 101 12.2. Informative References . . . . . . . . . . . . . . . . . . 24 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 104 1. Introduction 106 This document describes a protocol for transferring unbounded streams 107 of multimedia data. The protocol supports the encryption of media 108 data and the provision of alternate versions (e.g. bitrates) of a 109 stream. Media data can be transferred soon after it is created, 110 allowing it to be played in near real-time. Data is usually carried 111 over HTTP [RFC2616]. 113 External references that describe related standards such as HTTP are 114 listed in Section 11. 116 2. Summary 118 A multimedia presentation is specified by a URI [RFC3986] to a 119 Playlist file, which is an ordered list of media URIs and 120 informational tags. Each media URI refers to a media file which is a 121 segment of a single contiguous stream. 123 To play the stream, the client first obtains the Playlist file and 124 then obtains and plays each media file in the Playlist. It reloads 125 the Playlist file as described in this document to discover 126 additional segments. 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in RFC 2119 [RFC2119]. 132 3. The Playlist file 134 3.1. Introduction 136 Playlists MUST be Extended M3U Playlist files [M3U]. This document 137 extends the M3U file format by defining additional tags. 139 An M3U Playlist is a text file that consists of individual lines. 140 Lines are terminated by either a single LF character or a CR 141 character followed by an LF character. Each line is a URI, a blank, 142 or starts with the comment character '#'. Blank lines are ignored. 143 White space MUST NOT be present, except for elements in which it is 144 explicitly specified. 146 A URI line identifies a media file or a variant Playlist file (see 147 Section 3.3.8). 149 URIs MAY be relative. A relative URI MUST be resolved against the 150 URI of the Playlist file that contains it. 152 Lines that start with the comment character '#' are either comments 153 or tags. Tags begin with #EXT. All other lines that begin with '#' 154 are comments and SHOULD be ignored. 156 The duration of a Playlist file is the sum of the durations of the 157 media files within it. 159 M3U Playlist files whose names end in .m3u8 and/or have the HTTP 160 Content-Type "application/vnd.apple.mpegurl" are encoded in UTF-8 161 [RFC3629]. Files whose names end with .m3u and/or have the HTTP 162 Content-Type [RFC2616] "audio/mpegurl" are encoded in US-ASCII 163 [US_ASCII]. 165 Playlist files MUST have names that end in .m3u8 and/or have the 166 Content-Type "application/vnd.apple.mpegurl" (if transferred over 167 HTTP), or have names that end in .m3u and/or have the HTTP Content- 168 Type type "audio/mpegurl" (for compatibility). 170 The Extended M3U file format defines two tags: EXTM3U and EXTINF. An 171 Extended M3U file is distinguished from a basic M3U file by its first 172 line, which MUST be #EXTM3U. 174 EXTINF is a record marker that describes the media file identified by 175 the URI that follows it. Each media file URI MUST be preceded by an 176 EXTINF tag. Its format is: 178 #EXTINF:, 180 "duration" is an integer or floating-point number in decimal 181 positional notation that specifies the duration of the media file in 182 seconds. Integer durations SHOULD be rounded to the nearest integer. 183 Durations MUST be integers if the protocol version of the Playlist 184 file is less than 3. The remainder of the line following the comma 185 is the title of the media file, which is an optional human-readable 186 informative title of the media segment. 188 This document defines the following new tags: EXT-X-TARGETDURATION, 189 EXT-X-MEDIA-SEQUENCE, EXT-X-KEY, EXT-X-PROGRAM-DATE-TIME, EXT-X- 190 ALLOW-CACHE, EXT-X-PLAYLIST-TYPE, EXT-X-STREAM-INF, EXT-X-ENDLIST, 191 EXT-X-DISCONTINUITY, and EXT-X-VERSION. 193 3.2. Attribute Lists 195 Certain extended M3U tags have values which are Attribute Lists. An 196 Attribute List is a comma-separated list of attribute/value pairs 197 with no whitespace. 199 An attribute/value pair has the following syntax: 201 AttributeName=AttributeValue 203 An AttributeName is an unquoted string containing characters from the 204 set [A-Z]. 206 An AttributeValue is one of the following: 208 o decimal-integer: an unquoted string of characters from the set 209 [0-9] expressing an integer in base-10 arithmetic. 211 o hexadecimal-integer: an unquoted string of characters from the set 212 [0-9] and [A-F] that is prefixed with 0x or 0X and which expresses 213 an integer in base-16 arithmetic. 215 o decimal-floating-point: an unquoted string of characters from the 216 set [0-9] and '.' which expresses a floating-point number in 217 decimal positional notation. 219 o quoted-string: a string of characters within a pair of double- 220 quotes ("). The set of characters allowed in the string and any 221 rules for escaping special characters are specified by the 222 Attribute definition, but any double-quote (") character and any 223 carriage-return or linefeed will always be replaced by an escape 224 sequence. 226 o enumerated-string: an unquoted character string from a set which 227 is explicitly defined by the Attribute. An enumerated-string will 228 never contain double-quotes ("), commas (,), or whitespace. 230 o decimal-resolution: two decimal-integers separated by the "x" 231 character, indicating horizontal and vertical pixel dimensions. 233 The type of the AttributeValue for a given AttributeName is specified 234 by the Attribute definition. 236 A given AttributeName MUST NOT appear more than once in a given 237 Attribute List. 239 An Attribute/value pair with an unrecognized AttributeName MUST be 240 ignored by the client. 242 Attribute/value pairs of type enumerated-string that contain 243 unrecognized values SHOULD be ignored by the client. 245 3.3. New Tags 247 3.3.1. EXT-X-TARGETDURATION 249 The EXT-X-TARGETDURATION tag specifies the maximum media file 250 duration. The EXTINF duration of each media file in the Playlist 251 file MUST be less than or equal to the target duration. This tag 252 MUST appear once in the Playlist file. Its format is: 254 #EXT-X-TARGETDURATION:<s> 256 where s is an integer indicating the target duration in seconds. 258 3.3.2. EXT-X-MEDIA-SEQUENCE 260 Each media file URI in a Playlist has a unique integer sequence 261 number. The sequence number of a URI is equal to the sequence number 262 of the URI that preceded it plus one. The EXT-X-MEDIA-SEQUENCE tag 263 indicates the sequence number of the first URI that appears in a 264 Playlist file. Its format is: 266 #EXT-X-MEDIA-SEQUENCE:<number> 268 A Playlist file MUST NOT contain more than one EXT-X-MEDIA-SEQUENCE 269 tag. If the Playlist file does not contain an EXT-X-MEDIA-SEQUENCE 270 tag then the sequence number of the first URI in the playlist SHALL 271 be considered to be 0. 273 A media file's sequence number is not required to appear in its URI. 275 See Section 6.3.2 and Section 6.3.5 for information on handling the 276 EXT-X-MEDIA-SEQUENCE tag. 278 3.3.3. EXT-X-KEY 280 Media files MAY be encrypted. The EXT-X-KEY tag provides information 281 necessary to decrypt media files that follow it. Its format is: 283 #EXT-X-KEY:<attribute-list> 285 The following attributes are defined: 287 The METHOD attribute specifies the encryption method. It is of type 288 enumerated-string. Each EXT-X-KEY tag MUST contain a METHOD 289 attribute. 291 Two methods are defined: NONE and AES-128. 293 An encryption method of NONE means that media files are not 294 encrypted. If the encryption method is NONE, the URI and the IV 295 attributes MUST NOT be present. 297 An encryption method of AES-128 means that media files are encrypted 298 using the Advanced Encryption Standard [AES_128] with a 128-bit key 299 and PKCS7 padding [RFC5652]. If the encryption method is AES-128, 300 the URI attribute MUST be present. The IV attribute MAY be present; 301 see Section 5.2. 303 The URI attribute specifies how to obtain the key. Its value is a 304 quoted-string that contains a URI [RFC3986] for the key. 306 The IV attribute, if present, specifies the Initialization Vector to 307 be used with the key. Its value is a hexadecimal-integer. The IV 308 attribute appeared in protocol version 2. 310 A new EXT-X-KEY supersedes any prior EXT-X-KEY. 312 If the Playlist file does not contain an EXT-X-KEY tag then media 313 files are not encrypted. 315 See Section 5 for the format of the key file, and Section 5.2, 316 Section 6.2.3 and Section 6.3.6 for additional information on media 317 file encryption. 319 3.3.4. EXT-X-PROGRAM-DATE-TIME 321 The EXT-X-PROGRAM-DATE-TIME tag associates the beginning of the next 322 media file with an absolute date and/or time. The date/time 323 representation is ISO/IEC 8601:2004 [ISO_8601] and SHOULD indicate a 324 time zone. For example: 326 #EXT-X-PROGRAM-DATE-TIME:<YYYY-MM-DDThh:mm:ssZ> 328 See Section 6.2.1 and Section 6.3.3 for more information on the EXT- 329 X-PROGRAM-DATE-TIME tag. 331 3.3.5. EXT-X-ALLOW-CACHE 333 The EXT-X-ALLOW-CACHE tag indicates whether the client MAY or MUST 334 NOT cache downloaded media files for later replay. It MAY occur 335 anywhere in the Playlist file; it MUST NOT occur more than once. The 336 EXT-X-ALLOW-CACHE tag applies to all segments in the playlist. Its 337 format is: 339 #EXT-X-ALLOW-CACHE:<YES|NO> 340 See Section 6.3.3 for more information on the EXT-X-ALLOW-CACHE tag. 342 3.3.6. EXT-X-PLAYLIST-TYPE 344 The EXT-X-PLAYLIST-TYPE tag provides mutability information about the 345 Playlist file. It is optional. Its format is: 347 #EXT-X-PLAYLIST-TYPE:<EVENT|VOD> 349 Section 6.2.1 defines the implications of the EXT-X-PLAYLIST-TYPE 350 tag. 352 3.3.7. EXT-X-ENDLIST 354 The EXT-X-ENDLIST tag indicates that no more media files will be 355 added to the Playlist file. It MAY occur anywhere in the Playlist 356 file; it MUST NOT occur more than once. Its format is: 358 #EXT-X-ENDLIST 360 3.3.8. EXT-X-STREAM-INF 362 The EXT-X-STREAM-INF tag indicates that the next URI in the Playlist 363 file identifies another Playlist file. Its format is: 365 #EXT-X-STREAM-INF:<attribute-list> 366 <URI> 368 The following attributes are defined: 370 BANDWIDTH 372 The value is a decimal-integer of bits per second. It MUST be an 373 upper bound of the overall bitrate of each media file, calculated to 374 include container overhead, that appears or will appear in the 375 Playlist. 377 Every EXT-X-STREAM-INF tag MUST include the BANDWIDTH attribute. 379 PROGRAM-ID 381 The value is a decimal-integer that uniquely identifies a particular 382 presentation within the scope of the Playlist file. 384 A Playlist file MAY contain multiple EXT-X-STREAM-INF tags with the 385 same PROGRAM-ID to identify different encodings of the same 386 presentation. These variant playlists MAY contain additional EXT-X- 387 STREAM-INF tags. 389 CODECS 391 The value is a quoted-string containing a comma-separated list of 392 formats, where each format specifies a media sample type that is 393 present in a media file in the Playlist file. Valid format 394 identifiers are those in the ISO File Format Name Space defined by 395 RFC 4281 [RFC4281]. 397 Every EXT-X-STREAM-INF tag SHOULD include a CODECS attribute. 399 RESOLUTION 401 The value is a decimal-resolution describing the approximate encoded 402 horizontal and vertical resolution of video within the stream. 404 3.3.9. EXT-X-DISCONTINUITY 406 The EXT-X-DISCONTINUITY tag indicates an encoding discontinuity 407 between the media file that follows it and the one that preceded it. 408 The set of characteristics that MAY change is: 410 o file format 412 o number and type of tracks 414 o encoding parameters 416 o encoding sequence 418 o timestamp sequence 420 Its format is: 422 #EXT-X-DISCONTINUITY 424 See Section 4, Section 6.2.1, and Section 6.3.3 for more information 425 about the EXT-X-DISCONTINUITY tag. 427 3.3.10. EXT-X-VERSION 429 The EXT-X-VERSION tag indicates the compatibility version of the 430 Playlist file. The Playlist file, its associated media, and its 431 server MUST comply with all provisions of the most-recent version of 432 this document describing the protocol version indicated by the tag 433 value. 435 Its format is: 437 #EXT-X-VERSION:<n> 439 where n is an integer indicating the protocol version. 441 A Playlist file MUST NOT contain more than one EXT-X-VERSION tag. A 442 Playlist file that does not contain an EXT-X-VERSION tag MUST comply 443 with version 1 of this protocol. 445 4. Media files 447 Each media file URI in a Playlist file MUST identify a media file 448 which is a segment of the overall presentation. Each media file MUST 449 be formatted as an MPEG-2 Transport Stream or an MPEG-2 audio 450 elementary stream [ISO_13818]. 452 Transport Stream files MUST contain a single MPEG-2 Program. There 453 SHOULD be a Program Association Table and a Program Map Table at the 454 start of each file. A file that contains video SHOULD have at least 455 one key frame and enough information to completely initialize a video 456 decoder. 458 A media file in a Playlist MUST be the continuation of the encoded 459 stream at the end of the media file with the previous sequence number 460 unless it was the first media file ever to appear in the Playlist 461 file or it is prefixed by an EXT-X-DISCONTINUITY tag. 463 Clients SHOULD be prepared to handle multiple tracks of a particular 464 type (e.g. audio or video). A client with no other preference SHOULD 465 choose the one with the lowest numerical PID that it can play. 467 Clients MUST ignore private streams inside Transport Streams that 468 they do not recognize. 470 The encoding parameters for samples within a stream inside a media 471 file and between corresponding streams across multiple media files 472 SHOULD remain consistent. However clients SHOULD deal with encoding 473 changes as they are encountered, for example by scaling video content 474 to accommodate a resolution change. 476 5. Key files 477 5.1. Introduction 479 An EXT-X-KEY tag with the URI attribute identifies a Key file. A Key 480 file contains the cipher key that MUST be used to decrypt subsequent 481 media files in the Playlist. 483 The AES-128 encryption method uses 16-octet keys. The format of the 484 Key file is simply a packed array of these 16 octets in binary 485 format. 487 5.2. IV for AES-128 489 128-bit AES requires the same 16-octet Initialization Vector (IV) to 490 be supplied when encrypting and decrypting. Varying this IV 491 increases the strength of the cipher. 493 If the EXT-X-KEY tag has the IV attribute, implementations MUST use 494 the attribute value as the IV when encrypting or decrypting with that 495 key. The value MUST be interpreted as a 128-bit hexadecimal number 496 and MUST be prefixed with 0x or 0X. 498 If the EXT-X-KEY tag does not have the IV attribute, implementations 499 MUST use the sequence number of the media file as the IV when 500 encrypting or decrypting that media file. The big-endian binary 501 representation of the sequence number SHALL be placed in a 16-octet 502 buffer and padded (on the left) with zeros. 504 6. Client/Server Actions 506 6.1. Introduction 508 This section describes how the server generates the Playlist and 509 media files and how the client should download and play them. 511 6.2. Server Process 513 6.2.1. Introduction 515 The production of the MPEG-2 stream is outside the scope of this 516 document, which simply presumes a source of a continuous stream 517 containing the presentation. 519 The server MUST divide the stream into individual media files whose 520 duration is less than or equal to a constant target duration. The 521 server SHOULD attempt to divide the stream at points that support 522 effective decode of individual media files, e.g. on packet and key 523 frame boundaries. 525 The server MUST create a URI for each media file that will allow its 526 clients to obtain the file. 528 The server MUST create a Playlist file. The Playlist file MUST 529 conform to the format described in Section 3. A URI for each media 530 file that the server wishes to make available MUST appear in the 531 Playlist in the order in which it is to be played. The entire media 532 file MUST be available to clients if its URI is in the Playlist file. 534 The Playlist file MUST contain an EXT-X-TARGETDURATION tag. Its 535 value MUST be equal to or greater than the EXTINF value of any media 536 file that appears or will appear in the Playlist file. Its value 537 MUST NOT change. A typical target duration is 10 seconds. 539 The Playlist file SHOULD contain one EXT-X-VERSION tag which 540 indicates the compatibility version of the stream. Its value MUST be 541 the lowest protocol version with which the server, Playlist file, and 542 associated media files all comply. 544 The server MUST create a URI for the Playlist file that will allow 545 its clients to obtain the file. 547 If the Playlist file is distributed by HTTP, the server SHOULD 548 support client requests to use the "gzip" Content-Encoding. 550 Changes to the Playlist file MUST be made atomically from the point 551 of view of the clients. 553 The server MUST NOT change the Playlist file, except to: 555 Append lines to it (Section 6.2.1). 557 Remove media file URIs from the Playlist in the order that they 558 appear, along with any tags that apply only to those media files 559 (Section 6.2.2). 561 Change the value of the EXT-X-MEDIA-SEQUENCE tag (Section 6.2.2). 563 Add or remove EXT-X-STREAM-INF tags (Section 6.2.4). Note that 564 clients are not required to reload variant Playlist files, so 565 changing them may not have immediate effect. 567 Add an EXT-X-ENDLIST tag to the Playlist (Section 6.2.1). 569 Furthermore, the Playlist file MAY contain an EXT-X-PLAYLIST-TYPE tag 570 with a value of either EVENT or VOD. If the tag is present and has a 571 value of EVENT, the server MUST NOT change or delete any part of the 572 Playlist file (although it MAY append lines to it). If the tag is 573 present and has a value of VOD, the Playlist file MUST NOT change. 575 Every media file URI in a Playlist MUST be prefixed with an EXTINF 576 tag indicating the duration of the media file. 578 The server MAY associate an absolute date and time with a media file 579 by prefixing its URI with an EXT-X-PROGRAM-DATE-TIME tag. The value 580 of the date and time provides an informative mapping of the timeline 581 of the media to an appropriate wall-clock time, which may be used as 582 a basis for seeking, for display, or for other purposes. If a server 583 provides this mapping, it SHOULD place an EXT-X-PROGRAM-DATE-TIME tag 584 after every EXT-X-DISCONTINUITY tag in the Playlist file. 586 If the Playlist contains the final media file of the presentation 587 then the Playlist file MUST contain the EXT-X-ENDLIST tag. 589 If the Playlist does not contain the EXT-X-ENDLIST tag, the server 590 MUST make a new version of the Playlist file available that contains 591 at least one new media file URI. It MUST be made available relative 592 to the time that the previous version of the Playlist file was made 593 available: no earlier than one-half the target duration after that 594 time, and no later than 1.5 times the target duration after that 595 time. 597 If the server wishes to remove an entire presentation, it MUST make 598 the Playlist file unavailable to clients. It SHOULD ensure that all 599 media files in the Playlist file remain available to clients for at 600 least the duration of the Playlist file at the time of removal. 602 6.2.2. Sliding Window Playlists 604 The server MAY limit the availability of media files to those which 605 have been most recently added to the Playlist. To do so the Playlist 606 file MUST ALWAYS contain exactly one EXT-X-MEDIA-SEQUENCE tag. Its 607 value MUST be incremented by 1 for every media file URI that is 608 removed from the Playlist file. 610 Media file URIs MUST be removed from the Playlist file in the order 611 in which they were added. 613 The server MUST NOT remove a media file URI from the Playlist file if 614 the duration of the Playlist file minus the duration of the media 615 file is less than three times the target duration. 617 When the server removes a media file URI from the Playlist, the media 618 file SHOULD remain available to clients for a period of time equal to 619 the duration of the media file plus the duration of the longest 620 Playlist file in which the media file has appeared. 622 If a server plans to remove a media file after it is delivered to 623 clients over HTTP, it SHOULD ensure that the HTTP response contains 624 an Expires header that reflects the planned time-to-live. 626 6.2.3. Encrypting media files 628 If media files are to be encrypted the server MUST define a URI which 629 will allow authorized clients to obtain a Key file containing a 630 decryption key. The Key file MUST conform to the format described in 631 Section 5. 633 The server MAY set the HTTP Expires header in the key response to 634 indicate that the key may be cached. 636 If the encryption METHOD is AES-128, AES-128 CBC encryption SHALL be 637 applied to individual media files. The entire file MUST be 638 encrypted. Cipher Block Chaining MUST NOT be applied across media 639 files. The IV used for encryption MUST be either the sequence number 640 of the media file or the value of the IV attribute of the EXT-X-KEY 641 tag, as described in Section 5.2. 643 The server MUST encrypt every media file in a Playlist using the 644 method and other attributes specified by the EXT-X-KEY tag that most 645 immediately precedes its URI in the Playlist file. Media files 646 preceded by an EXT-X-KEY tag whose METHOD is NONE, or not preceded by 647 any EXT-X-KEY tag, MUST NOT be encrypted. 649 The server MUST NOT remove an EXT-X-KEY tag from the Playlist file if 650 the Playlist file contains a URI to a media file encrypted with that 651 key. 653 6.2.4. Providing variant streams 655 A server MAY offer multiple Playlist files to provide different 656 encodings of the same presentation. If it does so it SHOULD provide 657 a variant Playlist file that lists each variant stream to allow 658 clients to switch between encodings dynamically. 660 Variant Playlists MUST contain an EXT-X-STREAM-INF tag for each 661 variant stream. Each EXT-X-STREAM-INF tag for the same presentation 662 MUST have the same PROGRAM-ID attribute value. The PROGRAM-ID value 663 for each presentation MUST be unique within the variant Playlist. 665 If an EXT-X-STREAM-INF tag contains the CODECS attribute, the 666 attribute value MUST include every format defined by [RFC4281] that 667 is present in any media file that appears or will appear in the 668 Playlist file. 670 The server MUST meet the following constraints when producing variant 671 streams: 673 Each variant stream MUST present the same content, including 674 stream discontinuities. 676 Each variant Playlist file MUST have the same target duration. 678 Content that appears in one variant Playlist file but not in 679 another MUST appear either at the beginning or at the end of the 680 Playlist file and MUST NOT be longer than the target duration. 682 Matching content in variant streams MUST have matching timestamps. 683 This allows clients to synchronize the streams. 685 Elementary Audio Stream files MUST signal the timestamp of the 686 first sample in the file by prepending an ID3 PRIV tag [ID3] with 687 an owner identifier of 688 "com.apple.streaming.transportStreamTimestamp". The binary data 689 MUST be a 33-bit MPEG-2 Program Elementary Stream timestamp 690 expressed as a big-endian eight-octet number, with the upper 31 691 bits set to zero. 693 In addition, all variant streams SHOULD contain the same encoded 694 audio bitstream. This allows clients to switch between streams 695 without audible glitching. 697 6.3. Client Process 699 6.3.1. Introduction 701 How the client obtains the URI to the Playlist file is outside the 702 scope of this document; it is presumed to have done so. 704 The client MUST obtain the Playlist file from the URI. If the 705 Playlist file so obtained is a variant Playlist, the client MUST 706 obtain the Playlist file from the variant Playlist. 708 This document does not specify the treatment of variant streams by 709 clients. 711 6.3.2. Loading the Playlist file 713 Every time a Playlist file is loaded or reloaded from the Playlist 714 URI: 716 The client MUST ensure that the Playlist file begins with the 717 EXTM3U tag and that the EXT-X-VERSION tag, if present, specifies a 718 protocol version supported by the client; if not, the client MUST 719 NOT attempt to use the Playlist. 721 The client SHOULD ignore any tags and attributes it does not 722 recognize. 724 The client MUST determine the next media file to load as described 725 in Section 6.3.5. 727 If the Playlist contains the EXT-X-MEDIA-SEQUENCE tag, the client 728 SHOULD assume that each media file in it will become unavailable at 729 the time that the Playlist file was loaded plus the duration of the 730 Playlist file. The duration of a Playlist file is the sum of the 731 durations of the media files within it. 733 6.3.3. Playing the Playlist file 735 The client SHALL choose which media file to play first from the 736 Playlist when playback starts. If the EXT-X-ENDLIST tag is not 737 present and the client intends to play the media regularly (i.e. in 738 playlist order at the nominal playback rate), the client SHOULD NOT 739 choose a file which starts less than three target durations from the 740 end of the Playlist file. Doing so can trigger playback stalls. 742 To achieve regular playback, media files MUST be played in the order 743 that they appear in the Playlist file. The client MAY present the 744 available media in any way it wishes, including regular playback, 745 random access, and trick modes. 747 The client MUST be prepared to reset its parser(s) and decoder(s) 748 before playing a media file that is preceded by an EXT-X- 749 DISCONTINUITY tag. 751 The client SHOULD attempt to load media files in advance of when they 752 will be required for uninterrupted playback to compensate for 753 temporary variations in latency and throughput. 755 If the Playlist file contains the EXT-X-ALLOW-CACHE tag and its value 756 is NO, the client MUST NOT cache downloaded media files after they 757 have been played. Otherwise the client MAY cache downloaded media 758 files indefinitely for later replay. 760 The client MAY use the value of the EXT-X-PROGRAM-DATE-TIME tag to 761 display the program origination time to the user. If the value 762 includes time zone information the client SHALL take it into account, 763 but if it does not the client MUST NOT infer an originating time 764 zone. 766 The client MUST NOT depend upon the correctness or the consistency of 767 the value of the EXT-X-PROGRAM-DATE-TIME tag. 769 6.3.4. Reloading the Playlist file 771 The client MUST periodically reload the Playlist file unless it 772 contains the EXT-X-ENDLIST tag. 774 However the client MUST NOT attempt to reload the Playlist file more 775 frequently than specified by this section. 777 When a client loads a Playlist file for the first time or reloads a 778 Playlist file and finds that it has changed since the last time it 779 was loaded, the client MUST wait for a period of time before 780 attempting to reload the Playlist file again. This period is called 781 the initial minimum reload delay. It is measured from the time that 782 the client began loading the Playlist file. 784 The initial minimum reload delay is the duration of the last media 785 file in the Playlist. Media file duration is specified by the EXTINF 786 tag. 788 If the client reloads a Playlist file and finds that it has not 789 changed then it MUST wait for a period of time before retrying. The 790 minimum delay is a multiple of the target duration. This multiple is 791 0.5 for the first attempt, 1.5 for the second, and 3.0 thereafter. 793 In order to reduce server load, the client SHOULD NOT reload the 794 Playlist files of variant streams that are not currently being 795 played. If it decides to switch playback to a different variant, it 796 SHOULD stop reloading the Playlist of the old variant and begin 797 loading the Playlist of the new variant. It can use the EXTINF 798 durations and the constraints in Section 6.2.4 to determine the 799 approximate location of corresponding media. Once media from the new 800 variant has been loaded, the timestamps in the media files can be 801 used to synchronize the old and new timelines precisely. 803 6.3.5. Determining the next file to load 805 The client MUST examine the Playlist file every time it is loaded or 806 reloaded to determine the next media file to load. 808 The first file to load MUST be the file that the client has chosen to 809 play first, as described in Section 6.3.3. 811 If the first file to be played has been loaded and the Playlist file 812 does not contain the EXT-X-MEDIA-SEQUENCE tag then the client MUST 813 verify that the current Playlist file contains the URI of the last 814 loaded media file at the offset it was originally found at, halting 815 playback if it does not. The next media file to load MUST be the 816 first media file URI following the last-loaded URI in the Playlist. 818 If the first file to be played has been loaded and the Playlist file 819 contains the EXT-X-MEDIA-SEQUENCE tag then the next media file to 820 load SHALL be the one with the lowest sequence number that is greater 821 than the sequence number of the last media file loaded. 823 6.3.6. Decrypting encrypted media files 825 If a Playlist file contains an EXT-X-KEY tag that specifies a Key 826 file URI, the client MUST obtain that key file and use the key inside 827 it to decrypt all media files following the EXT-X-KEY tag until 828 another EXT-X-KEY tag is encountered. 830 If the encryption METHOD is AES-128, AES-128 CBC decryption SHALL be 831 applied to individual media files. The entire file MUST be 832 decrypted. Cipher Block Chaining MUST NOT be applied across media 833 files. The IV used for decryption MUST be either the sequence number 834 of the media file or the value of the IV attribute of the EXT-X-KEY 835 tag, as described in Section 5.2. 837 If the encryption METHOD is NONE, the client MUST treat all media 838 files following the EXT-X-KEY tag as cleartext (not encrypted) until 839 another EXT-X-KEY tag is encountered. 841 7. Protocol version compatibility 843 Clients and servers MUST implement protocol version 2 or higher to 844 use: 846 o The IV attribute of the EXT-X-KEY tag. 848 Clients and servers MUST implement protocol version 3 or higher to 849 use: 851 o Floating-point EXTINF duration values. 853 8. Examples 855 8.1. Introduction 857 This section contains several example Playlist files. 859 8.2. Simple Playlist file 861 #EXTM3U 862 #EXT-X-TARGETDURATION:5220 863 #EXTINF:5220, 864 http://media.example.com/entire.ts 865 #EXT-X-ENDLIST 867 8.3. Sliding Window Playlist, using HTTPS 869 #EXTM3U 870 #EXT-X-TARGETDURATION:8 871 #EXT-X-MEDIA-SEQUENCE:2680 873 #EXTINF:8, 874 https://priv.example.com/fileSequence2680.ts 875 #EXTINF:8, 876 https://priv.example.com/fileSequence2681.ts 877 #EXTINF:8, 878 https://priv.example.com/fileSequence2682.ts 880 8.4. Playlist file with encrypted media files 882 #EXTM3U 883 #EXT-X-MEDIA-SEQUENCE:7794 884 #EXT-X-TARGETDURATION:15 886 #EXT-X-KEY:METHOD=AES-128,URI="https://priv.example.com/key.php?r=52" 888 #EXTINF:15, 889 http://media.example.com/fileSequence52-1.ts 890 #EXTINF:15, 891 http://media.example.com/fileSequence52-2.ts 892 #EXTINF:15, 893 http://media.example.com/fileSequence52-3.ts 895 #EXT-X-KEY:METHOD=AES-128,URI="https://priv.example.com/key.php?r=53" 897 #EXTINF:15, 898 http://media.example.com/fileSequence53-1.ts 900 8.5. Variant Playlist file 902 #EXTM3U 903 #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1280000 904 http://example.com/low.m3u8 905 #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=2560000 906 http://example.com/mid.m3u8 907 #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=7680000 908 http://example.com/hi.m3u8 909 #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=65000,CODECS="mp4a.40.5" 910 http://example.com/audio-only.m3u8 912 9. Contributors 914 Significant contributions to the design of this protocol were made by 915 Jim Batson, David Biderman, Bill May, Roger Pantos, and Alan Tseng. 917 10. IANA Considerations 919 This memo requests that the following MIME type [RFC2046] be 920 registered with the IANA: 922 Type name: "application" 924 Subtype name: "vnd.apple.mpegurl" 926 Required parameters: (none) 928 Optional parameters: (none) 930 Encoding considerations: encoded as text. See Section 3 for more 931 information. 933 Security considerations: See Section 11. 935 Compression: this media type does not employ compression. 937 Interoperability considerations: There are no byte-ordering issues, 938 since files are 7- or 8-bit text. Applications could encounter 939 unrecognized tags, which SHOULD be ignored. 941 Published specification: see Section 3. 943 Applications that use this media type: Multimedia applications such 944 as the iPhone media player (OS 3.0) and QuickTime Player in Mac OS X 945 Snow Leopard. 947 Additional information: files begin with the magic number #EXTM3U. 948 Filenames normally end with .m3u8 or .m3u (see Section 3). No 949 Macintosh file type codes have been registered. 951 Person & email address to contact for further information: David 952 Singer, singer AT apple.com. 954 Intended usage: LIMITED USE 956 Restrictions on usage: (none) 958 Author: Roger Pantos 960 Change Controller: David Singer 962 11. Security Considerations 964 Since the protocol generally uses HTTP to transfer data, most of the 965 same security considerations apply. See section 15 of RFC 2616 966 [RFC2616]. 968 Media file parsers are typically subject to "fuzzing" attacks. 969 Clients SHOULD take care when parsing files received from a server so 970 that non-compliant files are rejected. 972 Playlist files contain URIs, which clients will use to make network 973 requests of arbitrary entities. Clients SHOULD range-check responses 974 to prevent buffer overflows. See also the Security Considerations 975 section of RFC 3986 [RFC3986]. 977 Clients SHOULD load resources identified by URI lazily to avoid 978 contributing to denial-of-service attacks. 980 HTTP requests often include session state ("cookies"), which may 981 contain private user data. Implementations MUST follow cookie 982 restriction and expiry rules specified by RFC 2965 [RFC2965]. See 983 also the Security Considerations section of RFC 2965, and RFC 2964 984 [RFC2964]. 986 Encryption keys are specified by URI. The delivery of these keys 987 SHOULD be secured by a mechanism such as HTTP over TLS [RFC5246] 988 (formerly SSL) in conjunction with a secure realm or a session 989 cookie. 991 12. References 992 12.1. Normative References 994 [AES_128] U.S. Department of Commerce/National Institute of 995 Standards and Technology, "Advanced Encryption Standard 996 (AES), FIPS PUB 197", November 2001, <http:// 997 csrc.nist.gov/publications/fips/fips197/fips-197.pdf>. 999 [ISO_13818] 1000 International Organization for Standardization, "ISO/IEC 1001 International Standard 13818; Generic coding of moving 1002 pictures and associated audio information", October 2007, 1003 <http://www.iso.org/iso/catalogue_detail?csnumber=44169>. 1005 [ISO_8601] 1006 International Organization for Standardization, "ISO/IEC 1007 International Standard 8601:2004; Data elements and 1008 interchange formats -- Information interchange -- 1009 Representation of dates and times", December 2004, 1010 <http://www.iso.org/iso/catalogue_detail?csnumber=40874>. 1012 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1013 Extensions (MIME) Part Two: Media Types", RFC 2046, 1014 November 1996. 1016 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1017 Requirement Levels", BCP 14, RFC 2119, March 1997. 1019 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1020 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1021 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1023 [RFC2964] Moore, K. and N. Freed, "Use of HTTP State Management", 1024 BCP 44, RFC 2964, October 2000. 1026 [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management 1027 Mechanism", RFC 2965, October 2000. 1029 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1030 10646", STD 63, RFC 3629, November 2003. 1032 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1033 Resource Identifier (URI): Generic Syntax", STD 66, 1034 RFC 3986, January 2005. 1036 [RFC4281] Gellens, R., Singer, D., and P. Frojdh, "The Codecs 1037 Parameter for "Bucket" Media Types", RFC 4281, 1038 November 2005. 1040 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1041 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1043 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1044 RFC 5652, September 2009. 1046 [US_ASCII] 1047 American National Standards Institute, "ANSI X3.4-1986, 1048 Information Systems -- Coded Character Sets 7-Bit American 1049 National Standard Code for Information Interchange (7-Bit 1050 ASCII)", December 1986. 1052 12.2. Informative References 1054 [ID3] ID3.org, "The ID3 audio file data tagging format", 1055 <http://www.id3.org/Developer_Information>. 1057 [M3U] Nullsoft, Inc., "The M3U Playlist format, originally 1058 invented for the Winamp media player", 1059 <http://wikipedia.org/wiki/M3U>. 1061 Authors' Addresses 1063 Roger Pantos (editor) 1064 Apple Inc. 1065 Cupertino, California 1066 United States 1068 Email: http-live-streaming-review@group.apple.com 1070 William May, Jr. 1071 Apple Inc. 1072 Cupertino, California 1073 United States 1075 Email: http-live-streaming-review@group.apple.com