idnits 2.17.1 draft-pantos-http-live-streaming-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 (October 5, 2009) is 5317 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 3852 (Obsoleted by RFC 5652) ** Obsolete normative reference: RFC 4281 (Obsoleted by RFC 6381) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 6 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 October 5, 2009 5 Expires: April 8, 2010 7 HTTP Live Streaming 8 draft-pantos-http-live-streaming-02 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. This document may not be modified, 14 and derivative works of it may not be created, and it may not be 15 published except as an Internet-Draft. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 8, 2010. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 To the extent that this Informational Internet Draft contains one or 47 more Code Components (see the IETF Trust's Legal Provisions Relating 48 to IETF Documents effective Feb. 15, 2009), such Code Components are 49 exempt from and not subject to Section 4 of the Legal Provisions. 51 Furthermore, this Informational Internet Draft is submitted as an RFC 52 Editor Contribution and/or non-IETF Document (not as a Contribution, 53 IETF Contribution, nor IETF Document) in accordance with BCP 78 and 54 BCP 79. 56 Abstract 58 This document describes a protocol for transmitting unbounded streams 59 of multimedia data. It specifies the data format of the files and 60 the actions to be taken by the server (sender) and the clients 61 (receivers) of the streams. It describes version 1.0 of this 62 protocol. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. The Playlist file . . . . . . . . . . . . . . . . . . . . . . 4 69 3.1. New Tags . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3.1.1. EXT-X-TARGETDURATION . . . . . . . . . . . . . . . . . 5 71 3.1.2. EXT-X-MEDIA-SEQUENCE . . . . . . . . . . . . . . . . . 6 72 3.1.3. EXT-X-KEY . . . . . . . . . . . . . . . . . . . . . . 6 73 3.1.4. EXT-X-PROGRAM-DATE-TIME . . . . . . . . . . . . . . . 7 74 3.1.5. EXT-X-ALLOW-CACHE . . . . . . . . . . . . . . . . . . 7 75 3.1.6. EXT-X-ENDLIST . . . . . . . . . . . . . . . . . . . . 7 76 3.1.7. EXT-X-STREAM-INF . . . . . . . . . . . . . . . . . . . 7 77 3.1.8. EXT-X-DISCONTINUITY . . . . . . . . . . . . . . . . . 8 78 4. Media files . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 5. Key files . . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 5.1. IV for AES-128 . . . . . . . . . . . . . . . . . . . . . . 9 81 6. Client/Server Actions . . . . . . . . . . . . . . . . . . . . 9 82 6.1. Server Process . . . . . . . . . . . . . . . . . . . . . . 9 83 6.1.1. Sliding Window Playlists . . . . . . . . . . . . . . . 10 84 6.1.2. Encrypting media files . . . . . . . . . . . . . . . . 11 85 6.1.3. Providing variant streams . . . . . . . . . . . . . . 11 86 6.2. Client Process . . . . . . . . . . . . . . . . . . . . . . 12 87 6.2.1. Loading the Playlist file . . . . . . . . . . . . . . 13 88 6.2.2. Playing the Playlist file . . . . . . . . . . . . . . 13 89 6.2.3. Reloading the Playlist file . . . . . . . . . . . . . 14 90 6.2.4. Determining the next file to load . . . . . . . . . . 14 91 6.2.5. Playing encrypted media files . . . . . . . . . . . . 15 92 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 93 7.1. Simple Playlist file . . . . . . . . . . . . . . . . . . . 15 94 7.2. Sliding Window Playlist, using HTTPS . . . . . . . . . . . 15 95 7.3. Playlist file with encrypted media files . . . . . . . . . 16 96 7.4. Variant Playlist file . . . . . . . . . . . . . . . . . . 16 97 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16 98 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 99 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 100 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 101 11.1. Normative References . . . . . . . . . . . . . . . . . . . 18 102 11.2. Informative References . . . . . . . . . . . . . . . . . . 19 103 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 105 1. Introduction 107 This document describes a protocol for transmitting unbounded streams 108 of multimedia data. The protocol supports the encryption of media 109 data and the provision of alternate versions (e.g. bitrates) of a 110 stream. Media data can be transmitted soon after it is created, 111 allowing it to be received in near real-time. Data is usually 112 carried over HTTP [RFC2616]. 114 External references that describe related standards such as HTTP are 115 listed in Section 11. 117 2. Summary 119 A multimedia presentation is specified by a URI [RFC3986] to a 120 Playlist file, which is an ordered list of additional URIs. Each URI 121 in the Playlist file refers to a media file which is a segment of a 122 single contiguous stream. 124 To play the stream, the client first obtains the Playlist file and 125 then obtains and plays each media file in the Playlist. It reloads 126 the Playlist file as described in this document to discover 127 additional segments. 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in RFC 2119 [RFC2119]. 133 3. The Playlist file 135 Playlists MUST be Extended M3U Playlist files [M3U]. This document 136 extends the M3U file format by defining additional tags. 138 An M3U Playlist is a text file that consists of individual lines. 139 Lines are terminated by either a single LF character or a CR 140 character followed by an LF character. Each line is a URI, a blank, 141 or starts with the comment character '#'. URIs identify media files 142 to be played. Blank lines are ignored. 144 Lines that start with the comment character '#' are either comments 145 or tags. Tags begin with #EXT. All other lines that begin with '#' 146 are comments and SHOULD be ignored. 148 M3U Playlist files whose names end in .m3u8 and/or have the HTTP 149 Content-Type "application/vnd.apple.mpegurl" are encoded in UTF-8 150 [RFC3629]. Files whose names end with .m3u and/or have the HTTP 151 Content-Type [RFC2616] "audio/mpegurl" are encoded in US-ASCII 152 [US_ASCII]. 154 Implementations SHOULD produce Playlist files whose names end in 155 .m3u8 or, if transmitted over HTTP, have the Content-Type 156 "application/vnd.apple.mpegurl". For compatibility, implementations 157 MAY produce Playlist files whose names end in .m3u and/or have the 158 HTTP Content-Type type "audio/mpegurl". 160 The Extended M3U file format defines two tags: EXTM3U and EXTINF. An 161 Extended M3U file is distinguished from a basic M3U file by its first 162 line, which MUST be #EXTM3U. 164 EXTINF is a record marker that describes the media file identified by 165 the URI that follows it. Each media file URI MUST be preceded by an 166 EXTINF tag. Its format is: 168 #EXTINF:, 170 "duration" is an integer that specifies the duration of the media 171 file in seconds. Durations SHOULD be rounded to the nearest integer. 172 The remainder of the line following the comma is the title of the 173 media file. 175 3.1. New Tags 177 This document defines seven new tags: EXT-X-TARGETDURATION, EXT-X- 178 MEDIA-SEQUENCE, EXT-X-KEY, EXT-X-PROGRAM-DATE-TIME, EXT-X-ALLOW- 179 CACHE, EXT-X-STREAM-INF, and EXT-X-ENDLIST. 181 3.1.1. EXT-X-TARGETDURATION 183 The EXT-X-TARGETDURATION tag indicates the approximate duration of 184 the next media file that will be added to the main presentation. It 185 MUST appear in the Playlist file. Its format is: 187 #EXT-X-TARGETDURATION:<seconds> 189 The actual duration of the media file MAY differ slightly from the 190 target duration. 192 3.1.2. EXT-X-MEDIA-SEQUENCE 194 Each media file URI in a Playlist has a unique sequence number. The 195 sequence number of a URI is equal to the sequence number of the URI 196 that preceded it plus one. The EXT-X-MEDIA-SEQUENCE tag indicates 197 the sequence number of the first URI that appears in a Playlist file. 198 Its format is: 200 #EXT-X-MEDIA-SEQUENCE:<number> 202 If the Playlist file does not contain an EXT-X-MEDIA-SEQUENCE tag 203 then the sequence number of the first URI in the playlist SHALL be 204 considered to be 1. 206 See Section 6.2.1 and Section 6.2.4 for information on handling the 207 EXT-X-MEDIA-SEQUENCE tag. 209 3.1.3. EXT-X-KEY 211 Media files MAY be encrypted. The EXT-X-KEY tag provides information 212 necessary to decrypt media files that follow it. Its format is: 214 #EXT-X-KEY:METHOD=<method>[,URI="<URI>"] 216 The METHOD parameter specifies the encryption method. The URI 217 parameter, if present, specifies how to obtain the key. 219 Version 1.0 of the protocol defines two encryption methods: NONE and 220 AES-128. An encryption method of NONE means that media files are not 221 encrypted. 223 An encryption method of AES-128 means that media files are encrypted 224 using the Advanced Encryption Standard [AES_128] with a 128-bit key 225 and PKCS7 padding [RFC3852]. 227 A new EXT-X-KEY supersedes any prior EXT-X-KEY. 229 If no EXT-X-KEY tag is present then media files are not encrypted. 231 See Section 5 for the format of the key file, and Section 5.1, 232 Section 6.1.2 and Section 6.2.5 for additional information on media 233 file encryption. 235 3.1.4. EXT-X-PROGRAM-DATE-TIME 237 The EXT-X-PROGRAM-DATE-TIME tag associates the beginning of the next 238 media file with an absolute date and/or time. The date/time 239 representation is ISO/IEC 8601:2004 [ISO_8601] and SHOULD indicate a 240 time zone. For example: 242 #EXT-X-PROGRAM-DATE-TIME:<YYYY-MM-DDThh:mm:ssZ> 244 3.1.5. EXT-X-ALLOW-CACHE 246 The EXT-X-ALLOW-CACHE tag indicates whether the client MAY cache 247 downloaded media files for later replay. Its format is: 249 #EXT-X-ALLOW-CACHE:<YES|NO> 251 See Section 6.2.2 for more information on treating the EXT-X-ALLOW- 252 CACHE tag. 254 3.1.6. EXT-X-ENDLIST 256 The EXT-X-ENDLIST tag indicates that no more media files will be 257 added to the Playlist file. Its format is: 259 #EXT-X-ENDLIST 261 3.1.7. EXT-X-STREAM-INF 263 The EXT-X-STREAM-INF tag indicates that the next URI in the Playlist 264 file identifies another Playlist file. Its format is: 266 #EXT-X-STREAM-INF:[attribute=value][,attribute=value]* 267 <URI> 269 The following attributes are defined for the EXT-X-STREAM-INF tag: 271 BANDWIDTH=<n> 273 where n is an approximate upper bound of the stream bitrate, 274 expressed as a number of bits per second. 276 PROGRAM-ID=<i> 278 where i is a number that uniquely identifies a particular 279 presentation within the scope of the Playlist file. 281 A Playlist file MAY contain multiple EXT-X-STREAM-INF URIs with the 282 same PROGRAM-ID to describe variant streams of the same presentation. 284 CODECS="[format][,format]*" 286 where each format specifies a media sample type that is present in a 287 media file in the Playlist file. 289 Valid format identifiers are those in the ISO File Format Name Space 290 defined by RFC 4281 [RFC4281]. 292 3.1.8. EXT-X-DISCONTINUITY 294 The EXT-X-DISCONTINUITY tag indicates that the media file following 295 it has different characteristics than the one that preceded it. The 296 set of characteristics that MAY change is: 298 o file format 300 o number and type of tracks 302 o encoding parameters 304 o encoding sequence 306 o timestamp sequence 308 Its format is: 310 #EXT-X-DISCONTINUITY 312 4. Media files 314 Each media file URI in a Playlist file MUST identify a media file 315 which is a segment of the overall presentation. Each media file MUST 316 be formatted as an MPEG-2 Transport Stream, an MPEG-2 Program Stream, 317 or an MPEG-2 audio elementary stream [ISO_13818]. All media files in 318 a presentation MUST have the same format. 320 Transport Stream files MUST contain a single MPEG-2 Program. There 321 SHOULD be a Program Association Table and a Program Map Table at the 322 start of each file. A file that contains video SHOULD have at least 323 one key frame and enough information to completely initialize a video 324 decoder. 326 Clients SHOULD be prepared to handle multiple tracks of a particular 327 type (e.g. audio or video) by choosing a reasonable subset. Clients 328 MUST ignore private streams inside Transport Streams that they do not 329 recognize. 331 The encoding parameters for samples within a stream inside a media 332 file and between corresponding streams across multiple media files 333 SHOULD remain consistent. However clients SHOULD deal with encoding 334 changes as they are encountered, for example by scaling video content 335 to accomodate a resolution change. 337 5. Key files 339 An EXT-X-KEY tag with the URI parameter identifies a Key file. A Key 340 file contains the cipher key that MUST be used to decrypt subsequent 341 media files in the Playlist. 343 The AES-128 encryption method uses 16-octet keys. The format of the 344 Key file is simply a packed array of these 16 octets in binary 345 format. 347 5.1. IV for AES-128 349 128-bit AES requires the same 16-octet Initialization Vector (IV) to 350 be supplied when encrypting and decrypting. Varying this IV 351 increases the strength of the cipher. 353 When using the encryption METHOD AES-128, implementations SHALL use 354 the sequence number of the media file as the IV when encrypting or 355 decrypting media files. The big-endian binary representation of the 356 sequence number SHALL be placed in a 16-octet buffer and padded (on 357 the left) with zeros. 359 6. Client/Server Actions 361 This section describes how the server generates the Playlist and 362 media files and how the client should download and play them. 364 6.1. Server Process 366 The production of the MPEG-2 stream is outside the scope of this 367 document, which simply presumes a source of a continuous stream 368 containing the main presentation. 370 The server MUST divide the stream into individual media files whose 371 duration is approximately equal. The server SHOULD attempt to divide 372 the stream at points that support effective decode of individual 373 media files, e.g. on packet and key frame boundaries. 375 The server MUST create a URI for each media file that will allow its 376 clients to obtain the file. 378 The server MUST create a Playlist file. The Playlist file MUST 379 conform to the format described in Section 3. A URI for each media 380 file that the server wishes to make available MUST appear in the 381 Playlist in the order in which it is to be played. The entire media 382 file MUST be available to clients if its URI is in the Playlist file. 384 The Playlist file MUST contain an EXT-X-TARGETDURATION tag. It MUST 385 indicate the approximate duration of the next media file to be added 386 to the main presentation. This value MUST remain constant for the 387 entire presentation. A typical target duration is 10 seconds. 389 The server MUST create a URI for the Playlist file that will allow 390 its clients to obtain the file. 392 Changes to the Playlist file MUST be made atomically from the point 393 of view of the clients. 395 Every media file URI in a Playlist MUST be prefixed with an EXTINF 396 tag indicating the approximate duration of the media file. 398 The server MAY associate an absolute date and time with a media file 399 by prefixing its URI with an EXT-X-PROGRAM-DATE-TIME tag. The value 400 of the date and time is arbitrary. 402 If the Playlist contains the final media file of the presentation 403 then the Playlist file MUST contain the EXT-X-ENDLIST tag. 405 If the server wishes to remove an entire presentation, it MUST make 406 the Playlist file unavailable to clients. It SHOULD ensure that all 407 media files in the Playlist file remain available to clients for at 408 least the duration of the Playlist file at the time of removal. 410 6.1.1. Sliding Window Playlists 412 The server MAY limit the availability of media files to those which 413 have been most recently added to the Playlist. To do so the Playlist 414 file MUST ALWAYS contain exactly one EXT-X-MEDIA-SEQUENCE tag. Its 415 value MUST be incremented by 1 for every media file URI that is 416 removed from the Playlist file. 418 Media file URIs MUST be removed from the Playlist file in the order 419 in which they were added. 421 When the server removes a media file URI from the Playlist, the media 422 file MUST remain available to clients for a period of time equal to 423 the duration of the media file plus the duration of the longest 424 Playlist file in which the media file has appeared. The duration of 425 a Playlist file is the sum of the durations of the media files within 426 it. 428 If a server plans to remove a media file after it is delivered to 429 clients over HTTP, it SHOULD ensure that the HTTP response contains 430 an Expires header that reflects the planned time-to-live. 432 The server MUST maintain at least three main presentation media files 433 in the Playlist at all times unless the EXT-X-ENDLIST tag is present. 435 6.1.2. Encrypting media files 437 If media files are to be encrypted the server MUST define a URI which 438 will allow authorized clients to obtain a Key file containing a 439 decryption key. The Key file MUST conform to the format described in 440 Section 5. 442 The server MAY set the HTTP Expires header in the key response to 443 indicate that the key may be cached. 445 If the encryption METHOD is AES-128, AES-128 CBC encyption SHALL be 446 applied to individual media files. The entire file MUST be 447 encrypted. Cipher Block Chaining MUST NOT be applied across media 448 files. The sequence number of the media file MUST be used as the IV 449 as described in Section 5.1. 451 The server MUST encrypt every media file in a Playlist using the 452 method specified by the EXT-X-KEY tag that most immediately precedes 453 its URI in the Playlist file. Media files preceded by an EXT-X-KEY 454 tag whose METHOD is NONE, or not preceded by any EXT-X-KEY tag, MUST 455 NOT be encrypted. 457 The URI of every EXT-X-KEY tag must be distinct from the URI of every 458 other EXT-X-KEY tag that appears or has appeared in the Playlist 459 file, unless its METHOD is NONE. An EXT-X-KEY tag with a METHOD of 460 NONE MUST NOT contain a URI parameter. 462 The server MUST NOT remove an EXT-X-KEY tag from the Playlist file if 463 the Playlist file contains a URI to a media file encrypted with that 464 key. 466 6.1.3. Providing variant streams 468 A server MAY offer multiple Playlist files to provide different 469 encodings of the same presentation. If it does so it SHOULD provide 470 a variant Playlist file that lists each variant stream to allow 471 clients to switch between encodings dynamically. 473 Variant Playlists MUST contain an EXT-X-STREAM-INF tag for each 474 variant stream. Each EXT-X-STREAM-INF tag for the same presentation 475 MUST have the same PROGRAM-ID attribute value. The PROGRAM-ID value 476 for each presentation MUST be unique within the variant Playlist. 478 If an EXT-X-STREAM-INF tag contains the CODECS attribute, the 479 attribute value MUST include every format defined by [RFC4281] that 480 is present in any media file that appears or will appear in the 481 Playlist file. 483 The server MUST meet the following constraints when producing variant 484 streams: 486 Each variant stream MUST consist of the same content, including 487 content which is not part of the main presentation. 489 The server MUST make the same period of content available for all 490 variant streams, within an accuracy of the smallest target 491 duration of the streams. 493 Matching content in variant streams MUST have matching timestamps. 494 This allows clients to synchronize the streams. 496 Elementary Audio Stream files MUST signal the timestamp of the 497 first sample in the file by prepending an ID3 PRIV tag [ID3] with 498 an owner identifier of 499 "com.apple.streaming.transportStreamTimestamp". The binary data 500 MUST be a 33-bit MPEG-2 Program Elementary Stream timestamp 501 expressed as a big-endian eight-octet number. 503 In addition, all variant streams SHOULD contain the same encoded 504 audio bitstream. This allows clients to switch between streams 505 without audible glitching. 507 6.2. Client Process 509 How the client obtains the URI to the Playlist file is outside the 510 scope of this document; it is presumed to have done so. 512 The client MUST obtain the Playlist file from the URI. If the 513 Playlist file so obtained is a variant Playlist, the client MUST 514 obtain the Playlist file from the variant Playlist. 516 This document does not specify the treatment of variant streams by 517 clients. 519 6.2.1. Loading the Playlist file 521 Every time a Playlist file is loaded or reloaded from the Playlist 522 URI: 524 The client SHOULD check that the Playlist file begins with #EXTM3U 525 and refuse to continue if it does not. The client SHOULD ignore 526 any tags it does not recognize. 528 The client MUST determine the next media file to load as described 529 in Section 6.2.4. 531 If the Playlist contains the EXT-X-MEDIA-SEQUENCE tag, the client 532 SHOULD assume that each media file in it will become unavailable at 533 the time that the Playlist file was loaded plus the duration of the 534 Playlist file. The duration of a Playlist file is the sum of the 535 durations of the media files within it. 537 6.2.2. Playing the Playlist file 539 The client SHALL choose which media file to play first from the 540 Playlist when playback starts. If the Playlist file contains the 541 EXT-X-ENDLIST tag, any file in the Playlist MAY be played first. If 542 the EXT-X-ENDLIST tag is not present, any file except for the last 543 and second-to-last files in the Playlist MAY be played first. 545 Once the first media file to play has been chosen, subsequent media 546 files in the Playlist MUST be loaded in the order that they appear 547 and played in the order that they are loaded. 549 The client SHOULD attempt to load media files in advance of when they 550 will be required for uninterrupted playback to compensate for 551 temporary variations in latency and throughput. 553 If the Playlist file contains the EXT-X-ALLOW-CACHE tag and its value 554 is NO, the client MUST NOT cache downloaded media files after they 555 have been played. Otherwise the client MAY cache downloaded media 556 files indefinitely for later replay. 558 The client MAY use the value of the EXT-X-PROGRAM-DATE-TIME tag to 559 display the program origination time to the user. If the value 560 includes time zone information the client SHALL take it into account, 561 but if it does not the client MUST NOT infer an originating time 562 zone. 564 The client MUST NOT depend upon the correctness or the consistency of 565 the value of the EXT-X-PROGRAM-DATE-TIME tag. 567 6.2.3. Reloading the Playlist file 569 The client MUST periodically reload the Playlist file unless it 570 contains the EXT-X-ENDLIST tag. 572 However the client MUST NOT attempt to reload the Playlist file more 573 frequently than specified by this section. 575 When a client loads a Playlist file for the first time or reloads a 576 Playlist file and finds that it has changed since the last time it 577 was loaded, the client MUST wait for a period of time before 578 attempting to reload the Playlist file again. This period is called 579 the initial minimum reload delay. It is measured from the time that 580 the client began loading the Playlist file. 582 The initial minimum reload delay is the duration of the last media 583 file in the Playlist or 3 times the target duration, whichever is 584 less. Media file duration is specified by the EXTINF tag. 586 If the client reloads a Playlist file and finds that it has not 587 changed then it MUST wait for a period of time before retrying. The 588 minimum delay is three times the target duration or a multiple of the 589 initial minimum reload delay, whichever is less. This multiple is 590 0.5 for the first attempt, 1.5 for the second, and 3.0 thereafter. 592 6.2.4. Determining the next file to load 594 The client MUST examine the Playlist file every time it is loaded or 595 reloaded to determine the next media file to load. 597 The first file to load MUST be the file that the client has chosen to 598 play first, as described in Section 6.2.2. 600 If the first file to be played has been loaded and the Playlist file 601 does not contain the EXT-X-MEDIA-SEQUENCE tag then the client MUST 602 verify that the current Playlist file contains the URI of the last 603 loaded media file at the offset it was originally found at, halting 604 playback if it does not. The next media file to load MUST be the 605 first media file URI following the last-loaded URI in the Playlist. 607 If the first file to be played has been loaded and the Playlist file 608 contains the EXT-X-MEDIA-SEQUENCE tag then the next media file to 609 load SHALL be the one with the lowest sequence number that is greater 610 than the sequence number of the last media file loaded. 612 6.2.5. Playing encrypted media files 614 If a Playlist file contains an EXT-X-KEY tag that specifies a Key 615 file URI, the client MUST obtain that key file and use the key inside 616 it to decrypt all media files following the EXT-X-KEY tag until 617 another EXT-X-KEY tag is encountered. 619 If the encryption METHOD is AES-128, AES-128 CBC decryption SHALL be 620 applied to individual media files. The entire file MUST be 621 decrypted. Cipher Block Chaining MUST NOT be applied across media 622 files. The sequence number of the media file MUST be used as the IV 623 as described in Section 5.1. 625 If the encryption METHOD is NONE, the client MUST treat all media 626 files following the EXT-X-KEY tag as cleartext (not encrypted) until 627 another EXT-X-KEY tag is encountered. 629 7. Examples 631 This section contains several example Playlist files. 633 7.1. Simple Playlist file 635 #EXTM3U 636 #EXT-X-TARGETDURATION:5220 637 #EXTINF:5220, 638 http://media.example.com/entire.ts 639 #EXT-X-ENDLIST 641 7.2. Sliding Window Playlist, using HTTPS 643 #EXTM3U 644 #EXT-X-TARGETDURATION:8 645 #EXT-X-MEDIA-SEQUENCE:2680 647 #EXTINF:8, 648 https://priv.example.com/fileSequence2680.ts 649 #EXTINF:8, 650 https://priv.example.com/fileSequence2681.ts 651 #EXTINF:8, 652 https://priv.example.com/fileSequence2682.ts 654 7.3. Playlist file with encrypted media files 656 #EXTM3U 657 #EXT-X-MEDIA-SEQUENCE:7794 658 #EXT-X-TARGETDURATION:15 660 #EXT-X-KEY:METHOD=AES-128,URI="https://priv.example.com/key.php?r=52" 662 #EXTINF:15, 663 http://media.example.com/fileSequence7794.ts 664 #EXTINF:15, 665 http://media.example.com/fileSequence7795.ts 666 #EXTINF:15, 667 http://media.example.com/fileSequence7796.ts 669 #EXT-X-KEY:METHOD=AES-128,URI="https://priv.example.com/key.php?r=53" 671 #EXTINF:15, 672 http://media.example.com/fileSequence7797.ts 674 7.4. Variant Playlist file 676 #EXTM3U 677 #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1280000 678 http://example.com/low.m3u8 679 #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=2560000 680 http://example.com/mid.m3u8 681 #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=7680000 682 http://example.com/hi.m3u8 683 #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=65000,CODECS="mp4a.40.5" 684 http://example.com/audio-only.m3u8 686 8. Contributors 688 Significant contributions to the design of this protocol were made by 689 Jim Batson, David Biderman, Bill May, Roger Pantos, and Alan Tseng. 691 9. IANA Considerations 693 This memo requests that the following MIME type [RFC2046] be 694 registered with the IANA: 696 Type name: "application" 698 Subtype name: "vnd.apple.mpegurl" 699 Required parameters: (none) 701 Optional parameters: (none) 703 Encoding considerations: encoded as text. See Section 3 for more 704 information. 706 Security considerations: See Section 10. 708 Compression: this media type does not employ compression. 710 Interoperability considerations: There are no byte-ordering issues, 711 since files are 7- or 8-bit text. Applications could encounter 712 unrecognized tags, which SHOULD be ignored. 714 Published specification: see Section 3. 716 Applications that use this media type: Multimedia applications such 717 as the iPhone media player (OS 3.0) and QuickTime Player in Mac OS X 718 Snow Leopard. 720 Additional information: files begin with the magic number #EXTM3U. 721 Filenames normally end with .m3u8 or .m3u (see Section 3). No 722 Macintosh file type codes have been registered. 724 Person & email address to contact for further information: David 725 Singer, singer AT apple.com. 727 Intended usage: LIMITED USE 729 Restrictions on usage: (none) 731 Author: Roger Pantos 733 Change Controller: David Singer 735 10. Security Considerations 737 Since the protocol generally uses HTTP to transmit data, most of the 738 same security considerations apply. See section 15 of RFC 2616 739 [RFC2616]. 741 Media file parsers are typically subject to "fuzzing" attacks. 742 Clients SHOULD take care when parsing files received from a server so 743 that non-compliant files are rejected. 745 Playlist files contain URIs, which clients will use to make network 746 requests of arbitrary entities. Clients SHOULD range-check responses 747 to prevent buffer overflows. See also the Security Considerations 748 section of RFC 3986 [RFC3986]. 750 Clients SHOULD load resources identified by URI lazily to avoid 751 contributing to denial-of-service attacks. 753 HTTP requests often include session state ("cookies"), which may 754 contain private user data. Implementations MUST follow cookie 755 restriction and expiry rules specified by RFC 2965 [RFC2965]. See 756 also the Security Considerations section of RFC 2965, and RFC 2964 757 [RFC2964]. 759 Encryption keys are specified by URI. The delivery of these keys 760 SHOULD be secured by a mechanism such as HTTP over TLS [RFC5246] 761 (formerly SSL) in conjunction with a secure realm or a session 762 cookie. 764 11. References 766 11.1. Normative References 768 [AES_128] U.S. Department of Commerce/National Institute of 769 Standards and Technology, "Advanced Encryption Standard 770 (AES), FIPS PUB 197", November 2001, <http:// 771 csrc.nist.gov/publications/fips/fips197/fips-197.pdf>. 773 [ISO_13818] 774 International Organization for Standardization, "ISO/IEC 775 International Standard 13818; Generic coding of moving 776 pictures and associated audio information", November 1994, 777 <http://www.iso.org/iso/catalogue_detail?csnumber=44169>. 779 [ISO_8601] 780 International Organization for Standardization, "ISO/IEC 781 International Standard 8601:2004; Data elements and 782 interchange formats -- Information interchange -- 783 Representation of dates and times", December 2004, 784 <http://www.iso.org/iso/catalogue_detail?csnumber=40874>. 786 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 787 Extensions (MIME) Part Two: Media Types", RFC 2046, 788 November 1996. 790 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 791 Requirement Levels", BCP 14, RFC 2119, March 1997. 793 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 794 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 795 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 797 [RFC2964] Moore, K. and N. Freed, "Use of HTTP State Management", 798 BCP 44, RFC 2964, October 2000. 800 [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management 801 Mechanism", RFC 2965, October 2000. 803 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 804 10646", STD 63, RFC 3629, November 2003. 806 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", 807 RFC 3852, July 2004. 809 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 810 Resource Identifier (URI): Generic Syntax", STD 66, 811 RFC 3986, January 2005. 813 [RFC4281] Gellens, R., Singer, D., and P. Frojdh, "The Codecs 814 Parameter for "Bucket" Media Types", RFC 4281, 815 November 2005. 817 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 818 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 820 [US_ASCII] 821 American National Standards Institute, "ANSI X3.4-1986, 822 Information Systems -- Coded Character Sets 7-Bit American 823 National Standard Code for Information Interchange (7-Bit 824 ASCII)", December 1986. 826 11.2. Informative References 828 [ID3] ID3.org, "The ID3 audio file data tagging format", 829 <http://www.id3.org/Developer_Information>. 831 [M3U] Nullsoft, Inc., "The M3U Playlist format, originally 832 invented for the Winamp media player", 833 <http://wikipedia.org/wiki/M3U>. 835 Author's Address 837 Roger Pantos (editor) 838 Apple Inc. 839 Cupertino, California 840 United States 842 Email: http-live-streaming-review@group.apple.com