idnits 2.17.1 draft-pantos-http-live-streaming-05.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 (November 19, 2010) is 4905 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: May 23, 2011 November 19, 2010 7 HTTP Live Streaming 8 draft-pantos-http-live-streaming-05 10 Abstract 12 This document describes a protocol for transferring unbounded streams 13 of multimedia data. It specifies the data format of the files and 14 the actions to be taken by the server (sender) and the clients 15 (receivers) of the streams. It describes version 3 of this protocol. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. This document may not be modified, 21 and derivative works of it may not be created, and it may not be 22 published except as an Internet-Draft. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on May 23, 2011. 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 This Informational Internet Draft is submitted as an RFC Editor 49 Contribution and/or non-IETF Document (not as a Contribution, IETF 50 Contribution, nor IETF Document) in accordance with BCP 78 and BCP 51 79. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. The Playlist file . . . . . . . . . . . . . . . . . . . . . . 4 58 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.2. New Tags . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3.2.1. EXT-X-TARGETDURATION . . . . . . . . . . . . . . . . . 6 61 3.2.2. EXT-X-MEDIA-SEQUENCE . . . . . . . . . . . . . . . . . 6 62 3.2.3. EXT-X-KEY . . . . . . . . . . . . . . . . . . . . . . 6 63 3.2.4. EXT-X-PROGRAM-DATE-TIME . . . . . . . . . . . . . . . 7 64 3.2.5. EXT-X-ALLOW-CACHE . . . . . . . . . . . . . . . . . . 7 65 3.2.6. EXT-X-ENDLIST . . . . . . . . . . . . . . . . . . . . 7 66 3.2.7. EXT-X-STREAM-INF . . . . . . . . . . . . . . . . . . . 8 67 3.2.8. EXT-X-DISCONTINUITY . . . . . . . . . . . . . . . . . 8 68 3.2.9. EXT-X-VERSION . . . . . . . . . . . . . . . . . . . . 9 69 4. Media files . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 5. Key files . . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 10 72 5.2. IV for AES-128 . . . . . . . . . . . . . . . . . . . . . . 10 73 6. Client/Server Actions . . . . . . . . . . . . . . . . . . . . 11 74 6.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 11 75 6.2. Server Process . . . . . . . . . . . . . . . . . . . . . . 11 76 6.2.1. Introduction . . . . . . . . . . . . . . . . . . . . . 11 77 6.2.2. Sliding Window Playlists . . . . . . . . . . . . . . . 12 78 6.2.3. Encrypting media files . . . . . . . . . . . . . . . . 13 79 6.2.4. Providing variant streams . . . . . . . . . . . . . . 13 80 6.3. Client Process . . . . . . . . . . . . . . . . . . . . . . 14 81 6.3.1. Introduction . . . . . . . . . . . . . . . . . . . . . 14 82 6.3.2. Loading the Playlist file . . . . . . . . . . . . . . 14 83 6.3.3. Playing the Playlist file . . . . . . . . . . . . . . 15 84 6.3.4. Reloading the Playlist file . . . . . . . . . . . . . 16 85 6.3.5. Determining the next file to load . . . . . . . . . . 16 86 6.3.6. Decrypting encrypted media files . . . . . . . . . . . 17 87 7. Protocol version compatibility . . . . . . . . . . . . . . . . 17 88 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 89 8.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 17 90 8.2. Simple Playlist file . . . . . . . . . . . . . . . . . . . 17 91 8.3. Sliding Window Playlist, using HTTPS . . . . . . . . . . . 18 92 8.4. Playlist file with encrypted media files . . . . . . . . . 18 93 8.5. Variant Playlist file . . . . . . . . . . . . . . . . . . 18 94 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19 95 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 96 11. Security Considerations . . . . . . . . . . . . . . . . . . . 20 97 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 98 12.1. Normative References . . . . . . . . . . . . . . . . . . . 20 99 12.2. Informative References . . . . . . . . . . . . . . . . . . 22 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 102 1. Introduction 104 This document describes a protocol for transferring unbounded streams 105 of multimedia data. The protocol supports the encryption of media 106 data and the provision of alternate versions (e.g. bitrates) of a 107 stream. Media data can be transferred soon after it is created, 108 allowing it to be played in near real-time. Data is usually carried 109 over HTTP [RFC2616]. 111 External references that describe related standards such as HTTP are 112 listed in Section 11. 114 2. Summary 116 A multimedia presentation is specified by a URI [RFC3986] to a 117 Playlist file, which is an ordered list of media URIs and 118 informational tags. Each media URI refers to a media file which is a 119 segment of a single contiguous stream. 121 To play the stream, the client first obtains the Playlist file and 122 then obtains and plays each media file in the Playlist. It reloads 123 the Playlist file as described in this document to discover 124 additional segments. 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in RFC 2119 [RFC2119]. 130 3. The Playlist file 132 3.1. Introduction 134 Playlists MUST be Extended M3U Playlist files [M3U]. This document 135 extends the M3U file format by defining additional tags. 137 An M3U Playlist is a text file that consists of individual lines. 138 Lines are terminated by either a single LF character or a CR 139 character followed by an LF character. Each line is a URI, a blank, 140 or starts with the comment character '#'. Blank lines are ignored. 141 White space MUST NOT be present, except for elements in which it is 142 explicitly specified. 144 A URI line identifies a media file or a variant Playlist file (see 145 Section 3.2.7). 147 URIs MAY be relative. A relative URI MUST be resolved against the 148 URI of the Playlist file that contains it. 150 Lines that start with the comment character '#' are either comments 151 or tags. Tags begin with #EXT. All other lines that begin with '#' 152 are comments and SHOULD be ignored. 154 The duration of a Playlist file is the sum of the durations of the 155 media files within it. 157 M3U Playlist files whose names end in .m3u8 and/or have the HTTP 158 Content-Type "application/vnd.apple.mpegurl" are encoded in UTF-8 159 [RFC3629]. Files whose names end with .m3u and/or have the HTTP 160 Content-Type [RFC2616] "audio/mpegurl" are encoded in US-ASCII 161 [US_ASCII]. 163 Playlist files MUST have names that end in .m3u8 and/or have the 164 Content-Type "application/vnd.apple.mpegurl" (if transferred over 165 HTTP), or have names that end in .m3u and/or have the HTTP Content- 166 Type type "audio/mpegurl" (for compatibility). 168 The Extended M3U file format defines two tags: EXTM3U and EXTINF. An 169 Extended M3U file is distinguished from a basic M3U file by its first 170 line, which MUST be #EXTM3U. 172 EXTINF is a record marker that describes the media file identified by 173 the URI that follows it. Each media file URI MUST be preceded by an 174 EXTINF tag. Its format is: 176 #EXTINF:, 178 "duration" is an integer or floating-point number that specifies the 179 duration of the media file in seconds. Integer durations SHOULD be 180 rounded to the nearest integer. Durations MUST be integers if the 181 protocol version of the Playlist file less than 3. The remainder of 182 the line following the comma is the title of the media file, which is 183 an optional human-readable informative title of the media segment. 185 This document defines the following new tags: EXT-X-TARGETDURATION, 186 EXT-X-MEDIA-SEQUENCE, EXT-X-KEY, EXT-X-PROGRAM-DATE-TIME, EXT-X- 187 ALLOW-CACHE, EXT-X-STREAM-INF, EXT-X-ENDLIST, EXT-X-DISCONTINUITY, 188 and EXT-X-VERSION. 190 3.2. New Tags 191 3.2.1. EXT-X-TARGETDURATION 193 The EXT-X-TARGETDURATION tag specifies the maximum media file 194 duration. The EXTINF duration of each media file in the Playlist 195 file MUST be less than or equal to the target duration. This tag 196 MUST appear once in the Playlist file. Its format is: 198 #EXT-X-TARGETDURATION:<s> 200 where s is an integer indicating the target duration in seconds. 202 3.2.2. EXT-X-MEDIA-SEQUENCE 204 Each media file URI in a Playlist has a unique integer sequence 205 number. The sequence number of a URI is equal to the sequence number 206 of the URI that preceded it plus one. The EXT-X-MEDIA-SEQUENCE tag 207 indicates the sequence number of the first URI that appears in a 208 Playlist file. Its format is: 210 #EXT-X-MEDIA-SEQUENCE:<number> 212 A Playlist file MUST NOT contain more than one EXT-X-MEDIA-SEQUENCE 213 tag. If the Playlist file does not contain an EXT-X-MEDIA-SEQUENCE 214 tag then the sequence number of the first URI in the playlist SHALL 215 be considered to be 0. 217 A media file's sequence number is not required to appear in its URI. 219 See Section 6.3.2 and Section 6.3.5 for information on handling the 220 EXT-X-MEDIA-SEQUENCE tag. 222 3.2.3. EXT-X-KEY 224 Media files MAY be encrypted. The EXT-X-KEY tag provides information 225 necessary to decrypt media files that follow it. Its format is: 227 #EXT-X-KEY:METHOD=<method>[,URI="<URI>"][,IV=<IV>] 229 The METHOD attribute specifies the encryption method. Two encryption 230 methods are defined: NONE and AES-128. 232 An encryption method of NONE means that media files are not 233 encrypted. If the encryption method is NONE, the URI and the IV 234 attributes MUST NOT be present. 236 An encryption method of AES-128 means that media files are encrypted 237 using the Advanced Encryption Standard [AES_128] with a 128-bit key 238 and PKCS7 padding [RFC5652]. If the encryption method is AES-128, 239 the URI attribute MUST be present. The IV attribute MAY be present; 240 see Section 5.2. 242 The URI attribute, if present, specifies how to obtain the key. The 243 IV attribute, if present, specifies the Initialization Vector to be 244 used with the key. The IV attribute appeared in protocol version 2. 246 A new EXT-X-KEY supersedes any prior EXT-X-KEY. 248 If the Playlist file does not contain an EXT-X-KEY tag then media 249 files are not encrypted. 251 See Section 5 for the format of the key file, and Section 5.2, 252 Section 6.2.3 and Section 6.3.6 for additional information on media 253 file encryption. 255 3.2.4. EXT-X-PROGRAM-DATE-TIME 257 The EXT-X-PROGRAM-DATE-TIME tag associates the beginning of the next 258 media file with an absolute date and/or time. The date/time 259 representation is ISO/IEC 8601:2004 [ISO_8601] and SHOULD indicate a 260 time zone. For example: 262 #EXT-X-PROGRAM-DATE-TIME:<YYYY-MM-DDThh:mm:ssZ> 264 See Section 6.2.1 and Section 6.3.3 for more information on the EXT- 265 X-PROGRAM-DATE-TIME tag. 267 3.2.5. EXT-X-ALLOW-CACHE 269 The EXT-X-ALLOW-CACHE tag indicates whether the client MAY or MUST 270 NOT cache downloaded media files for later replay. It MAY occur 271 anywhere in the Playlist file; it MUST NOT occur more than once. The 272 EXT-X-ALLOW-CACHE tag applies to all segments in the playlist. Its 273 format is: 275 #EXT-X-ALLOW-CACHE:<YES|NO> 277 See Section 6.3.3 for more information on the EXT-X-ALLOW-CACHE tag. 279 3.2.6. EXT-X-ENDLIST 281 The EXT-X-ENDLIST tag indicates that no more media files will be 282 added to the Playlist file. It MAY occur anywhere in the Playlist 283 file; it MUST NOT occur more than once. Its format is: 285 #EXT-X-ENDLIST 287 3.2.7. EXT-X-STREAM-INF 289 The EXT-X-STREAM-INF tag indicates that the next URI in the Playlist 290 file identifies another Playlist file. Its format is: 292 #EXT-X-STREAM-INF:[attribute=value][,attribute=value]* 293 <URI> 295 An attribute MUST NOT occur more than once in the same EXT-X-STREAM- 296 INF tag. The following attributes are defined: 298 BANDWIDTH=<n> 300 where n is an integer number of bits per second. It MUST be an upper 301 bound of the overall bitrate of each media file, calculated to 302 include container overhead, that appears or will appear in the 303 Playlist. 305 PROGRAM-ID=<i> 307 where i is an integer that uniquely identifies a particular 308 presentation within the scope of the Playlist file. 310 A Playlist file MAY contain multiple EXT-X-STREAM-INF tags with the 311 same PROGRAM-ID to identify different encodings of the same 312 presentation. These variant playlists MAY contain additional EXT-X- 313 STREAM-INF tags. 315 CODECS="[format][,format]*" 317 where each format specifies a media sample type that is present in a 318 media file in the Playlist file. 320 Valid format identifiers are those in the ISO File Format Name Space 321 defined by RFC 4281 [RFC4281]. 323 RESOLUTION=<N>x<M> 325 where N is the approximate encoded horizontal resolution of video 326 within the stream, expressed as a number of pixels, and M is the 327 approximate encoded vertical resolution. N and M are integers. 329 3.2.8. EXT-X-DISCONTINUITY 331 The EXT-X-DISCONTINUITY tag indicates an encoding discontinuity 332 between the media file that follows it and the one that preceded it. 333 The set of characteristics that MAY change is: 335 o file format 337 o number and type of tracks 339 o encoding parameters 341 o encoding sequence 343 o timestamp sequence 345 Its format is: 347 #EXT-X-DISCONTINUITY 349 See Section 4, Section 6.2.1, and Section 6.3.3 for more information 350 about the EXT-X-DISCONTINUITY tag. 352 3.2.9. EXT-X-VERSION 354 The EXT-X-VERSION tag indicates the compatibility version of the 355 Playlist file. The Playlist file, its associated media, and its 356 server MUST comply with all provisions of the most-recent version of 357 this document describing the protocol version indicated by the tag 358 value. 360 Its format is: 362 #EXT-X-VERSION:<n> 364 where n is an integer indicating the protocol version. 366 A Playlist file MUST NOT contain more than one EXT-X-VERSION tag. A 367 Playlist file that does not contain an EXT-X-VERSION tag MUST comply 368 with version 1 of this protocol. 370 4. Media files 372 Each media file URI in a Playlist file MUST identify a media file 373 which is a segment of the overall presentation. Each media file MUST 374 be formatted as an MPEG-2 Transport Stream or an MPEG-2 audio 375 elementary stream [ISO_13818]. 377 Transport Stream files MUST contain a single MPEG-2 Program. There 378 SHOULD be a Program Association Table and a Program Map Table at the 379 start of each file. A file that contains video SHOULD have at least 380 one key frame and enough information to completely initialize a video 381 decoder. 383 A media file in a Playlist MUST be the continuation of the encoded 384 stream at the end of the media file with the previous sequence number 385 unless it was the first media file ever to appear in the Playlist 386 file or it is prefixed by an EXT-X-DISCONTINUITY tag. 388 Clients SHOULD be prepared to handle multiple tracks of a particular 389 type (e.g. audio or video). A client with no other preference SHOULD 390 choose the one with the lowest numerical PID that it can play. 392 Clients MUST ignore private streams inside Transport Streams that 393 they do not recognize. 395 The encoding parameters for samples within a stream inside a media 396 file and between corresponding streams across multiple media files 397 SHOULD remain consistent. However clients SHOULD deal with encoding 398 changes as they are encountered, for example by scaling video content 399 to accommodate a resolution change. 401 5. Key files 403 5.1. Introduction 405 An EXT-X-KEY tag with the URI attribute identifies a Key file. A Key 406 file contains the cipher key that MUST be used to decrypt subsequent 407 media files in the Playlist. 409 The AES-128 encryption method uses 16-octet keys. The format of the 410 Key file is simply a packed array of these 16 octets in binary 411 format. 413 5.2. IV for AES-128 415 128-bit AES requires the same 16-octet Initialization Vector (IV) to 416 be supplied when encrypting and decrypting. Varying this IV 417 increases the strength of the cipher. 419 If the EXT-X-KEY tag has the IV attribute, implementations MUST use 420 the attribute value as the IV when encrypting or decrypting with that 421 key. The value MUST be interpreted as a 128-bit hexadecimal number 422 and MUST be prefixed with 0x or 0X. 424 If the EXT-X-KEY tag does not have the IV attribute, implementations 425 MUST use the sequence number of the media file as the IV when 426 encrypting or decrypting that media file. The big-endian binary 427 representation of the sequence number SHALL be placed in a 16-octet 428 buffer and padded (on the left) with zeros. 430 6. Client/Server Actions 432 6.1. Introduction 434 This section describes how the server generates the Playlist and 435 media files and how the client should download and play them. 437 6.2. Server Process 439 6.2.1. Introduction 441 The production of the MPEG-2 stream is outside the scope of this 442 document, which simply presumes a source of a continuous stream 443 containing the presentation. 445 The server MUST divide the stream into individual media files whose 446 duration is approximately equal. The server SHOULD attempt to divide 447 the stream at points that support effective decode of individual 448 media files, e.g. on packet and key frame boundaries. 450 The server MUST create a URI for each media file that will allow its 451 clients to obtain the file. 453 The server MUST create a Playlist file. The Playlist file MUST 454 conform to the format described in Section 3. A URI for each media 455 file that the server wishes to make available MUST appear in the 456 Playlist in the order in which it is to be played. The entire media 457 file MUST be available to clients if its URI is in the Playlist file. 459 The Playlist file MUST contain an EXT-X-TARGETDURATION tag. Its 460 value MUST be equal to or greater than the EXTINF value of any media 461 file that appears or will appear in the Playlist file. Its value 462 MUST NOT change. A typical target duration is 10 seconds. 464 The Playlist file SHOULD contain one EXT-X-VERSION tag which 465 indicates the compatibility version of the stream. Its value MUST be 466 the lowest protocol version with which the server, Playlist file, and 467 associated media files all comply. 469 The server MUST create a URI for the Playlist file that will allow 470 its clients to obtain the file. 472 If the Playlist file is distributed by HTTP, the server SHOULD 473 support client requests to use the "gzip" Content-Encoding. 475 Changes to the Playlist file MUST be made atomically from the point 476 of view of the clients. 478 The server MUST NOT change the value of the EXT-X-ALLOW-CACHE tag. 480 Every media file URI in a Playlist MUST be prefixed with an EXTINF 481 tag indicating the duration of the media file. 483 The server MAY associate an absolute date and time with a media file 484 by prefixing its URI with an EXT-X-PROGRAM-DATE-TIME tag. The value 485 of the date and time provides an informative mapping of the timeline 486 of the media to an appropriate wall-clock time, which may be used as 487 a basis for seeking, for display, or for other purposes. If a server 488 provides this mapping, it SHOULD place an EXT-X-PROGRAM-DATE-TIME tag 489 after every EXT-X-DISCONTINUITY tag in the Playlist file. 491 If the Playlist contains the final media file of the presentation 492 then the Playlist file MUST contain the EXT-X-ENDLIST tag. 494 If the Playlist does not contain the EXT-X-ENDLIST tag, the server 495 MUST make a new version of the Playlist file available that contains 496 at least one new media file URI. It MUST be made available relative 497 to the time that the previous version of the Playlist file was made 498 available: no earlier than one-half the target duration after that 499 time, and no later than 1.5 times the target duration after that 500 time. 502 If the server wishes to remove an entire presentation, it MUST make 503 the Playlist file unavailable to clients. It SHOULD ensure that all 504 media files in the Playlist file remain available to clients for at 505 least the duration of the Playlist file at the time of removal. 507 6.2.2. Sliding Window Playlists 509 The server MAY limit the availability of media files to those which 510 have been most recently added to the Playlist. To do so the Playlist 511 file MUST ALWAYS contain exactly one EXT-X-MEDIA-SEQUENCE tag. Its 512 value MUST be incremented by 1 for every media file URI that is 513 removed from the Playlist file. 515 Media file URIs MUST be removed from the Playlist file in the order 516 in which they were added. 518 The server MUST NOT remove a media file URI from the Playlist file if 519 the duration of the Playlist file minus the duration of the media 520 file is less than three times the target duration. 522 When the server removes a media file URI from the Playlist, the media 523 file SHOULD remain available to clients for a period of time equal to 524 the duration of the media file plus the duration of the longest 525 Playlist file in which the media file has appeared. 527 If a server plans to remove a media file after it is delivered to 528 clients over HTTP, it SHOULD ensure that the HTTP response contains 529 an Expires header that reflects the planned time-to-live. 531 6.2.3. Encrypting media files 533 If media files are to be encrypted the server MUST define a URI which 534 will allow authorized clients to obtain a Key file containing a 535 decryption key. The Key file MUST conform to the format described in 536 Section 5. 538 The server MAY set the HTTP Expires header in the key response to 539 indicate that the key may be cached. 541 If the encryption METHOD is AES-128, AES-128 CBC encryption SHALL be 542 applied to individual media files. The entire file MUST be 543 encrypted. Cipher Block Chaining MUST NOT be applied across media 544 files. The IV used for encryption MUST be either the sequence number 545 of the media file or the value of the IV attribute of the EXT-X-KEY 546 tag, as described in Section 5.2. 548 The server MUST encrypt every media file in a Playlist using the 549 method and other attributes specified by the EXT-X-KEY tag that most 550 immediately precedes its URI in the Playlist file. Media files 551 preceded by an EXT-X-KEY tag whose METHOD is NONE, or not preceded by 552 any EXT-X-KEY tag, MUST NOT be encrypted. 554 The server MUST NOT remove an EXT-X-KEY tag from the Playlist file if 555 the Playlist file contains a URI to a media file encrypted with that 556 key. 558 6.2.4. Providing variant streams 560 A server MAY offer multiple Playlist files to provide different 561 encodings of the same presentation. If it does so it SHOULD provide 562 a variant Playlist file that lists each variant stream to allow 563 clients to switch between encodings dynamically. 565 Variant Playlists MUST contain an EXT-X-STREAM-INF tag for each 566 variant stream. Each EXT-X-STREAM-INF tag for the same presentation 567 MUST have the same PROGRAM-ID attribute value. The PROGRAM-ID value 568 for each presentation MUST be unique within the variant Playlist. 570 If an EXT-X-STREAM-INF tag contains the CODECS attribute, the 571 attribute value MUST include every format defined by [RFC4281] that 572 is present in any media file that appears or will appear in the 573 Playlist file. 575 The server MUST meet the following constraints when producing variant 576 streams: 578 Each variant stream MUST present the same content, including 579 stream discontinuities. 581 Each variant Playlist file MUST have the same target duration. 583 Content that appears in one variant Playlist file but not in 584 another MUST appear either at the beginning or at the end of the 585 Playlist file and MUST NOT be longer than the target duration. 587 Matching content in variant streams MUST have matching timestamps. 588 This allows clients to synchronize the streams. 590 Elementary Audio Stream files MUST signal the timestamp of the 591 first sample in the file by prepending an ID3 PRIV tag [ID3] with 592 an owner identifier of 593 "com.apple.streaming.transportStreamTimestamp". The binary data 594 MUST be a 33-bit MPEG-2 Program Elementary Stream timestamp 595 expressed as a big-endian eight-octet number. 597 In addition, all variant streams SHOULD contain the same encoded 598 audio bitstream. This allows clients to switch between streams 599 without audible glitching. 601 6.3. Client Process 603 6.3.1. Introduction 605 How the client obtains the URI to the Playlist file is outside the 606 scope of this document; it is presumed to have done so. 608 The client MUST obtain the Playlist file from the URI. If the 609 Playlist file so obtained is a variant Playlist, the client MUST 610 obtain the Playlist file from the variant Playlist. 612 This document does not specify the treatment of variant streams by 613 clients. 615 6.3.2. Loading the Playlist file 617 Every time a Playlist file is loaded or reloaded from the Playlist 618 URI: 620 The client MUST ensure that the Playlist file begins with the 621 EXTM3U tag and that the EXT-X-VERSION tag, if present, specifies a 622 protocol version supported by the client; if not, the client MUST 623 NOT attempt to use the Playlist. 625 The client SHOULD ignore any tags and attributes it does not 626 recognize. 628 The client MUST determine the next media file to load as described 629 in Section 6.3.5. 631 If the Playlist contains the EXT-X-MEDIA-SEQUENCE tag, the client 632 SHOULD assume that each media file in it will become unavailable at 633 the time that the Playlist file was loaded plus the duration of the 634 Playlist file. The duration of a Playlist file is the sum of the 635 durations of the media files within it. 637 6.3.3. Playing the Playlist file 639 The client SHALL choose which media file to play first from the 640 Playlist when playback starts. If the EXT-X-ENDLIST tag is not 641 present and the client intends to play the media regularly (i.e. in 642 playlist order at the nominal playback rate), the client SHOULD NOT 643 choose a file which starts less than three target durations from the 644 end of the Playlist file. Doing so can trigger playback stalls. 646 To achieve regular playback, media files MUST be played in the order 647 that they appear in the Playlist file. The client MAY present the 648 available media in any way it wishes, including regular playback, 649 random access, and trick modes. 651 The client MUST be prepared to reset its parser(s) and decoder(s) 652 before playing a media file that is preceded by an EXT-X- 653 DISCONTINUITY tag. 655 The client SHOULD attempt to load media files in advance of when they 656 will be required for uninterrupted playback to compensate for 657 temporary variations in latency and throughput. 659 If the Playlist file contains the EXT-X-ALLOW-CACHE tag and its value 660 is NO, the client MUST NOT cache downloaded media files after they 661 have been played. Otherwise the client MAY cache downloaded media 662 files indefinitely for later replay. 664 The client MAY use the value of the EXT-X-PROGRAM-DATE-TIME tag to 665 display the program origination time to the user. If the value 666 includes time zone information the client SHALL take it into account, 667 but if it does not the client MUST NOT infer an originating time 668 zone. 670 The client MUST NOT depend upon the correctness or the consistency of 671 the value of the EXT-X-PROGRAM-DATE-TIME tag. 673 6.3.4. Reloading the Playlist file 675 The client MUST periodically reload the Playlist file unless it 676 contains the EXT-X-ENDLIST tag. 678 However the client MUST NOT attempt to reload the Playlist file more 679 frequently than specified by this section. 681 When a client loads a Playlist file for the first time or reloads a 682 Playlist file and finds that it has changed since the last time it 683 was loaded, the client MUST wait for a period of time before 684 attempting to reload the Playlist file again. This period is called 685 the initial minimum reload delay. It is measured from the time that 686 the client began loading the Playlist file. 688 The initial minimum reload delay is the duration of the last media 689 file in the Playlist. Media file duration is specified by the EXTINF 690 tag. 692 If the client reloads a Playlist file and finds that it has not 693 changed then it MUST wait for a period of time before retrying. The 694 minimum delay is a multiple of the target duration. This multiple is 695 0.5 for the first attempt, 1.5 for the second, and 3.0 thereafter. 697 6.3.5. Determining the next file to load 699 The client MUST examine the Playlist file every time it is loaded or 700 reloaded to determine the next media file to load. 702 The first file to load MUST be the file that the client has chosen to 703 play first, as described in Section 6.3.3. 705 If the first file to be played has been loaded and the Playlist file 706 does not contain the EXT-X-MEDIA-SEQUENCE tag then the client MUST 707 verify that the current Playlist file contains the URI of the last 708 loaded media file at the offset it was originally found at, halting 709 playback if it does not. The next media file to load MUST be the 710 first media file URI following the last-loaded URI in the Playlist. 712 If the first file to be played has been loaded and the Playlist file 713 contains the EXT-X-MEDIA-SEQUENCE tag then the next media file to 714 load SHALL be the one with the lowest sequence number that is greater 715 than the sequence number of the last media file loaded. 717 6.3.6. Decrypting encrypted media files 719 If a Playlist file contains an EXT-X-KEY tag that specifies a Key 720 file URI, the client MUST obtain that key file and use the key inside 721 it to decrypt all media files following the EXT-X-KEY tag until 722 another EXT-X-KEY tag is encountered. 724 If the encryption METHOD is AES-128, AES-128 CBC decryption SHALL be 725 applied to individual media files. The entire file MUST be 726 decrypted. Cipher Block Chaining MUST NOT be applied across media 727 files. The IV used for decryption MUST be either the sequence number 728 of the media file or the value of the IV attribute of the EXT-X-KEY 729 tag, as described in Section 5.2. 731 If the encryption METHOD is NONE, the client MUST treat all media 732 files following the EXT-X-KEY tag as cleartext (not encrypted) until 733 another EXT-X-KEY tag is encountered. 735 7. Protocol version compatibility 737 Clients and servers MUST implement protocol version 2 or higher to 738 use: 740 o The IV attribute of the EXT-X-KEY tag. 742 Clients and servers MUST implement protocol version 3 or higher to 743 use: 745 o Floating-point EXTINF duration values. 747 8. Examples 749 8.1. Introduction 751 This section contains several example Playlist files. 753 8.2. Simple Playlist file 755 #EXTM3U 756 #EXT-X-TARGETDURATION:5220 757 #EXTINF:5220, 758 http://media.example.com/entire.ts 759 #EXT-X-ENDLIST 761 8.3. Sliding Window Playlist, using HTTPS 763 #EXTM3U 764 #EXT-X-TARGETDURATION:8 765 #EXT-X-MEDIA-SEQUENCE:2680 767 #EXTINF:8, 768 https://priv.example.com/fileSequence2680.ts 769 #EXTINF:8, 770 https://priv.example.com/fileSequence2681.ts 771 #EXTINF:8, 772 https://priv.example.com/fileSequence2682.ts 774 8.4. Playlist file with encrypted media files 776 #EXTM3U 777 #EXT-X-MEDIA-SEQUENCE:7794 778 #EXT-X-TARGETDURATION:15 780 #EXT-X-KEY:METHOD=AES-128,URI="https://priv.example.com/key.php?r=52" 782 #EXTINF:15, 783 http://media.example.com/fileSequence52-1.ts 784 #EXTINF:15, 785 http://media.example.com/fileSequence52-2.ts 786 #EXTINF:15, 787 http://media.example.com/fileSequence52-3.ts 789 #EXT-X-KEY:METHOD=AES-128,URI="https://priv.example.com/key.php?r=53" 791 #EXTINF:15, 792 http://media.example.com/fileSequence53-1.ts 794 8.5. Variant Playlist file 796 #EXTM3U 797 #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1280000 798 http://example.com/low.m3u8 799 #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=2560000 800 http://example.com/mid.m3u8 801 #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=7680000 802 http://example.com/hi.m3u8 803 #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=65000,CODECS="mp4a.40.5" 804 http://example.com/audio-only.m3u8 806 9. Contributors 808 Significant contributions to the design of this protocol were made by 809 Jim Batson, David Biderman, Bill May, Roger Pantos, and Alan Tseng. 811 10. IANA Considerations 813 This memo requests that the following MIME type [RFC2046] be 814 registered with the IANA: 816 Type name: "application" 818 Subtype name: "vnd.apple.mpegurl" 820 Required parameters: (none) 822 Optional parameters: (none) 824 Encoding considerations: encoded as text. See Section 3 for more 825 information. 827 Security considerations: See Section 11. 829 Compression: this media type does not employ compression. 831 Interoperability considerations: There are no byte-ordering issues, 832 since files are 7- or 8-bit text. Applications could encounter 833 unrecognized tags, which SHOULD be ignored. 835 Published specification: see Section 3. 837 Applications that use this media type: Multimedia applications such 838 as the iPhone media player (OS 3.0) and QuickTime Player in Mac OS X 839 Snow Leopard. 841 Additional information: files begin with the magic number #EXTM3U. 842 Filenames normally end with .m3u8 or .m3u (see Section 3). No 843 Macintosh file type codes have been registered. 845 Person & email address to contact for further information: David 846 Singer, singer AT apple.com. 848 Intended usage: LIMITED USE 850 Restrictions on usage: (none) 852 Author: Roger Pantos 853 Change Controller: David Singer 855 11. Security Considerations 857 Since the protocol generally uses HTTP to transfer data, most of the 858 same security considerations apply. See section 15 of RFC 2616 859 [RFC2616]. 861 Media file parsers are typically subject to "fuzzing" attacks. 862 Clients SHOULD take care when parsing files received from a server so 863 that non-compliant files are rejected. 865 Playlist files contain URIs, which clients will use to make network 866 requests of arbitrary entities. Clients SHOULD range-check responses 867 to prevent buffer overflows. See also the Security Considerations 868 section of RFC 3986 [RFC3986]. 870 Clients SHOULD load resources identified by URI lazily to avoid 871 contributing to denial-of-service attacks. 873 HTTP requests often include session state ("cookies"), which may 874 contain private user data. Implementations MUST follow cookie 875 restriction and expiry rules specified by RFC 2965 [RFC2965]. See 876 also the Security Considerations section of RFC 2965, and RFC 2964 877 [RFC2964]. 879 Encryption keys are specified by URI. The delivery of these keys 880 SHOULD be secured by a mechanism such as HTTP over TLS [RFC5246] 881 (formerly SSL) in conjunction with a secure realm or a session 882 cookie. 884 12. References 886 12.1. Normative References 888 [AES_128] U.S. Department of Commerce/National Institute of 889 Standards and Technology, "Advanced Encryption Standard 890 (AES), FIPS PUB 197", November 2001, <http:// 891 csrc.nist.gov/publications/fips/fips197/fips-197.pdf>. 893 [ISO_13818] 894 International Organization for Standardization, "ISO/IEC 895 International Standard 13818; Generic coding of moving 896 pictures and associated audio information", October 2007, 897 <http://www.iso.org/iso/catalogue_detail?csnumber=44169>. 899 [ISO_8601] 900 International Organization for Standardization, "ISO/IEC 901 International Standard 8601:2004; Data elements and 902 interchange formats -- Information interchange -- 903 Representation of dates and times", December 2004, 904 <http://www.iso.org/iso/catalogue_detail?csnumber=40874>. 906 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 907 Extensions (MIME) Part Two: Media Types", RFC 2046, 908 November 1996. 910 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 911 Requirement Levels", BCP 14, RFC 2119, March 1997. 913 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 914 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 915 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 917 [RFC2964] Moore, K. and N. Freed, "Use of HTTP State Management", 918 BCP 44, RFC 2964, October 2000. 920 [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management 921 Mechanism", RFC 2965, October 2000. 923 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 924 10646", STD 63, RFC 3629, November 2003. 926 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 927 Resource Identifier (URI): Generic Syntax", STD 66, 928 RFC 3986, January 2005. 930 [RFC4281] Gellens, R., Singer, D., and P. Frojdh, "The Codecs 931 Parameter for "Bucket" Media Types", RFC 4281, 932 November 2005. 934 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 935 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 937 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 938 RFC 5652, September 2009. 940 [US_ASCII] 941 American National Standards Institute, "ANSI X3.4-1986, 942 Information Systems -- Coded Character Sets 7-Bit American 943 National Standard Code for Information Interchange (7-Bit 944 ASCII)", December 1986. 946 12.2. Informative References 948 [ID3] ID3.org, "The ID3 audio file data tagging format", 949 <http://www.id3.org/Developer_Information>. 951 [M3U] Nullsoft, Inc., "The M3U Playlist format, originally 952 invented for the Winamp media player", 953 <http://wikipedia.org/wiki/M3U>. 955 Authors' Addresses 957 Roger Pantos (editor) 958 Apple Inc. 959 Cupertino, California 960 United States 962 Email: http-live-streaming-review@group.apple.com 964 William May, Jr. 965 Apple Inc. 966 Cupertino, California 967 United States 969 Email: http-live-streaming-review@group.apple.com