idnits 2.17.1 draft-pantos-http-live-streaming-03.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 (April 2, 2010) is 5137 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 ---------------------------------------------------------------------------- ** 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 (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Informational R. Pantos, Ed. 3 Internet-Draft Apple Inc. 4 Intended status: Informational April 2, 2010 5 Expires: October 4, 2010 7 HTTP Live Streaming 8 draft-pantos-http-live-streaming-03 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 2 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), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 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 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on October 4, 2010. 42 Copyright Notice 44 Copyright (c) 2010 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. 54 Pursuant to Section 8.f. of the Legal Provisions (see the IETF 55 Trust's Legal Provisions Relating to IETF Documents effective 56 December 28, 2009), Section 4 of the Legal Provisions does not apply 57 to this document. Thus, to the extent that this Informational 58 Internet Draft contains one or more Code Components, no license to 59 such Code Components is granted. Furthermore, this document may not 60 be modified, and derivative works of it may not be created, and it 61 may not be published except as an Internet-Draft. 63 Furthermore, this Informational Internet Draft is submitted as an RFC 64 Editor Contribution and/or non-IETF Document (not as a Contribution, 65 IETF Contribution, nor IETF Document) in accordance with BCP 78 and 66 BCP 79. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 3. The Playlist file . . . . . . . . . . . . . . . . . . . . . . 4 73 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 74 3.2. New Tags . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 3.2.1. EXT-X-TARGETDURATION . . . . . . . . . . . . . . . . . 6 76 3.2.2. EXT-X-MEDIA-SEQUENCE . . . . . . . . . . . . . . . . . 6 77 3.2.3. EXT-X-KEY . . . . . . . . . . . . . . . . . . . . . . 6 78 3.2.4. EXT-X-PROGRAM-DATE-TIME . . . . . . . . . . . . . . . 7 79 3.2.5. EXT-X-ALLOW-CACHE . . . . . . . . . . . . . . . . . . 7 80 3.2.6. EXT-X-ENDLIST . . . . . . . . . . . . . . . . . . . . 7 81 3.2.7. EXT-X-STREAM-INF . . . . . . . . . . . . . . . . . . . 8 82 3.2.8. EXT-X-DISCONTINUITY . . . . . . . . . . . . . . . . . 8 83 3.2.9. EXT-X-VERSION . . . . . . . . . . . . . . . . . . . . 9 84 4. Media files . . . . . . . . . . . . . . . . . . . . . . . . . 9 85 5. Key files . . . . . . . . . . . . . . . . . . . . . . . . . . 10 86 5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 10 87 5.2. IV for AES-128 . . . . . . . . . . . . . . . . . . . . . . 10 88 6. Client/Server Actions . . . . . . . . . . . . . . . . . . . . 11 89 6.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 11 90 6.2. Server Process . . . . . . . . . . . . . . . . . . . . . . 11 91 6.2.1. Introduction . . . . . . . . . . . . . . . . . . . . . 11 92 6.2.2. Sliding Window Playlists . . . . . . . . . . . . . . . 12 93 6.2.3. Encrypting media files . . . . . . . . . . . . . . . . 13 94 6.2.4. Providing variant streams . . . . . . . . . . . . . . 13 95 6.3. Client Process . . . . . . . . . . . . . . . . . . . . . . 14 96 6.3.1. Introduction . . . . . . . . . . . . . . . . . . . . . 14 97 6.3.2. Loading the Playlist file . . . . . . . . . . . . . . 14 98 6.3.3. Playing the Playlist file . . . . . . . . . . . . . . 15 99 6.3.4. Reloading the Playlist file . . . . . . . . . . . . . 16 100 6.3.5. Determining the next file to load . . . . . . . . . . 16 101 6.3.6. Decrypting encrypted media files . . . . . . . . . . . 17 102 7. Protocol version compatibility . . . . . . . . . . . . . . . . 17 103 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 104 8.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 17 105 8.2. Simple Playlist file . . . . . . . . . . . . . . . . . . . 17 106 8.3. Sliding Window Playlist, using HTTPS . . . . . . . . . . . 18 107 8.4. Playlist file with encrypted media files . . . . . . . . . 18 108 8.5. Variant Playlist file . . . . . . . . . . . . . . . . . . 18 109 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19 110 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 111 11. Security Considerations . . . . . . . . . . . . . . . . . . . 20 112 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 113 12.1. Normative References . . . . . . . . . . . . . . . . . . . 20 114 12.2. Informative References . . . . . . . . . . . . . . . . . . 22 115 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 117 1. Introduction 119 This document describes a protocol for transferring unbounded streams 120 of multimedia data. The protocol supports the encryption of media 121 data and the provision of alternate versions (e.g. bitrates) of a 122 stream. Media data can be transferred soon after it is created, 123 allowing it to be played in near real-time. Data is usually carried 124 over HTTP [RFC2616]. 126 External references that describe related standards such as HTTP are 127 listed in Section 11. 129 2. Summary 131 A multimedia presentation is specified by a URI [RFC3986] to a 132 Playlist file, which is an ordered list of media URIs and 133 informational tags. Each media URI refers to a media file which is a 134 segment of a single contiguous stream. 136 To play the stream, the client first obtains the Playlist file and 137 then obtains and plays each media file in the Playlist. It reloads 138 the Playlist file as described in this document to discover 139 additional segments. 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in RFC 2119 [RFC2119]. 145 3. The Playlist file 147 3.1. Introduction 149 Playlists MUST be Extended M3U Playlist files [M3U]. This document 150 extends the M3U file format by defining additional tags. 152 An M3U Playlist is a text file that consists of individual lines. 153 Lines are terminated by either a single LF character or a CR 154 character followed by an LF character. Each line is a URI, a blank, 155 or starts with the comment character '#'. Blank lines are ignored. 156 White space MUST NOT be present, except for elements in which it is 157 explicitly specified. 159 A URI line identifies a media file or a variant Playlist file (see 160 Section 3.2.7). 162 URIs MAY be relative. A relative URI MUST be resolved against the 163 URI of the Playlist file that contains it. 165 Lines that start with the comment character '#' are either comments 166 or tags. Tags begin with #EXT. All other lines that begin with '#' 167 are comments and SHOULD be ignored. 169 The duration of a Playlist file is the sum of the durations of the 170 media files within it. 172 M3U Playlist files whose names end in .m3u8 and/or have the HTTP 173 Content-Type "application/vnd.apple.mpegurl" are encoded in UTF-8 174 [RFC3629]. Files whose names end with .m3u and/or have the HTTP 175 Content-Type [RFC2616] "audio/mpegurl" are encoded in US-ASCII 176 [US_ASCII]. 178 Playlist files MUST have names that end in .m3u8 and/or have the 179 Content-Type "application/vnd.apple.mpegurl" (if transferred over 180 HTTP), or have names that end in .m3u and/or have the HTTP Content- 181 Type type "audio/mpegurl" (for compatibility). 183 The Extended M3U file format defines two tags: EXTM3U and EXTINF. An 184 Extended M3U file is distinguished from a basic M3U file by its first 185 line, which MUST be #EXTM3U. 187 EXTINF is a record marker that describes the media file identified by 188 the URI that follows it. Each media file URI MUST be preceded by an 189 EXTINF tag. Its format is: 191 #EXTINF:, 193 "duration" is an integer that specifies the duration of the media 194 file in seconds. Durations SHOULD be rounded to the nearest integer. 195 The remainder of the line following the comma is the title of the 196 media file, which is an optional human-readable informative title of 197 the media segment. 199 This document defines the following new tags: EXT-X-TARGETDURATION, 200 EXT-X-MEDIA-SEQUENCE, EXT-X-KEY, EXT-X-PROGRAM-DATE-TIME, EXT-X- 201 ALLOW-CACHE, EXT-X-STREAM-INF, EXT-X-ENDLIST, EXT-X-DISCONTINUITY, 202 and EXT-X-VERSION. 204 3.2. New Tags 205 3.2.1. EXT-X-TARGETDURATION 207 The EXT-X-TARGETDURATION tag specifies the maximum media file 208 duration. The EXTINF duration of each media file in the Playlist 209 file MUST be less than or equal to the target duration. This tag 210 MUST appear once in the Playlist file. Its format is: 212 #EXT-X-TARGETDURATION:<s> 214 where s is an integer indicating the target duration in seconds. 216 3.2.2. EXT-X-MEDIA-SEQUENCE 218 Each media file URI in a Playlist has a unique sequence number. The 219 sequence number of a URI is equal to the sequence number of the URI 220 that preceded it plus one. The EXT-X-MEDIA-SEQUENCE tag indicates 221 the sequence number of the first URI that appears in a Playlist file. 222 Its format is: 224 #EXT-X-MEDIA-SEQUENCE:<number> 226 A Playlist file MUST NOT contain more than one EXT-X-MEDIA-SEQUENCE 227 tag. If the Playlist file does not contain an EXT-X-MEDIA-SEQUENCE 228 tag then the sequence number of the first URI in the playlist SHALL 229 be considered to be 0. 231 A media file's sequence number is not required to appear in its URI. 233 See Section 6.3.2 and Section 6.3.5 for information on handling the 234 EXT-X-MEDIA-SEQUENCE tag. 236 3.2.3. EXT-X-KEY 238 Media files MAY be encrypted. The EXT-X-KEY tag provides information 239 necessary to decrypt media files that follow it. Its format is: 241 #EXT-X-KEY:METHOD=<method>[,URI="<URI>"][,IV=<IV>] 243 The METHOD attribute specifies the encryption method. Two encryption 244 methods are defined: NONE and AES-128. 246 An encryption method of NONE means that media files are not 247 encrypted. If the encryption method is NONE, the URI and the IV 248 attributes MUST NOT be present. 250 An encryption method of AES-128 means that media files are encrypted 251 using the Advanced Encryption Standard [AES_128] with a 128-bit key 252 and PKCS7 padding [RFC5652]. If the encryption method is AES-128, 253 the URI attribute MUST be present. The IV attribute MAY be present; 254 see Section 5.2. 256 The URI attribute, if present, specifies how to obtain the key. The 257 IV attribute, if present, specifies the Initialization Vector to be 258 used with the key. The IV attribute appeared in protocol version 2. 260 A new EXT-X-KEY supersedes any prior EXT-X-KEY. 262 If the Playlist file does not contain an EXT-X-KEY tag then media 263 files are not encrypted. 265 See Section 5 for the format of the key file, and Section 5.2, 266 Section 6.2.3 and Section 6.3.6 for additional information on media 267 file encryption. 269 3.2.4. EXT-X-PROGRAM-DATE-TIME 271 The EXT-X-PROGRAM-DATE-TIME tag associates the beginning of the next 272 media file with an absolute date and/or time. The date/time 273 representation is ISO/IEC 8601:2004 [ISO_8601] and SHOULD indicate a 274 time zone. For example: 276 #EXT-X-PROGRAM-DATE-TIME:<YYYY-MM-DDThh:mm:ssZ> 278 See Section 6.2.1 and Section 6.3.3 for more information on the EXT- 279 X-PROGRAM-DATE-TIME tag. 281 3.2.5. EXT-X-ALLOW-CACHE 283 The EXT-X-ALLOW-CACHE tag indicates whether the client MAY or MUST 284 NOT cache downloaded media files for later replay. It MAY occur 285 anywhere in the Playlist file; it MUST NOT occur more than once. The 286 EXT-X-ALLOW-CACHE tag applies to all segments in the playlist. Its 287 format is: 289 #EXT-X-ALLOW-CACHE:<YES|NO> 291 See Section 6.3.3 for more information on the EXT-X-ALLOW-CACHE tag. 293 3.2.6. EXT-X-ENDLIST 295 The EXT-X-ENDLIST tag indicates that no more media files will be 296 added to the Playlist file. It MAY occur anywhere in the Playlist 297 file; it MUST NOT occur more than once. Its format is: 299 #EXT-X-ENDLIST 301 3.2.7. EXT-X-STREAM-INF 303 The EXT-X-STREAM-INF tag indicates that the next URI in the Playlist 304 file identifies another Playlist file. Its format is: 306 #EXT-X-STREAM-INF:[attribute=value][,attribute=value]* 307 <URI> 309 An attribute MUST NOT occur more than once in the same EXT-X-STREAM- 310 INF tag. The following attributes are defined: 312 BANDWIDTH=<n> 314 where n is a number of bits per second. It MUST be an upper bound of 315 the overall bitrate of each media file, calculated to include 316 container overhead, that appears or will appear in the Playlist. 318 PROGRAM-ID=<i> 320 where i is a number that uniquely identifies a particular 321 presentation within the scope of the Playlist file. 323 A Playlist file MAY contain multiple EXT-X-STREAM-INF tags with the 324 same PROGRAM-ID to identify different encodings of the same 325 presentation. These variant playlists MAY contain additional EXT-X- 326 STREAM-INF tags. 328 CODECS="[format][,format]*" 330 where each format specifies a media sample type that is present in a 331 media file in the Playlist file. 333 Valid format identifiers are those in the ISO File Format Name Space 334 defined by RFC 4281 [RFC4281]. 336 RESOLUTION=<N>x<M> 338 where N is the approximate encoded horizontal resolution of video 339 within the stream, expressed as a number of pixels, and M is the 340 approximate encoded vertical resolution. 342 3.2.8. EXT-X-DISCONTINUITY 344 The EXT-X-DISCONTINUITY tag indicates an encoding discontinuity 345 between the media file that follows it and the one that preceded it. 346 The set of characteristics that MAY change is: 348 o file format 350 o number and type of tracks 352 o encoding parameters 354 o encoding sequence 356 o timestamp sequence 358 Its format is: 360 #EXT-X-DISCONTINUITY 362 See Section 4, Section 6.2.1, and Section 6.3.3 for more information 363 about the EXT-X-DISCONTINUITY tag. 365 3.2.9. EXT-X-VERSION 367 The EXT-X-VERSION tag indicates the compatibility version of the 368 Playlist file. The Playlist file, its associated media, and its 369 server MUST comply with all provisions of the most-recent version of 370 this document describing the protocol version indicated by the tag 371 value. 373 Its format is: 375 #EXT-X-VERSION:<n> 377 where n is an integer indicating the protocol version. 379 A Playlist file MUST NOT contain more than one EXT-X-VERSION tag. A 380 Playlist file that does not contain an EXT-X-VERSION tag MUST comply 381 with version 1 of this protocol. 383 4. Media files 385 Each media file URI in a Playlist file MUST identify a media file 386 which is a segment of the overall presentation. Each media file MUST 387 be formatted as an MPEG-2 Transport Stream or an MPEG-2 audio 388 elementary stream [ISO_13818]. 390 Transport Stream files MUST contain a single MPEG-2 Program. There 391 SHOULD be a Program Association Table and a Program Map Table at the 392 start of each file. A file that contains video SHOULD have at least 393 one key frame and enough information to completely initialize a video 394 decoder. 396 A media file in a Playlist MUST be the continuation of the encoded 397 stream at the end of the media file with the previous sequence number 398 unless it was the first media file to appear in the Playlist file or 399 if it is preceded by an EXT-X-DISCONTINUITY tag. 401 Clients SHOULD be prepared to handle multiple tracks of a particular 402 type (e.g. audio or video) by choosing a reasonable subset. Clients 403 MUST ignore private streams inside Transport Streams that they do not 404 recognize. 406 The encoding parameters for samples within a stream inside a media 407 file and between corresponding streams across multiple media files 408 SHOULD remain consistent. However clients SHOULD deal with encoding 409 changes as they are encountered, for example by scaling video content 410 to accommodate a resolution change. 412 5. Key files 414 5.1. Introduction 416 An EXT-X-KEY tag with the URI attribute identifies a Key file. A Key 417 file contains the cipher key that MUST be used to decrypt subsequent 418 media files in the Playlist. 420 The AES-128 encryption method uses 16-octet keys. The format of the 421 Key file is simply a packed array of these 16 octets in binary 422 format. 424 5.2. IV for AES-128 426 128-bit AES requires the same 16-octet Initialization Vector (IV) to 427 be supplied when encrypting and decrypting. Varying this IV 428 increases the strength of the cipher. 430 If the EXT-X-KEY tag has the IV attribute, implementations MUST use 431 the attribute value as the IV when encrypting or decrypting with that 432 key. The value MUST be interpreted as a 128-bit hexadecimal number 433 and MUST be prefixed with 0x or 0X. 435 If the EXT-X-KEY tag does not have the IV attribute, implementations 436 MUST use the sequence number of the media file as the IV when 437 encrypting or decrypting that media file. The big-endian binary 438 representation of the sequence number SHALL be placed in a 16-octet 439 buffer and padded (on the left) with zeros. 441 6. Client/Server Actions 443 6.1. Introduction 445 This section describes how the server generates the Playlist and 446 media files and how the client should download and play them. 448 6.2. Server Process 450 6.2.1. Introduction 452 The production of the MPEG-2 stream is outside the scope of this 453 document, which simply presumes a source of a continuous stream 454 containing the presentation. 456 The server MUST divide the stream into individual media files whose 457 duration is approximately equal. The server SHOULD attempt to divide 458 the stream at points that support effective decode of individual 459 media files, e.g. on packet and key frame boundaries. 461 The server MUST create a URI for each media file that will allow its 462 clients to obtain the file. 464 The server MUST create a Playlist file. The Playlist file MUST 465 conform to the format described in Section 3. A URI for each media 466 file that the server wishes to make available MUST appear in the 467 Playlist in the order in which it is to be played. The entire media 468 file MUST be available to clients if its URI is in the Playlist file. 470 The Playlist file MUST contain an EXT-X-TARGETDURATION tag. It MUST 471 indicate the maximum EXTINF value of any media file added to the 472 Playlist file. Its value MUST remain constant for the entire 473 presentation. A typical target duration is 10 seconds. 475 The Playlist file SHOULD contain one EXT-X-VERSION tag which 476 indicates the compatibility version of the stream. Its value SHOULD 477 be the lowest protocol version with which the server, Playlist file, 478 and associated media files all comply. 480 The server MUST create a URI for the Playlist file that will allow 481 its clients to obtain the file. 483 Changes to the Playlist file MUST be made atomically from the point 484 of view of the clients. 486 The server MUST NOT change the value of the EXT-X-ALLOW-CACHE tag. 488 Every media file URI in a Playlist MUST be prefixed with an EXTINF 489 tag indicating the rounded duration of the media file. 491 The server MAY associate an absolute date and time with a media file 492 by prefixing its URI with an EXT-X-PROGRAM-DATE-TIME tag. The value 493 of the date and time provides an informative mapping of the timeline 494 of the media to an appropriate wall-clock time, which may be used as 495 a basis for seeking, for display, or for other purposes. If a server 496 provides this mapping, it SHOULD place an EXT-X-PROGRAM-DATE-TIME tag 497 after every EXT-X-DISCONTINUITY tag in the Playlist file. 499 If the Playlist contains the final media file of the presentation 500 then the Playlist file MUST contain the EXT-X-ENDLIST tag. 502 If the Playlist does not contain the EXT-X-ENDLIST tag, the server 503 MUST make a new version of the Playlist file available that contains 504 at least one new media file URI. It MUST be made available relative 505 to the time that the previous version of the Playlist file was made 506 available: no earlier than one-half the target duration after that 507 time, and no later than 1.5 times the target duration after that 508 time. 510 If the server wishes to remove an entire presentation, it MUST make 511 the Playlist file unavailable to clients. It SHOULD ensure that all 512 media files in the Playlist file remain available to clients for at 513 least the duration of the Playlist file at the time of removal. 515 6.2.2. Sliding Window Playlists 517 The server MAY limit the availability of media files to those which 518 have been most recently added to the Playlist. To do so the Playlist 519 file MUST ALWAYS contain exactly one EXT-X-MEDIA-SEQUENCE tag. Its 520 value MUST be incremented by 1 for every media file URI that is 521 removed from the Playlist file. 523 Media file URIs MUST be removed from the Playlist file in the order 524 in which they were added. 526 When the server removes a media file URI from the Playlist, the media 527 file SHOULD remain available to clients for a period of time equal to 528 the duration of the media file plus the duration of the longest 529 Playlist file in which the media file has appeared. 531 If a server plans to remove a media file after it is delivered to 532 clients over HTTP, it SHOULD ensure that the HTTP response contains 533 an Expires header that reflects the planned time-to-live. 535 The duration of a Playlist file that does not contain the EXT-X- 536 ENDLIST tag MUST be at least three times the target duration. 538 6.2.3. Encrypting media files 540 If media files are to be encrypted the server MUST define a URI which 541 will allow authorized clients to obtain a Key file containing a 542 decryption key. The Key file MUST conform to the format described in 543 Section 5. 545 The server MAY set the HTTP Expires header in the key response to 546 indicate that the key may be cached. 548 If the encryption METHOD is AES-128, AES-128 CBC encryption SHALL be 549 applied to individual media files. The entire file MUST be 550 encrypted. Cipher Block Chaining MUST NOT be applied across media 551 files. The IV used for encryption MUST be either the sequence number 552 of the media file or the value of the IV attribute of the EXT-X-KEY 553 tag, as described in Section 5.2. 555 The server MUST encrypt every media file in a Playlist using the 556 method and other attributes specified by the EXT-X-KEY tag that most 557 immediately precedes its URI in the Playlist file. Media files 558 preceded by an EXT-X-KEY tag whose METHOD is NONE, or not preceded by 559 any EXT-X-KEY tag, MUST NOT be encrypted. 561 The URI of every EXT-X-KEY tag must be distinct from the URI of every 562 other EXT-X-KEY tag that appears or has appeared in the Playlist 563 file, unless its METHOD is NONE. An EXT-X-KEY tag with a METHOD of 564 NONE MUST NOT contain a URI attribute. 566 The server MUST NOT remove an EXT-X-KEY tag from the Playlist file if 567 the Playlist file contains a URI to a media file encrypted with that 568 key. 570 6.2.4. Providing variant streams 572 A server MAY offer multiple Playlist files to provide different 573 encodings of the same presentation. If it does so it SHOULD provide 574 a variant Playlist file that lists each variant stream to allow 575 clients to switch between encodings dynamically. 577 Variant Playlists MUST contain an EXT-X-STREAM-INF tag for each 578 variant stream. Each EXT-X-STREAM-INF tag for the same presentation 579 MUST have the same PROGRAM-ID attribute value. The PROGRAM-ID value 580 for each presentation MUST be unique within the variant Playlist. 582 If an EXT-X-STREAM-INF tag contains the CODECS attribute, the 583 attribute value MUST include every format defined by [RFC4281] that 584 is present in any media file that appears or will appear in the 585 Playlist file. 587 The server MUST meet the following constraints when producing variant 588 streams: 590 Each variant stream MUST present the same content, including 591 stream discontinuities. 593 Each variant Playlist file MUST have the same target duration. 595 Content that appears in one variant Playlist file but not in 596 another MUST appear either at the beginning or at the end of the 597 Playlist file and MUST NOT be longer than the target duration. 599 Matching content in variant streams MUST have matching timestamps. 600 This allows clients to synchronize the streams. 602 Elementary Audio Stream files MUST signal the timestamp of the 603 first sample in the file by prepending an ID3 PRIV tag [ID3] with 604 an owner identifier of 605 "com.apple.streaming.transportStreamTimestamp". The binary data 606 MUST be a 33-bit MPEG-2 Program Elementary Stream timestamp 607 expressed as a big-endian eight-octet number. 609 In addition, all variant streams SHOULD contain the same encoded 610 audio bitstream. This allows clients to switch between streams 611 without audible glitching. 613 6.3. Client Process 615 6.3.1. Introduction 617 How the client obtains the URI to the Playlist file is outside the 618 scope of this document; it is presumed to have done so. 620 The client MUST obtain the Playlist file from the URI. If the 621 Playlist file so obtained is a variant Playlist, the client MUST 622 obtain the Playlist file from the variant Playlist. 624 This document does not specify the treatment of variant streams by 625 clients. 627 6.3.2. Loading the Playlist file 629 Every time a Playlist file is loaded or reloaded from the Playlist 630 URI: 632 The client MUST ensure that the Playlist file begins with the 633 EXTM3U tag and that the EXT-X-VERSION tag, if present, specifies a 634 protocol version supported by the client; if not, the client MUST 635 NOT attempt to use the Playlist. 637 The client SHOULD ignore any tags and attributes it does not 638 recognize. 640 The client MUST determine the next media file to load as described 641 in Section 6.3.5. 643 If the Playlist contains the EXT-X-MEDIA-SEQUENCE tag, the client 644 SHOULD assume that each media file in it will become unavailable at 645 the time that the Playlist file was loaded plus the duration of the 646 Playlist file. The duration of a Playlist file is the sum of the 647 durations of the media files within it. 649 6.3.3. Playing the Playlist file 651 The client SHALL choose which media file to play first from the 652 Playlist when playback starts. If the EXT-X-ENDLIST tag is not 653 present and the client intends to play the media regularly (i.e. in 654 playlist order at the nominal playback rate), the client SHOULD NOT 655 choose a file which starts less than three target durations from the 656 end of the Playlist file. Doing so can trigger playback stalls. 658 To achieve regular playback, media files MUST be played in the order 659 that they appear in the Playlist file. The client MAY present the 660 available media in any way it wishes, including regular playback, 661 random access, and trick modes. 663 The client MUST be prepared to reset its parser(s) and decoder(s) 664 before playing a media file that is preceded by an EXT-X- 665 DISCONTINUITY tag. 667 The client SHOULD attempt to load media files in advance of when they 668 will be required for uninterrupted playback to compensate for 669 temporary variations in latency and throughput. 671 If the Playlist file contains the EXT-X-ALLOW-CACHE tag and its value 672 is NO, the client MUST NOT cache downloaded media files after they 673 have been played. Otherwise the client MAY cache downloaded media 674 files indefinitely for later replay. 676 The client MAY use the value of the EXT-X-PROGRAM-DATE-TIME tag to 677 display the program origination time to the user. If the value 678 includes time zone information the client SHALL take it into account, 679 but if it does not the client MUST NOT infer an originating time 680 zone. 682 The client MUST NOT depend upon the correctness or the consistency of 683 the value of the EXT-X-PROGRAM-DATE-TIME tag. 685 6.3.4. Reloading the Playlist file 687 The client MUST periodically reload the Playlist file unless it 688 contains the EXT-X-ENDLIST tag. 690 However the client MUST NOT attempt to reload the Playlist file more 691 frequently than specified by this section. 693 When a client loads a Playlist file for the first time or reloads a 694 Playlist file and finds that it has changed since the last time it 695 was loaded, the client MUST wait for a period of time before 696 attempting to reload the Playlist file again. This period is called 697 the initial minimum reload delay. It is measured from the time that 698 the client began loading the Playlist file. 700 The initial minimum reload delay is the duration of the last media 701 file in the Playlist. Media file duration is specified by the EXTINF 702 tag. 704 If the client reloads a Playlist file and finds that it has not 705 changed then it MUST wait for a period of time before retrying. The 706 minimum delay is a multiple of the target duration. This multiple is 707 0.5 for the first attempt, 1.5 for the second, and 3.0 thereafter. 709 6.3.5. Determining the next file to load 711 The client MUST examine the Playlist file every time it is loaded or 712 reloaded to determine the next media file to load. 714 The first file to load MUST be the file that the client has chosen to 715 play first, as described in Section 6.3.3. 717 If the first file to be played has been loaded and the Playlist file 718 does not contain the EXT-X-MEDIA-SEQUENCE tag then the client MUST 719 verify that the current Playlist file contains the URI of the last 720 loaded media file at the offset it was originally found at, halting 721 playback if it does not. The next media file to load MUST be the 722 first media file URI following the last-loaded URI in the Playlist. 724 If the first file to be played has been loaded and the Playlist file 725 contains the EXT-X-MEDIA-SEQUENCE tag then the next media file to 726 load SHALL be the one with the lowest sequence number that is greater 727 than the sequence number of the last media file loaded. 729 6.3.6. Decrypting encrypted media files 731 If a Playlist file contains an EXT-X-KEY tag that specifies a Key 732 file URI, the client MUST obtain that key file and use the key inside 733 it to decrypt all media files following the EXT-X-KEY tag until 734 another EXT-X-KEY tag is encountered. 736 If the encryption METHOD is AES-128, AES-128 CBC decryption SHALL be 737 applied to individual media files. The entire file MUST be 738 decrypted. Cipher Block Chaining MUST NOT be applied across media 739 files. The IV used for decryption MUST be either the sequence number 740 of the media file or the value of the IV attribute of the EXT-X-KEY 741 tag, as described in Section 5.2. 743 If the encryption METHOD is NONE, the client MUST treat all media 744 files following the EXT-X-KEY tag as cleartext (not encrypted) until 745 another EXT-X-KEY tag is encountered. 747 7. Protocol version compatibility 749 Clients and servers MUST implement protocol version 2 or higher to 750 use: 752 o The IV attribute of the EXT-X-KEY tag. 754 8. Examples 756 8.1. Introduction 758 This section contains several example Playlist files. 760 8.2. Simple Playlist file 762 #EXTM3U 763 #EXT-X-TARGETDURATION:5220 764 #EXTINF:5220, 765 http://media.example.com/entire.ts 766 #EXT-X-ENDLIST 768 8.3. Sliding Window Playlist, using HTTPS 770 #EXTM3U 771 #EXT-X-TARGETDURATION:8 772 #EXT-X-MEDIA-SEQUENCE:2680 774 #EXTINF:8, 775 https://priv.example.com/fileSequence2680.ts 776 #EXTINF:8, 777 https://priv.example.com/fileSequence2681.ts 778 #EXTINF:8, 779 https://priv.example.com/fileSequence2682.ts 781 8.4. Playlist file with encrypted media files 783 #EXTM3U 784 #EXT-X-MEDIA-SEQUENCE:7794 785 #EXT-X-TARGETDURATION:15 787 #EXT-X-KEY:METHOD=AES-128,URI="https://priv.example.com/key.php?r=52" 789 #EXTINF:15, 790 http://media.example.com/fileSequence52-1.ts 791 #EXTINF:15, 792 http://media.example.com/fileSequence52-2.ts 793 #EXTINF:15, 794 http://media.example.com/fileSequence52-3.ts 796 #EXT-X-KEY:METHOD=AES-128,URI="https://priv.example.com/key.php?r=53" 798 #EXTINF:15, 799 http://media.example.com/fileSequence53-1.ts 801 8.5. Variant Playlist file 803 #EXTM3U 804 #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1280000 805 http://example.com/low.m3u8 806 #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=2560000 807 http://example.com/mid.m3u8 808 #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=7680000 809 http://example.com/hi.m3u8 810 #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=65000,CODECS="mp4a.40.5" 811 http://example.com/audio-only.m3u8 813 9. Contributors 815 Significant contributions to the design of this protocol were made by 816 Jim Batson, David Biderman, Bill May, Roger Pantos, and Alan Tseng. 818 10. IANA Considerations 820 This memo requests that the following MIME type [RFC2046] be 821 registered with the IANA: 823 Type name: "application" 825 Subtype name: "vnd.apple.mpegurl" 827 Required parameters: (none) 829 Optional parameters: (none) 831 Encoding considerations: encoded as text. See Section 3 for more 832 information. 834 Security considerations: See Section 11. 836 Compression: this media type does not employ compression. 838 Interoperability considerations: There are no byte-ordering issues, 839 since files are 7- or 8-bit text. Applications could encounter 840 unrecognized tags, which SHOULD be ignored. 842 Published specification: see Section 3. 844 Applications that use this media type: Multimedia applications such 845 as the iPhone media player (OS 3.0) and QuickTime Player in Mac OS X 846 Snow Leopard. 848 Additional information: files begin with the magic number #EXTM3U. 849 Filenames normally end with .m3u8 or .m3u (see Section 3). No 850 Macintosh file type codes have been registered. 852 Person & email address to contact for further information: David 853 Singer, singer AT apple.com. 855 Intended usage: LIMITED USE 857 Restrictions on usage: (none) 859 Author: Roger Pantos 860 Change Controller: David Singer 862 11. Security Considerations 864 Since the protocol generally uses HTTP to transfer data, most of the 865 same security considerations apply. See section 15 of RFC 2616 866 [RFC2616]. 868 Media file parsers are typically subject to "fuzzing" attacks. 869 Clients SHOULD take care when parsing files received from a server so 870 that non-compliant files are rejected. 872 Playlist files contain URIs, which clients will use to make network 873 requests of arbitrary entities. Clients SHOULD range-check responses 874 to prevent buffer overflows. See also the Security Considerations 875 section of RFC 3986 [RFC3986]. 877 Clients SHOULD load resources identified by URI lazily to avoid 878 contributing to denial-of-service attacks. 880 HTTP requests often include session state ("cookies"), which may 881 contain private user data. Implementations MUST follow cookie 882 restriction and expiry rules specified by RFC 2965 [RFC2965]. See 883 also the Security Considerations section of RFC 2965, and RFC 2964 884 [RFC2964]. 886 Encryption keys are specified by URI. The delivery of these keys 887 SHOULD be secured by a mechanism such as HTTP over TLS [RFC5246] 888 (formerly SSL) in conjunction with a secure realm or a session 889 cookie. 891 12. References 893 12.1. Normative References 895 [AES_128] U.S. Department of Commerce/National Institute of 896 Standards and Technology, "Advanced Encryption Standard 897 (AES), FIPS PUB 197", November 2001, <http:// 898 csrc.nist.gov/publications/fips/fips197/fips-197.pdf>. 900 [ISO_13818] 901 International Organization for Standardization, "ISO/IEC 902 International Standard 13818; Generic coding of moving 903 pictures and associated audio information", October 2007, 904 <http://www.iso.org/iso/catalogue_detail?csnumber=44169>. 906 [ISO_8601] 907 International Organization for Standardization, "ISO/IEC 908 International Standard 8601:2004; Data elements and 909 interchange formats -- Information interchange -- 910 Representation of dates and times", December 2004, 911 <http://www.iso.org/iso/catalogue_detail?csnumber=40874>. 913 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 914 Extensions (MIME) Part Two: Media Types", RFC 2046, 915 November 1996. 917 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 918 Requirement Levels", BCP 14, RFC 2119, March 1997. 920 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 921 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 922 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 924 [RFC2964] Moore, K. and N. Freed, "Use of HTTP State Management", 925 BCP 44, RFC 2964, October 2000. 927 [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management 928 Mechanism", RFC 2965, October 2000. 930 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 931 10646", STD 63, RFC 3629, November 2003. 933 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 934 Resource Identifier (URI): Generic Syntax", STD 66, 935 RFC 3986, January 2005. 937 [RFC4281] Gellens, R., Singer, D., and P. Frojdh, "The Codecs 938 Parameter for "Bucket" Media Types", RFC 4281, 939 November 2005. 941 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 942 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 944 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", 945 RFC 5652, September 2009. 947 [US_ASCII] 948 American National Standards Institute, "ANSI X3.4-1986, 949 Information Systems -- Coded Character Sets 7-Bit American 950 National Standard Code for Information Interchange (7-Bit 951 ASCII)", December 1986. 953 12.2. Informative References 955 [ID3] ID3.org, "The ID3 audio file data tagging format", 956 <http://www.id3.org/Developer_Information>. 958 [M3U] Nullsoft, Inc., "The M3U Playlist format, originally 959 invented for the Winamp media player", 960 <http://wikipedia.org/wiki/M3U>. 962 Author's Address 964 Roger Pantos (editor) 965 Apple Inc. 966 Cupertino, California 967 United States 969 Email: http-live-streaming-review@group.apple.com