idnits 2.17.1 draft-pantos-http-live-streaming-04.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 (June 5, 2010) is 5073 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 W. May 4 Intended status: Informational Apple Inc. 5 Expires: December 7, 2010 June 5, 2010 7 HTTP Live Streaming 8 draft-pantos-http-live-streaming-04 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). 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 December 7, 2010. 36 Copyright Notice 38 Copyright (c) 2010 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 Pursuant to Section 8.f. of the Legal Provisions (see the IETF 49 Trust's Legal Provisions Relating to IETF Documents effective 50 December 28, 2009), Section 4 of the Legal Provisions does not apply 51 to this document. Thus, to the extent that this Informational 52 Internet Draft contains one or more Code Components, no license to 53 such Code Components is granted. Furthermore, this document may not 54 be modified, and derivative works of it may not be created, and it 55 may not be published except as an Internet-Draft. 57 Furthermore, this Informational Internet Draft is submitted as an RFC 58 Editor Contribution and/or non-IETF Document (not as a Contribution, 59 IETF Contribution, nor IETF Document) in accordance with BCP 78 and 60 BCP 79. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. The Playlist file . . . . . . . . . . . . . . . . . . . . . . 4 67 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 68 3.2. New Tags . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3.2.1. EXT-X-TARGETDURATION . . . . . . . . . . . . . . . . . 6 70 3.2.2. EXT-X-MEDIA-SEQUENCE . . . . . . . . . . . . . . . . . 6 71 3.2.3. EXT-X-KEY . . . . . . . . . . . . . . . . . . . . . . 6 72 3.2.4. EXT-X-PROGRAM-DATE-TIME . . . . . . . . . . . . . . . 7 73 3.2.5. EXT-X-ALLOW-CACHE . . . . . . . . . . . . . . . . . . 7 74 3.2.6. EXT-X-ENDLIST . . . . . . . . . . . . . . . . . . . . 7 75 3.2.7. EXT-X-STREAM-INF . . . . . . . . . . . . . . . . . . . 8 76 3.2.8. EXT-X-DISCONTINUITY . . . . . . . . . . . . . . . . . 8 77 3.2.9. EXT-X-VERSION . . . . . . . . . . . . . . . . . . . . 9 78 4. Media files . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 5. Key files . . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 10 81 5.2. IV for AES-128 . . . . . . . . . . . . . . . . . . . . . . 10 82 6. Client/Server Actions . . . . . . . . . . . . . . . . . . . . 11 83 6.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 11 84 6.2. Server Process . . . . . . . . . . . . . . . . . . . . . . 11 85 6.2.1. Introduction . . . . . . . . . . . . . . . . . . . . . 11 86 6.2.2. Sliding Window Playlists . . . . . . . . . . . . . . . 12 87 6.2.3. Encrypting media files . . . . . . . . . . . . . . . . 13 88 6.2.4. Providing variant streams . . . . . . . . . . . . . . 13 89 6.3. Client Process . . . . . . . . . . . . . . . . . . . . . . 14 90 6.3.1. Introduction . . . . . . . . . . . . . . . . . . . . . 14 91 6.3.2. Loading the Playlist file . . . . . . . . . . . . . . 14 92 6.3.3. Playing the Playlist file . . . . . . . . . . . . . . 15 93 6.3.4. Reloading the Playlist file . . . . . . . . . . . . . 16 94 6.3.5. Determining the next file to load . . . . . . . . . . 16 95 6.3.6. Decrypting encrypted media files . . . . . . . . . . . 16 96 7. Protocol version compatibility . . . . . . . . . . . . . . . . 17 97 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 98 8.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 17 99 8.2. Simple Playlist file . . . . . . . . . . . . . . . . . . . 17 100 8.3. Sliding Window Playlist, using HTTPS . . . . . . . . . . . 18 101 8.4. Playlist file with encrypted media files . . . . . . . . . 18 102 8.5. Variant Playlist file . . . . . . . . . . . . . . . . . . 18 103 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19 104 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 105 11. Security Considerations . . . . . . . . . . . . . . . . . . . 20 106 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 107 12.1. Normative References . . . . . . . . . . . . . . . . . . . 20 108 12.2. Informative References . . . . . . . . . . . . . . . . . . 22 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 111 1. Introduction 113 This document describes a protocol for transferring unbounded streams 114 of multimedia data. The protocol supports the encryption of media 115 data and the provision of alternate versions (e.g. bitrates) of a 116 stream. Media data can be transferred soon after it is created, 117 allowing it to be played in near real-time. Data is usually carried 118 over HTTP [RFC2616]. 120 External references that describe related standards such as HTTP are 121 listed in Section 11. 123 2. Summary 125 A multimedia presentation is specified by a URI [RFC3986] to a 126 Playlist file, which is an ordered list of media URIs and 127 informational tags. Each media URI refers to a media file which is a 128 segment of a single contiguous stream. 130 To play the stream, the client first obtains the Playlist file and 131 then obtains and plays each media file in the Playlist. It reloads 132 the Playlist file as described in this document to discover 133 additional segments. 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in RFC 2119 [RFC2119]. 139 3. The Playlist file 141 3.1. Introduction 143 Playlists MUST be Extended M3U Playlist files [M3U]. This document 144 extends the M3U file format by defining additional tags. 146 An M3U Playlist is a text file that consists of individual lines. 147 Lines are terminated by either a single LF character or a CR 148 character followed by an LF character. Each line is a URI, a blank, 149 or starts with the comment character '#'. Blank lines are ignored. 150 White space MUST NOT be present, except for elements in which it is 151 explicitly specified. 153 A URI line identifies a media file or a variant Playlist file (see 154 Section 3.2.7). 156 URIs MAY be relative. A relative URI MUST be resolved against the 157 URI of the Playlist file that contains it. 159 Lines that start with the comment character '#' are either comments 160 or tags. Tags begin with #EXT. All other lines that begin with '#' 161 are comments and SHOULD be ignored. 163 The duration of a Playlist file is the sum of the durations of the 164 media files within it. 166 M3U Playlist files whose names end in .m3u8 and/or have the HTTP 167 Content-Type "application/vnd.apple.mpegurl" are encoded in UTF-8 168 [RFC3629]. Files whose names end with .m3u and/or have the HTTP 169 Content-Type [RFC2616] "audio/mpegurl" are encoded in US-ASCII 170 [US_ASCII]. 172 Playlist files MUST have names that end in .m3u8 and/or have the 173 Content-Type "application/vnd.apple.mpegurl" (if transferred over 174 HTTP), or have names that end in .m3u and/or have the HTTP Content- 175 Type type "audio/mpegurl" (for compatibility). 177 The Extended M3U file format defines two tags: EXTM3U and EXTINF. An 178 Extended M3U file is distinguished from a basic M3U file by its first 179 line, which MUST be #EXTM3U. 181 EXTINF is a record marker that describes the media file identified by 182 the URI that follows it. Each media file URI MUST be preceded by an 183 EXTINF tag. Its format is: 185 #EXTINF:, 187 "duration" is an integer that specifies the duration of the media 188 file in seconds. Durations SHOULD be rounded to the nearest integer. 189 The remainder of the line following the comma is the title of the 190 media file, which is an optional human-readable informative title of 191 the media segment. 193 This document defines the following new tags: EXT-X-TARGETDURATION, 194 EXT-X-MEDIA-SEQUENCE, EXT-X-KEY, EXT-X-PROGRAM-DATE-TIME, EXT-X- 195 ALLOW-CACHE, EXT-X-STREAM-INF, EXT-X-ENDLIST, EXT-X-DISCONTINUITY, 196 and EXT-X-VERSION. 198 3.2. New Tags 199 3.2.1. EXT-X-TARGETDURATION 201 The EXT-X-TARGETDURATION tag specifies the maximum media file 202 duration. The EXTINF duration of each media file in the Playlist 203 file MUST be less than or equal to the target duration. This tag 204 MUST appear once in the Playlist file. Its format is: 206 #EXT-X-TARGETDURATION:<s> 208 where s is an integer indicating the target duration in seconds. 210 3.2.2. EXT-X-MEDIA-SEQUENCE 212 Each media file URI in a Playlist has a unique sequence number. The 213 sequence number of a URI is equal to the sequence number of the URI 214 that preceded it plus one. The EXT-X-MEDIA-SEQUENCE tag indicates 215 the sequence number of the first URI that appears in a Playlist file. 216 Its format is: 218 #EXT-X-MEDIA-SEQUENCE:<number> 220 A Playlist file MUST NOT contain more than one EXT-X-MEDIA-SEQUENCE 221 tag. If the Playlist file does not contain an EXT-X-MEDIA-SEQUENCE 222 tag then the sequence number of the first URI in the playlist SHALL 223 be considered to be 0. 225 A media file's sequence number is not required to appear in its URI. 227 See Section 6.3.2 and Section 6.3.5 for information on handling the 228 EXT-X-MEDIA-SEQUENCE tag. 230 3.2.3. EXT-X-KEY 232 Media files MAY be encrypted. The EXT-X-KEY tag provides information 233 necessary to decrypt media files that follow it. Its format is: 235 #EXT-X-KEY:METHOD=<method>[,URI="<URI>"][,IV=<IV>] 237 The METHOD attribute specifies the encryption method. Two encryption 238 methods are defined: NONE and AES-128. 240 An encryption method of NONE means that media files are not 241 encrypted. If the encryption method is NONE, the URI and the IV 242 attributes MUST NOT be present. 244 An encryption method of AES-128 means that media files are encrypted 245 using the Advanced Encryption Standard [AES_128] with a 128-bit key 246 and PKCS7 padding [RFC5652]. If the encryption method is AES-128, 247 the URI attribute MUST be present. The IV attribute MAY be present; 248 see Section 5.2. 250 The URI attribute, if present, specifies how to obtain the key. The 251 IV attribute, if present, specifies the Initialization Vector to be 252 used with the key. The IV attribute appeared in protocol version 2. 254 A new EXT-X-KEY supersedes any prior EXT-X-KEY. 256 If the Playlist file does not contain an EXT-X-KEY tag then media 257 files are not encrypted. 259 See Section 5 for the format of the key file, and Section 5.2, 260 Section 6.2.3 and Section 6.3.6 for additional information on media 261 file encryption. 263 3.2.4. EXT-X-PROGRAM-DATE-TIME 265 The EXT-X-PROGRAM-DATE-TIME tag associates the beginning of the next 266 media file with an absolute date and/or time. The date/time 267 representation is ISO/IEC 8601:2004 [ISO_8601] and SHOULD indicate a 268 time zone. For example: 270 #EXT-X-PROGRAM-DATE-TIME:<YYYY-MM-DDThh:mm:ssZ> 272 See Section 6.2.1 and Section 6.3.3 for more information on the EXT- 273 X-PROGRAM-DATE-TIME tag. 275 3.2.5. EXT-X-ALLOW-CACHE 277 The EXT-X-ALLOW-CACHE tag indicates whether the client MAY or MUST 278 NOT cache downloaded media files for later replay. It MAY occur 279 anywhere in the Playlist file; it MUST NOT occur more than once. The 280 EXT-X-ALLOW-CACHE tag applies to all segments in the playlist. Its 281 format is: 283 #EXT-X-ALLOW-CACHE:<YES|NO> 285 See Section 6.3.3 for more information on the EXT-X-ALLOW-CACHE tag. 287 3.2.6. EXT-X-ENDLIST 289 The EXT-X-ENDLIST tag indicates that no more media files will be 290 added to the Playlist file. It MAY occur anywhere in the Playlist 291 file; it MUST NOT occur more than once. Its format is: 293 #EXT-X-ENDLIST 295 3.2.7. EXT-X-STREAM-INF 297 The EXT-X-STREAM-INF tag indicates that the next URI in the Playlist 298 file identifies another Playlist file. Its format is: 300 #EXT-X-STREAM-INF:[attribute=value][,attribute=value]* 301 <URI> 303 An attribute MUST NOT occur more than once in the same EXT-X-STREAM- 304 INF tag. The following attributes are defined: 306 BANDWIDTH=<n> 308 where n is a number of bits per second. It MUST be an upper bound of 309 the overall bitrate of each media file, calculated to include 310 container overhead, that appears or will appear in the Playlist. 312 PROGRAM-ID=<i> 314 where i is a number that uniquely identifies a particular 315 presentation within the scope of the Playlist file. 317 A Playlist file MAY contain multiple EXT-X-STREAM-INF tags with the 318 same PROGRAM-ID to identify different encodings of the same 319 presentation. These variant playlists MAY contain additional EXT-X- 320 STREAM-INF tags. 322 CODECS="[format][,format]*" 324 where each format specifies a media sample type that is present in a 325 media file in the Playlist file. 327 Valid format identifiers are those in the ISO File Format Name Space 328 defined by RFC 4281 [RFC4281]. 330 RESOLUTION=<N>x<M> 332 where N is the approximate encoded horizontal resolution of video 333 within the stream, expressed as a number of pixels, and M is the 334 approximate encoded vertical resolution. 336 3.2.8. EXT-X-DISCONTINUITY 338 The EXT-X-DISCONTINUITY tag indicates an encoding discontinuity 339 between the media file that follows it and the one that preceded it. 340 The set of characteristics that MAY change is: 342 o file format 344 o number and type of tracks 346 o encoding parameters 348 o encoding sequence 350 o timestamp sequence 352 Its format is: 354 #EXT-X-DISCONTINUITY 356 See Section 4, Section 6.2.1, and Section 6.3.3 for more information 357 about the EXT-X-DISCONTINUITY tag. 359 3.2.9. EXT-X-VERSION 361 The EXT-X-VERSION tag indicates the compatibility version of the 362 Playlist file. The Playlist file, its associated media, and its 363 server MUST comply with all provisions of the most-recent version of 364 this document describing the protocol version indicated by the tag 365 value. 367 Its format is: 369 #EXT-X-VERSION:<n> 371 where n is an integer indicating the protocol version. 373 A Playlist file MUST NOT contain more than one EXT-X-VERSION tag. A 374 Playlist file that does not contain an EXT-X-VERSION tag MUST comply 375 with version 1 of this protocol. 377 4. Media files 379 Each media file URI in a Playlist file MUST identify a media file 380 which is a segment of the overall presentation. Each media file MUST 381 be formatted as an MPEG-2 Transport Stream or an MPEG-2 audio 382 elementary stream [ISO_13818]. 384 Transport Stream files MUST contain a single MPEG-2 Program. There 385 SHOULD be a Program Association Table and a Program Map Table at the 386 start of each file. A file that contains video SHOULD have at least 387 one key frame and enough information to completely initialize a video 388 decoder. 390 A media file in a Playlist MUST be the continuation of the encoded 391 stream at the end of the media file with the previous sequence number 392 unless it was the first media file to appear in the Playlist file or 393 if it is preceded by an EXT-X-DISCONTINUITY tag. 395 Clients SHOULD be prepared to handle multiple tracks of a particular 396 type (e.g. audio or video). A client with no other preference SHOULD 397 choose the one with the lowest numerical PID that it can play. 399 Clients MUST ignore private streams inside Transport Streams that 400 they do not recognize. 402 The encoding parameters for samples within a stream inside a media 403 file and between corresponding streams across multiple media files 404 SHOULD remain consistent. However clients SHOULD deal with encoding 405 changes as they are encountered, for example by scaling video content 406 to accommodate a resolution change. 408 5. Key files 410 5.1. Introduction 412 An EXT-X-KEY tag with the URI attribute identifies a Key file. A Key 413 file contains the cipher key that MUST be used to decrypt subsequent 414 media files in the Playlist. 416 The AES-128 encryption method uses 16-octet keys. The format of the 417 Key file is simply a packed array of these 16 octets in binary 418 format. 420 5.2. IV for AES-128 422 128-bit AES requires the same 16-octet Initialization Vector (IV) to 423 be supplied when encrypting and decrypting. Varying this IV 424 increases the strength of the cipher. 426 If the EXT-X-KEY tag has the IV attribute, implementations MUST use 427 the attribute value as the IV when encrypting or decrypting with that 428 key. The value MUST be interpreted as a 128-bit hexadecimal number 429 and MUST be prefixed with 0x or 0X. 431 If the EXT-X-KEY tag does not have the IV attribute, implementations 432 MUST use the sequence number of the media file as the IV when 433 encrypting or decrypting that media file. The big-endian binary 434 representation of the sequence number SHALL be placed in a 16-octet 435 buffer and padded (on the left) with zeros. 437 6. Client/Server Actions 439 6.1. Introduction 441 This section describes how the server generates the Playlist and 442 media files and how the client should download and play them. 444 6.2. Server Process 446 6.2.1. Introduction 448 The production of the MPEG-2 stream is outside the scope of this 449 document, which simply presumes a source of a continuous stream 450 containing the presentation. 452 The server MUST divide the stream into individual media files whose 453 duration is approximately equal. The server SHOULD attempt to divide 454 the stream at points that support effective decode of individual 455 media files, e.g. on packet and key frame boundaries. 457 The server MUST create a URI for each media file that will allow its 458 clients to obtain the file. 460 The server MUST create a Playlist file. The Playlist file MUST 461 conform to the format described in Section 3. A URI for each media 462 file that the server wishes to make available MUST appear in the 463 Playlist in the order in which it is to be played. The entire media 464 file MUST be available to clients if its URI is in the Playlist file. 466 The Playlist file MUST contain an EXT-X-TARGETDURATION tag. It MUST 467 indicate the maximum EXTINF value of any media file added to the 468 Playlist file. Its value MUST remain constant for the entire 469 presentation. A typical target duration is 10 seconds. 471 The Playlist file SHOULD contain one EXT-X-VERSION tag which 472 indicates the compatibility version of the stream. Its value SHOULD 473 be the lowest protocol version with which the server, Playlist file, 474 and associated media files all comply. 476 The server MUST create a URI for the Playlist file that will allow 477 its clients to obtain the file. 479 If the Playlist file is distributed by HTTP, the server SHOULD 480 support client requests to use the "gzip" Content-Encoding. 482 Changes to the Playlist file MUST be made atomically from the point 483 of view of the clients. 485 The server MUST NOT change the value of the EXT-X-ALLOW-CACHE tag. 487 Every media file URI in a Playlist MUST be prefixed with an EXTINF 488 tag indicating the rounded duration of the media file. 490 The server MAY associate an absolute date and time with a media file 491 by prefixing its URI with an EXT-X-PROGRAM-DATE-TIME tag. The value 492 of the date and time provides an informative mapping of the timeline 493 of the media to an appropriate wall-clock time, which may be used as 494 a basis for seeking, for display, or for other purposes. If a server 495 provides this mapping, it SHOULD place an EXT-X-PROGRAM-DATE-TIME tag 496 after every EXT-X-DISCONTINUITY tag in the Playlist file. 498 If the Playlist contains the final media file of the presentation 499 then the Playlist file MUST contain the EXT-X-ENDLIST tag. 501 If the Playlist does not contain the EXT-X-ENDLIST tag, the server 502 MUST make a new version of the Playlist file available that contains 503 at least one new media file URI. It MUST be made available relative 504 to the time that the previous version of the Playlist file was made 505 available: no earlier than one-half the target duration after that 506 time, and no later than 1.5 times the target duration after that 507 time. 509 If the server wishes to remove an entire presentation, it MUST make 510 the Playlist file unavailable to clients. It SHOULD ensure that all 511 media files in the Playlist file remain available to clients for at 512 least the duration of the Playlist file at the time of removal. 514 6.2.2. Sliding Window Playlists 516 The server MAY limit the availability of media files to those which 517 have been most recently added to the Playlist. To do so the Playlist 518 file MUST ALWAYS contain exactly one EXT-X-MEDIA-SEQUENCE tag. Its 519 value MUST be incremented by 1 for every media file URI that is 520 removed from the Playlist file. 522 Media file URIs MUST be removed from the Playlist file in the order 523 in which they were added. 525 When the server removes a media file URI from the Playlist, the media 526 file SHOULD remain available to clients for a period of time equal to 527 the duration of the media file plus the duration of the longest 528 Playlist file in which the media file has appeared. 530 If a server plans to remove a media file after it is delivered to 531 clients over HTTP, it SHOULD ensure that the HTTP response contains 532 an Expires header that reflects the planned time-to-live. 534 The duration of a Playlist file that does not contain the EXT-X- 535 ENDLIST tag MUST be at least three times the target duration. 537 6.2.3. Encrypting media files 539 If media files are to be encrypted the server MUST define a URI which 540 will allow authorized clients to obtain a Key file containing a 541 decryption key. The Key file MUST conform to the format described in 542 Section 5. 544 The server MAY set the HTTP Expires header in the key response to 545 indicate that the key may be cached. 547 If the encryption METHOD is AES-128, AES-128 CBC encryption SHALL be 548 applied to individual media files. The entire file MUST be 549 encrypted. Cipher Block Chaining MUST NOT be applied across media 550 files. The IV used for encryption MUST be either the sequence number 551 of the media file or the value of the IV attribute of the EXT-X-KEY 552 tag, as described in Section 5.2. 554 The server MUST encrypt every media file in a Playlist using the 555 method and other attributes specified by the EXT-X-KEY tag that most 556 immediately precedes its URI in the Playlist file. Media files 557 preceded by an EXT-X-KEY tag whose METHOD is NONE, or not preceded by 558 any EXT-X-KEY tag, MUST NOT be encrypted. 560 The server MUST NOT remove an EXT-X-KEY tag from the Playlist file if 561 the Playlist file contains a URI to a media file encrypted with that 562 key. 564 6.2.4. Providing variant streams 566 A server MAY offer multiple Playlist files to provide different 567 encodings of the same presentation. If it does so it SHOULD provide 568 a variant Playlist file that lists each variant stream to allow 569 clients to switch between encodings dynamically. 571 Variant Playlists MUST contain an EXT-X-STREAM-INF tag for each 572 variant stream. Each EXT-X-STREAM-INF tag for the same presentation 573 MUST have the same PROGRAM-ID attribute value. The PROGRAM-ID value 574 for each presentation MUST be unique within the variant Playlist. 576 If an EXT-X-STREAM-INF tag contains the CODECS attribute, the 577 attribute value MUST include every format defined by [RFC4281] that 578 is present in any media file that appears or will appear in the 579 Playlist file. 581 The server MUST meet the following constraints when producing variant 582 streams: 584 Each variant stream MUST present the same content, including 585 stream discontinuities. 587 Each variant Playlist file MUST have the same target duration. 589 Content that appears in one variant Playlist file but not in 590 another MUST appear either at the beginning or at the end of the 591 Playlist file and MUST NOT be longer than the target duration. 593 Matching content in variant streams MUST have matching timestamps. 594 This allows clients to synchronize the streams. 596 Elementary Audio Stream files MUST signal the timestamp of the 597 first sample in the file by prepending an ID3 PRIV tag [ID3] with 598 an owner identifier of 599 "com.apple.streaming.transportStreamTimestamp". The binary data 600 MUST be a 33-bit MPEG-2 Program Elementary Stream timestamp 601 expressed as a big-endian eight-octet number. 603 In addition, all variant streams SHOULD contain the same encoded 604 audio bitstream. This allows clients to switch between streams 605 without audible glitching. 607 6.3. Client Process 609 6.3.1. Introduction 611 How the client obtains the URI to the Playlist file is outside the 612 scope of this document; it is presumed to have done so. 614 The client MUST obtain the Playlist file from the URI. If the 615 Playlist file so obtained is a variant Playlist, the client MUST 616 obtain the Playlist file from the variant Playlist. 618 This document does not specify the treatment of variant streams by 619 clients. 621 6.3.2. Loading the Playlist file 623 Every time a Playlist file is loaded or reloaded from the Playlist 624 URI: 626 The client MUST ensure that the Playlist file begins with the 627 EXTM3U tag and that the EXT-X-VERSION tag, if present, specifies a 628 protocol version supported by the client; if not, the client MUST 629 NOT attempt to use the Playlist. 631 The client SHOULD ignore any tags and attributes it does not 632 recognize. 634 The client MUST determine the next media file to load as described 635 in Section 6.3.5. 637 If the Playlist contains the EXT-X-MEDIA-SEQUENCE tag, the client 638 SHOULD assume that each media file in it will become unavailable at 639 the time that the Playlist file was loaded plus the duration of the 640 Playlist file. The duration of a Playlist file is the sum of the 641 durations of the media files within it. 643 6.3.3. Playing the Playlist file 645 The client SHALL choose which media file to play first from the 646 Playlist when playback starts. If the EXT-X-ENDLIST tag is not 647 present and the client intends to play the media regularly (i.e. in 648 playlist order at the nominal playback rate), the client SHOULD NOT 649 choose a file which starts less than three target durations from the 650 end of the Playlist file. Doing so can trigger playback stalls. 652 To achieve regular playback, media files MUST be played in the order 653 that they appear in the Playlist file. The client MAY present the 654 available media in any way it wishes, including regular playback, 655 random access, and trick modes. 657 The client MUST be prepared to reset its parser(s) and decoder(s) 658 before playing a media file that is preceded by an EXT-X- 659 DISCONTINUITY tag. 661 The client SHOULD attempt to load media files in advance of when they 662 will be required for uninterrupted playback to compensate for 663 temporary variations in latency and throughput. 665 If the Playlist file contains the EXT-X-ALLOW-CACHE tag and its value 666 is NO, the client MUST NOT cache downloaded media files after they 667 have been played. Otherwise the client MAY cache downloaded media 668 files indefinitely for later replay. 670 The client MAY use the value of the EXT-X-PROGRAM-DATE-TIME tag to 671 display the program origination time to the user. If the value 672 includes time zone information the client SHALL take it into account, 673 but if it does not the client MUST NOT infer an originating time 674 zone. 676 The client MUST NOT depend upon the correctness or the consistency of 677 the value of the EXT-X-PROGRAM-DATE-TIME tag. 679 6.3.4. Reloading the Playlist file 681 The client MUST periodically reload the Playlist file unless it 682 contains the EXT-X-ENDLIST tag. 684 However the client MUST NOT attempt to reload the Playlist file more 685 frequently than specified by this section. 687 When a client loads a Playlist file for the first time or reloads a 688 Playlist file and finds that it has changed since the last time it 689 was loaded, the client MUST wait for a period of time before 690 attempting to reload the Playlist file again. This period is called 691 the initial minimum reload delay. It is measured from the time that 692 the client began loading the Playlist file. 694 The initial minimum reload delay is the duration of the last media 695 file in the Playlist. Media file duration is specified by the EXTINF 696 tag. 698 If the client reloads a Playlist file and finds that it has not 699 changed then it MUST wait for a period of time before retrying. The 700 minimum delay is a multiple of the target duration. This multiple is 701 0.5 for the first attempt, 1.5 for the second, and 3.0 thereafter. 703 6.3.5. Determining the next file to load 705 The client MUST examine the Playlist file every time it is loaded or 706 reloaded to determine the next media file to load. 708 The first file to load MUST be the file that the client has chosen to 709 play first, as described in Section 6.3.3. 711 If the first file to be played has been loaded and the Playlist file 712 does not contain the EXT-X-MEDIA-SEQUENCE tag then the client MUST 713 verify that the current Playlist file contains the URI of the last 714 loaded media file at the offset it was originally found at, halting 715 playback if it does not. The next media file to load MUST be the 716 first media file URI following the last-loaded URI in the Playlist. 718 If the first file to be played has been loaded and the Playlist file 719 contains the EXT-X-MEDIA-SEQUENCE tag then the next media file to 720 load SHALL be the one with the lowest sequence number that is greater 721 than the sequence number of the last media file loaded. 723 6.3.6. Decrypting encrypted media files 725 If a Playlist file contains an EXT-X-KEY tag that specifies a Key 726 file URI, the client MUST obtain that key file and use the key inside 727 it to decrypt all media files following the EXT-X-KEY tag until 728 another EXT-X-KEY tag is encountered. 730 If the encryption METHOD is AES-128, AES-128 CBC decryption SHALL be 731 applied to individual media files. The entire file MUST be 732 decrypted. Cipher Block Chaining MUST NOT be applied across media 733 files. The IV used for decryption MUST be either the sequence number 734 of the media file or the value of the IV attribute of the EXT-X-KEY 735 tag, as described in Section 5.2. 737 If the encryption METHOD is NONE, the client MUST treat all media 738 files following the EXT-X-KEY tag as cleartext (not encrypted) until 739 another EXT-X-KEY tag is encountered. 741 7. Protocol version compatibility 743 Clients and servers MUST implement protocol version 2 or higher to 744 use: 746 o The IV attribute of the EXT-X-KEY tag. 748 8. Examples 750 8.1. Introduction 752 This section contains several example Playlist files. 754 8.2. Simple Playlist file 756 #EXTM3U 757 #EXT-X-TARGETDURATION:5220 758 #EXTINF:5220, 759 http://media.example.com/entire.ts 760 #EXT-X-ENDLIST 762 8.3. Sliding Window Playlist, using HTTPS 764 #EXTM3U 765 #EXT-X-TARGETDURATION:8 766 #EXT-X-MEDIA-SEQUENCE:2680 768 #EXTINF:8, 769 https://priv.example.com/fileSequence2680.ts 770 #EXTINF:8, 771 https://priv.example.com/fileSequence2681.ts 772 #EXTINF:8, 773 https://priv.example.com/fileSequence2682.ts 775 8.4. Playlist file with encrypted media files 777 #EXTM3U 778 #EXT-X-MEDIA-SEQUENCE:7794 779 #EXT-X-TARGETDURATION:15 781 #EXT-X-KEY:METHOD=AES-128,URI="https://priv.example.com/key.php?r=52" 783 #EXTINF:15, 784 http://media.example.com/fileSequence52-1.ts 785 #EXTINF:15, 786 http://media.example.com/fileSequence52-2.ts 787 #EXTINF:15, 788 http://media.example.com/fileSequence52-3.ts 790 #EXT-X-KEY:METHOD=AES-128,URI="https://priv.example.com/key.php?r=53" 792 #EXTINF:15, 793 http://media.example.com/fileSequence53-1.ts 795 8.5. Variant Playlist file 797 #EXTM3U 798 #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1280000 799 http://example.com/low.m3u8 800 #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=2560000 801 http://example.com/mid.m3u8 802 #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=7680000 803 http://example.com/hi.m3u8 804 #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=65000,CODECS="mp4a.40.5" 805 http://example.com/audio-only.m3u8 807 9. Contributors 809 Significant contributions to the design of this protocol were made by 810 Jim Batson, David Biderman, Bill May, Roger Pantos, and Alan Tseng. 812 10. IANA Considerations 814 This memo requests that the following MIME type [RFC2046] be 815 registered with the IANA: 817 Type name: "application" 819 Subtype name: "vnd.apple.mpegurl" 821 Required parameters: (none) 823 Optional parameters: (none) 825 Encoding considerations: encoded as text. See Section 3 for more 826 information. 828 Security considerations: See Section 11. 830 Compression: this media type does not employ compression. 832 Interoperability considerations: There are no byte-ordering issues, 833 since files are 7- or 8-bit text. Applications could encounter 834 unrecognized tags, which SHOULD be ignored. 836 Published specification: see Section 3. 838 Applications that use this media type: Multimedia applications such 839 as the iPhone media player (OS 3.0) and QuickTime Player in Mac OS X 840 Snow Leopard. 842 Additional information: files begin with the magic number #EXTM3U. 843 Filenames normally end with .m3u8 or .m3u (see Section 3). No 844 Macintosh file type codes have been registered. 846 Person & email address to contact for further information: David 847 Singer, singer AT apple.com. 849 Intended usage: LIMITED USE 851 Restrictions on usage: (none) 853 Author: Roger Pantos 854 Change Controller: David Singer 856 11. Security Considerations 858 Since the protocol generally uses HTTP to transfer data, most of the 859 same security considerations apply. See section 15 of RFC 2616 860 [RFC2616]. 862 Media file parsers are typically subject to "fuzzing" attacks. 863 Clients SHOULD take care when parsing files received from a server so 864 that non-compliant files are rejected. 866 Playlist files contain URIs, which clients will use to make network 867 requests of arbitrary entities. Clients SHOULD range-check responses 868 to prevent buffer overflows. See also the Security Considerations 869 section of RFC 3986 [RFC3986]. 871 Clients SHOULD load resources identified by URI lazily to avoid 872 contributing to denial-of-service attacks. 874 HTTP requests often include session state ("cookies"), which may 875 contain private user data. Implementations MUST follow cookie 876 restriction and expiry rules specified by RFC 2965 [RFC2965]. See 877 also the Security Considerations section of RFC 2965, and RFC 2964 878 [RFC2964]. 880 Encryption keys are specified by URI. The delivery of these keys 881 SHOULD be secured by a mechanism such as HTTP over TLS [RFC5246] 882 (formerly SSL) in conjunction with a secure realm or a session 883 cookie. 885 12. References 887 12.1. Normative References 889 [AES_128] U.S. Department of Commerce/National Institute of 890 Standards and Technology, "Advanced Encryption Standard 891 (AES), FIPS PUB 197", November 2001, <http:// 892 csrc.nist.gov/publications/fips/fips197/fips-197.pdf>. 894 [ISO_13818] 895 International Organization for Standardization, "ISO/IEC 896 International Standard 13818; Generic coding of moving 897 pictures and associated audio information", October 2007, 898 <http://www.iso.org/iso/catalogue_detail?csnumber=44169>. 900 [ISO_8601] 901 International Organization for Standardization, "ISO/IEC 902 International Standard 8601:2004; Data elements and 903 interchange formats -- Information interchange -- 904 Representation of dates and times", December 2004, 905 <http://www.iso.org/iso/catalogue_detail?csnumber=40874>. 907 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 908 Extensions (MIME) Part Two: Media Types", RFC 2046, 909 November 1996. 911 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 912 Requirement Levels", BCP 14, RFC 2119, March 1997. 914 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 915 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 916 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 918 [RFC2964] Moore, K. and N. Freed, "Use of HTTP State Management", 919 BCP 44, RFC 2964, October 2000. 921 [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management 922 Mechanism", RFC 2965, October 2000. 924 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 925 10646", STD 63, RFC 3629, November 2003. 927 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 928 Resource Identifier (URI): Generic Syntax", STD 66, 929 RFC 3986, January 2005. 931 [RFC4281] Gellens, R., Singer, D., and P. Frojdh, "The Codecs 932 Parameter for "Bucket" Media Types", RFC 4281, 933 November 2005. 935 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 936 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 938 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", 939 RFC 5652, September 2009. 941 [US_ASCII] 942 American National Standards Institute, "ANSI X3.4-1986, 943 Information Systems -- Coded Character Sets 7-Bit American 944 National Standard Code for Information Interchange (7-Bit 945 ASCII)", December 1986. 947 12.2. Informative References 949 [ID3] ID3.org, "The ID3 audio file data tagging format", 950 <http://www.id3.org/Developer_Information>. 952 [M3U] Nullsoft, Inc., "The M3U Playlist format, originally 953 invented for the Winamp media player", 954 <http://wikipedia.org/wiki/M3U>. 956 Authors' Addresses 958 Roger Pantos (editor) 959 Apple Inc. 960 Cupertino, California 961 United States 963 Email: http-live-streaming-review@group.apple.com 965 William May, Jr. 966 Apple Inc. 967 Cupertino, California 968 United States 970 Email: http-live-streaming-review@group.apple.com