idnits 2.17.1 draft-pantos-http-live-streaming-09.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 (September 22, 2012) is 4231 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 5246 (Obsoleted by RFC 8446) Summary: 2 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: March 26, 2013 September 22, 2012 7 HTTP Live Streaming 8 draft-pantos-http-live-streaming-09 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 5 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 March 26, 2013. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. 48 This Informational Internet Draft is submitted as an RFC Editor 49 Contribution and/or non-IETF Document (not as a Contribution, IETF 50 Contribution, nor IETF Document) in accordance with BCP 78 and BCP 51 79. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. The Playlist file . . . . . . . . . . . . . . . . . . . . . . 4 58 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.2. Attribute Lists . . . . . . . . . . . . . . . . . . . . . 5 60 3.3. Standard Tags . . . . . . . . . . . . . . . . . . . . . . 6 61 3.3.1. EXTM3U . . . . . . . . . . . . . . . . . . . . . . . . 6 62 3.3.2. EXTINF . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3.4. New Tags . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 3.4.1. EXT-X-BYTERANGE . . . . . . . . . . . . . . . . . . . 7 65 3.4.2. EXT-X-TARGETDURATION . . . . . . . . . . . . . . . . . 7 66 3.4.3. EXT-X-MEDIA-SEQUENCE . . . . . . . . . . . . . . . . . 8 67 3.4.4. EXT-X-KEY . . . . . . . . . . . . . . . . . . . . . . 8 68 3.4.5. EXT-X-PROGRAM-DATE-TIME . . . . . . . . . . . . . . . 10 69 3.4.6. EXT-X-ALLOW-CACHE . . . . . . . . . . . . . . . . . . 10 70 3.4.7. EXT-X-PLAYLIST-TYPE . . . . . . . . . . . . . . . . . 10 71 3.4.8. EXT-X-ENDLIST . . . . . . . . . . . . . . . . . . . . 11 72 3.4.9. EXT-X-MEDIA . . . . . . . . . . . . . . . . . . . . . 11 73 3.4.9.1. Rendition Groups . . . . . . . . . . . . . . . . . 13 74 3.4.10. EXT-X-STREAM-INF . . . . . . . . . . . . . . . . . . . 14 75 3.4.10.1. Alternative Renditions . . . . . . . . . . . . . . 15 76 3.4.11. EXT-X-DISCONTINUITY . . . . . . . . . . . . . . . . . 16 77 3.4.12. EXT-X-I-FRAMES-ONLY . . . . . . . . . . . . . . . . . 16 78 3.4.13. EXT-X-MAP . . . . . . . . . . . . . . . . . . . . . . 17 79 3.4.14. EXT-X-I-FRAME-STREAM-INF . . . . . . . . . . . . . . . 17 80 3.4.15. EXT-X-VERSION . . . . . . . . . . . . . . . . . . . . 18 81 4. Media segments . . . . . . . . . . . . . . . . . . . . . . . . 19 82 5. Key files . . . . . . . . . . . . . . . . . . . . . . . . . . 20 83 5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 20 84 5.2. IV for [AES_128] . . . . . . . . . . . . . . . . . . . . . 20 85 6. Client/Server Actions . . . . . . . . . . . . . . . . . . . . 20 86 6.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 20 87 6.2. Server Process . . . . . . . . . . . . . . . . . . . . . . 21 88 6.2.1. Introduction . . . . . . . . . . . . . . . . . . . . . 21 89 6.2.2. Sliding Window Playlists . . . . . . . . . . . . . . . 23 90 6.2.3. Encrypting media segments . . . . . . . . . . . . . . 23 91 6.2.4. Providing variant streams . . . . . . . . . . . . . . 24 92 6.3. Client Process . . . . . . . . . . . . . . . . . . . . . . 25 93 6.3.1. Introduction . . . . . . . . . . . . . . . . . . . . . 25 94 6.3.2. Loading the Playlist file . . . . . . . . . . . . . . 25 95 6.3.3. Playing the Playlist file . . . . . . . . . . . . . . 26 96 6.3.4. Reloading the Playlist file . . . . . . . . . . . . . 26 97 6.3.5. Determining the next segment to load . . . . . . . . . 27 98 6.3.6. Decrypting encrypted media segments . . . . . . . . . 28 99 7. Protocol version compatibility . . . . . . . . . . . . . . . . 28 100 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 101 8.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 29 102 8.2. Simple Playlist file . . . . . . . . . . . . . . . . . . . 29 103 8.3. Sliding Window Playlist, using HTTPS . . . . . . . . . . . 30 104 8.4. Playlist file with encrypted media segments . . . . . . . 30 105 8.5. Variant Playlist file . . . . . . . . . . . . . . . . . . 30 106 8.6. Variant Playlist with I-Frames . . . . . . . . . . . . . . 31 107 8.7. Variant Playlist with Alternative audio . . . . . . . . . 31 108 8.8. Variant Playlist with Alternative video . . . . . . . . . 31 109 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 32 110 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 111 11. Security Considerations . . . . . . . . . . . . . . . . . . . 33 112 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 113 12.1. Normative References . . . . . . . . . . . . . . . . . . . 34 114 12.2. Informative References . . . . . . . . . . . . . . . . . . 36 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 117 1. Introduction 119 This document describes a protocol for transferring unbounded streams 120 of multimedia data. The protocol supports the encryption of media 121 data and the provision of alternate versions (e.g. bitrates) of a 122 stream. Media data can be transferred soon after it is created, 123 allowing it to be played in near real-time. Data is usually carried 124 over HTTP [RFC2616]. 126 External references that describe related standards such as HTTP are 127 listed in Section 11. 129 2. Summary 131 A multimedia presentation is specified by a URI [RFC3986] to a 132 Playlist file, which is an ordered list of media URIs and 133 informational tags. The URIs and their associated tags specify a 134 series of media segments. 136 To play the stream, the client first obtains the Playlist file and 137 then obtains and plays each media segment in the Playlist. It 138 reloads the Playlist file as described in this document to discover 139 additional segments. 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in RFC 2119 [RFC2119]. 145 3. The Playlist file 147 3.1. Introduction 149 Playlists MUST be Extended M3U Playlist files [M3U]. This document 150 extends the M3U file format further by defining additional tags. 152 An M3U Playlist is a text file that consists of individual lines. 153 Lines are terminated by either a single LF character or a CR 154 character followed by an LF character. Each line is a URI, blank, or 155 starts with the character '#'. Blank lines are ignored. White space 156 MUST NOT be present, except for elements in which it is explicitly 157 specified. 159 A URI line identifies a media segment or a variant Playlist file (see 160 Section 3.4.10). Each media segment is specified by a media URI and 161 the tags that apply to it. 163 Lines that start with the character '#' are either comments or tags. 165 Tags begin with #EXT. All other lines that begin with '#' are 166 comments and SHOULD be ignored. 168 A URI in a Playlist, whether it is a URI line or part of a tag, MAY 169 be relative. Relative URIs MUST be resolved against the URI of the 170 Playlist file that contains it. 172 The duration of a Playlist file is the sum of the durations of the 173 media segments within it. 175 Playlist files whose names end in .m3u8 and/or have the HTTP Content- 176 Type "application/vnd.apple.mpegurl" are encoded in UTF-8 [RFC3629]. 177 Files whose names end with .m3u and/or have the HTTP Content-Type 178 [RFC2616] "audio/mpegurl" are encoded in US-ASCII [US_ASCII]. 180 Playlist files MUST have names that end in .m3u8 and/or have the 181 Content-Type "application/vnd.apple.mpegurl" (if transferred over 182 HTTP), or have names that end in .m3u and/or have the HTTP Content- 183 Type type "audio/mpegurl" (for compatibility). 185 3.2. Attribute Lists 187 Certain extended M3U tags have values which are Attribute Lists. An 188 Attribute List is a comma-separated list of attribute/value pairs 189 with no whitespace. 191 An attribute/value pair has the following syntax: 193 AttributeName=AttributeValue 195 An AttributeName is an unquoted string containing characters from the 196 set [A..Z] and '-'. 198 An AttributeValue is one of the following: 200 o decimal-integer: an unquoted string of characters from the set 201 [0..9] expressing an integer in base-10 arithmetic. 203 o hexadecimal-integer: an unquoted string of characters from the set 204 [0..9] and [A..F] that is prefixed with 0x or 0X and which 205 expresses an integer in base-16 arithmetic. 207 o decimal-floating-point: an unquoted string of characters from the 208 set [0..9] and '.' which expresses a floating-point number in 209 decimal positional notation. 211 o quoted-string: a string of characters within a pair of double- 212 quotes ("), including Uniform Type Identifiers [UTI]. The set of 213 characters allowed in the string and any rules for escaping 214 special characters are specified by the Attribute definition, but 215 any double-quote (") character and any carriage-return or linefeed 216 will always be replaced by an escape sequence. 218 o enumerated-string: an unquoted character string from a set which 219 is explicitly defined by the Attribute. An enumerated-string will 220 never contain double-quotes ("), commas (,), or whitespace. 222 o decimal-resolution: two decimal-integers separated by the "x" 223 character. The first integer is a horizontal pixel dimension 224 (width); the second is a vertical pixel dimension (height). 226 The type of the AttributeValue for a given AttributeName is specified 227 by the Attribute definition. 229 A given AttributeName MUST NOT appear more than once in a given 230 Attribute List. 232 An Attribute/value pair with an unrecognized AttributeName MUST be 233 ignored by the client. 235 Any tag containing an attribute/value pair of type enumerated-string 236 whose AttributeName is recognized but whose AttributeValue is not 237 recognized MUST be ignored by the client. 239 3.3. Standard Tags 241 3.3.1. EXTM3U 243 An Extended M3U file is distinguished from a basic M3U file by its 244 first line, which MUST be the tag #EXTM3U. 246 3.3.2. EXTINF 248 The EXTINF tag specifies the duration of a media segment. It applies 249 only to the media segment that follows it. Each media segment MUST 250 be preceded by an EXTINF tag. Its format is: 252 #EXTINF:, 254 "duration" is an integer or floating-point number in decimal 255 positional notation that specifies the duration of the media segment 256 in seconds. Durations that are reported as integers SHOULD be 257 rounded to the nearest integer. Durations MUST be integers if the 258 protocol version of the Playlist file is less than 3. The remainder 259 of the line following the comma is an optional human-readable 260 informative title of the media segment. 262 3.4. New Tags 264 This document defines the following new tags: EXT-X-BYTERANGE, EXT-X- 265 TARGETDURATION, EXT-X-MEDIA-SEQUENCE, EXT-X-KEY, EXT-X-PROGRAM-DATE- 266 TIME, EXT-X-ALLOW-CACHE, EXT-X-PLAYLIST-TYPE, EXT-X-STREAM-INF, EXT- 267 X-I-FRAME-STREAM-INF, EXT-X-I-FRAMES-ONLY, EXT-X-MEDIA, EXT-X- 268 ENDLIST, EXT-X-DISCONTINUITY, and EXT-X-VERSION. 270 3.4.1. EXT-X-BYTERANGE 272 The EXT-X-BYTERANGE tag indicates that a media segment is a sub-range 273 of the resource identified by its media URI. It applies only to the 274 next media URI that follows it in the Playlist. Its format is: 276 #EXT-X-BYTERANGE:<n>[@o] 278 where n is a decimal-integer indicating the length of the sub-range 279 in bytes. If present, o is a decimal-integer indicating the start of 280 the sub-range, as a byte offset from the beginning of the resource. 281 If o is not present, the sub-range begins at the next byte following 282 the sub-range of the previous media segment. 284 If o is not present, a previous media segment MUST appear in the 285 Playlist file and MUST be a sub-range of the same media resource. 287 A media URI with no EXT-X-BYTERANGE tag applied to it specifies a 288 media segment that consists of the entire resource. 290 The EXT-X-BYTERANGE tag appeared in version 4 of the protocol. 292 3.4.2. EXT-X-TARGETDURATION 294 The EXT-X-TARGETDURATION tag specifies the maximum media segment 295 duration. The EXTINF duration of each media segment in the Playlist 296 file MUST be less than or equal to the target duration. This tag 297 MUST appear once in the Playlist file. It applies to the entire 298 Playlist file. Its format is: 300 #EXT-X-TARGETDURATION:<s> 302 where s is an integer indicating the target duration in seconds. 304 3.4.3. EXT-X-MEDIA-SEQUENCE 306 Each media segment in a Playlist has a unique integer sequence 307 number. The sequence number of a segment is equal to the sequence 308 number of the segment that preceded it plus one. The EXT-X-MEDIA- 309 SEQUENCE tag indicates the sequence number of the first segment that 310 appears in a Playlist file. Its format is: 312 #EXT-X-MEDIA-SEQUENCE:<number> 314 A Playlist file MUST NOT contain more than one EXT-X-MEDIA-SEQUENCE 315 tag. If the Playlist file does not contain an EXT-X-MEDIA-SEQUENCE 316 tag then the sequence number of the first segment in the playlist 317 SHALL be considered to be 0. A client MUST NOT assume that segments 318 with the same sequence number in different variants or renditions 319 contain matching content. 321 A media URI is not required to contain its sequence number. 323 See Section 6.3.2 and Section 6.3.5 for information on handling the 324 EXT-X-MEDIA-SEQUENCE tag. 326 3.4.4. EXT-X-KEY 328 Media segments MAY be encrypted. The EXT-X-KEY tag specifies how to 329 decrypt them. It applies to every media segment that appears between 330 it and the next EXT-X-KEY tag in the Playlist file with the same 331 KEYFORMAT attribute (or the end of the Playlist file). Two or more 332 EXT-X-KEY tags with different KEYFORMAT attributes MAY apply to the 333 same media segment, in which case they MUST resolve to the same key. 334 Its format is: 336 #EXT-X-KEY:<attribute-list> 338 The following attributes are defined: 340 METHOD 342 The value is an enumerated-string that specifies the encryption 343 method. This attribute is mandatory. 345 The methods defined are: NONE, AES-128, and SAMPLE-AES. 347 An encryption method of NONE means that media segments are not 348 encrypted. If the encryption method is NONE, the following 349 attributes MUST NOT be present: URI; IV; KEYFORMAT; 350 KEYFORMATVERSIONS. 352 An encryption method of AES-128 means that media segments are 353 completely encrypted using the Advanced Encryption Standard [AES_128] 354 with a 128-bit key and PKCS7 padding [RFC5652]. If the encryption 355 method is AES-128, the URI attribute MUST be present. The IV 356 attribute MAY be present; see Section 5.2. 358 An encryption method of SAMPLE-AES means that the media segments 359 contain elementary streams of audio, video, or other samples that are 360 encrypted using the Advanced Encryption Standard [AES_128]. How an 361 elementary stream is encrypted depends on the media encoding. The 362 encryption format for H.264 [H_264], AAC [ISO_14496] and AC-3 [AC_3] 363 elementary streams is described by [SampleEnc]. The IV attribute MAY 364 be present; see Section 5.2. 366 URI 368 The value is a quoted-string containing a URI [RFC3986] that 369 specifies how to obtain the key. This attribute is mandatory unless 370 the METHOD is NONE. 372 IV 374 The value is a hexadecimal-integer that specifies the Initialization 375 Vector to be used with the key. The IV attribute appeared in 376 protocol version 2. 378 KEYFORMAT 380 The value is a quoted-string that specifies how the key is 381 represented in the resource identified by the URI; see Section 5 for 382 more detail. This attribute is optional; its absence indicates, an 383 implicit value of "identity". The KEYFORMAT attribute appeared in 384 protocol version 5. 386 KEYFORMATVERSIONS 388 The value is a quoted-string containing one or more positive integers 389 separated by the "/" character (for example, "1/3"). If more than 390 one version of a particular KEYFORMAT is defined, this attribute can 391 be used to indicate which version(s) this instance complies with. 392 This attribute is optional; if it is not present, its value is 393 considered to be "1". The KEYFORMATVERSIONS attribute appeared in 394 protocol version 5. 396 If the Playlist file does not contain an EXT-X-KEY tag then media 397 segments are not encrypted. 399 See Section 5 for the format of the key file, and Section 5.2, 400 Section 6.2.3 and Section 6.3.6 for additional information on media 401 segment encryption. 403 3.4.5. EXT-X-PROGRAM-DATE-TIME 405 The EXT-X-PROGRAM-DATE-TIME tag associates the first sample of a 406 media segment with an absolute date and/or time. It applies only to 407 the next media segment. 409 The date/time representation is ISO/IEC 8601:2004 [ISO_8601] and 410 SHOULD indicate a time zone: 412 #EXT-X-PROGRAM-DATE-TIME:<YYYY-MM-DDThh:mm:ssZ> 414 For example: 416 #EXT-X-PROGRAM-DATE-TIME:2010-02-19T14:54:23.031+08:00 418 See Section 6.2.1 and Section 6.3.3 for more information on the EXT- 419 X-PROGRAM-DATE-TIME tag. 421 3.4.6. EXT-X-ALLOW-CACHE 423 The EXT-X-ALLOW-CACHE tag indicates whether the client MAY or MUST 424 NOT cache downloaded media segments for later replay. It MAY occur 425 anywhere in the Playlist file; it MUST NOT occur more than once. The 426 EXT-X-ALLOW-CACHE tag applies to all segments in the playlist. Its 427 format is: 429 #EXT-X-ALLOW-CACHE:<YES|NO> 431 See Section 6.3.3 for more information on the EXT-X-ALLOW-CACHE tag. 433 3.4.7. EXT-X-PLAYLIST-TYPE 435 The EXT-X-PLAYLIST-TYPE tag provides mutability information about the 436 Playlist file. It applies to the entire Playlist file. It is 437 optional. Its format is: 439 #EXT-X-PLAYLIST-TYPE:<EVENT|VOD> 441 Section 6.2.1 defines the implications of the EXT-X-PLAYLIST-TYPE 442 tag. 444 3.4.8. EXT-X-ENDLIST 446 The EXT-X-ENDLIST tag indicates that no more media segments will be 447 added to the Playlist file. It MAY occur anywhere in the Playlist 448 file; it MUST NOT occur more than once. Its format is: 450 #EXT-X-ENDLIST 452 3.4.9. EXT-X-MEDIA 454 The EXT-X-MEDIA tag is used to relate Playlists that contain 455 alternative renditions of the same content. For example, three EXT- 456 X-MEDIA tags can be used to identify audio-only Playlists that 457 contain English, French and Spanish renditions of the same 458 presentation. Or two EXT-X-MEDIA tags can be used to identify video- 459 only Playlists that show two different camera angles. 461 The EXT-X-MEDIA tag stands alone, in that it does not apply to a 462 particular URI in the Playlist. Its format is: 464 #EXT-X-MEDIA:<attribute-list> 466 The following attributes are defined: 468 URI 470 The value is a quoted-string containing a URI that identifies the 471 Playlist file. This attribute is optional; see Section 3.4.10.1. 473 TYPE 475 The value is enumerated-string; valid strings are AUDIO, VIDEO and 476 SUBTITLES. If the value is AUDIO, the Playlist described by the tag 477 MUST contain audio media. If the value is VIDEO, the Playlist MUST 478 contain video media. If the value is SUBTITLES, the Playlist MUST 479 contain subtitle media. 481 GROUP-ID 483 The value is a quoted-string identifying a mutually-exclusive group 484 of renditions. The presence of this attribute signals membership in 485 the group. See Section 3.4.9.1. 487 LANGUAGE 489 The value is a quoted-string containing an RFC 5646 [RFC5646] 490 language tag that identifies the primary language used in the 491 rendition. This attribute is optional. 493 NAME 495 The value is a quoted-string containing a human-readable description 496 of the rendition. If the LANGUAGE attribute is present then this 497 description SHOULD be in that language. 499 DEFAULT 501 The value is an enumerated-string; valid strings are YES and NO. If 502 the value is YES, then the client SHOULD play this rendition of the 503 content in the absence of information from the user indicating a 504 different choice. This attribute is optional. Its absence indicates 505 an implicit value of NO. 507 AUTOSELECT 509 The value is an enumerated-string; valid strings are YES and NO. 510 This attribute is optional. Its absence indicates an implicit value 511 of NO. If the value is YES, then the client MAY choose to play this 512 rendition in the absence of explicit user preference because it 513 matches the current playback environment, such as chosen system 514 language. 516 FORCED 518 The value is an enumerated-string; valid strings are YES and NO. 519 This attribute is optional. Its absence indicates an implicit value 520 of NO. The FORCED attribute MUST NOT be present unless the TYPE is 521 SUBTITLES. 523 A value of YES indicates that the rendition contains content which is 524 considered essential to play. When selecting a FORCED rendition, a 525 client should choose the one that best matches the current playback 526 environment (e.g. language). 528 A value of NO indicates that the rendition contains content which is 529 intended to be played in response to explicit user request. 531 CHARACTERISTICS 533 The value is a quoted-string containing one or more Uniform Type 534 Identifiers [UTI] separated by comma (,) characters. This attribute 535 is optional. Each UTI indicates an individual characteristic of the 536 rendition. 538 A SUBTITLES rendition MAY include the following characteristics: 539 "public.accessibility.transcribes-spoken-dialog"; 540 "public.accessibility.describes-music-and-sound"; "public.easy-to- 541 read" (which indicates that the subtitles have been edited for ease 542 of reading). 544 An AUDIO rendition MAY include the following characteristics: 545 "public.accessibility.describes-video". 547 The CHARACTERISTICS attribute MAY include private UTIs. 549 The EXT-X-MEDIA tag appeared in version 4 of the protocol. 551 3.4.9.1. Rendition Groups 553 A set of EXT-X-MEDIA tags with the same GROUP-ID value forms a group 554 of renditions. Each member of the group MUST represent an 555 alternative rendition of the same content. 557 All EXT-X-MEDIA tags in a Playlist MUST meet the following 558 constraints: 560 o All EXT-X-MEDIA tags in the same group MUST have the same TYPE 561 attribute. 563 o All EXT-X-MEDIA tags in the same group MUST have different NAME 564 attributes. 566 o A group MUST NOT have more than one member with a DEFAULT 567 attribute of YES. 569 o All members of a group whose AUTOSELECT attribute has a value of 570 YES MUST have LANGUAGE [RFC5646] attributes with unique values. 572 o All members of a group with TYPE=AUDIO MUST use the same audio 573 sample format. 575 o All members of a group with TYPE=VIDEO MUST use the same video 576 sample format. 578 A Playlist MAY contain multiple groups of the same TYPE in order to 579 provide multiple encodings of each rendition. If it does so, each 580 group of the same TYPE SHOULD contain corresponding members with the 581 same NAME attribute, LANGUAGE attribute, and rendition. 583 3.4.10. EXT-X-STREAM-INF 585 The EXT-X-STREAM-INF tag identifies a media URI as a Playlist file 586 containing a multimedia presentation and provides information about 587 that presentation. It applies only to the URI that follows it. Its 588 format is: 590 #EXT-X-STREAM-INF:<attribute-list> 591 <URI> 593 The following attributes are defined: 595 BANDWIDTH 597 The value is a decimal-integer of bits per second. It MUST be an 598 upper bound of the overall bitrate of each media segment (calculated 599 to include container overhead) that appears or will appear in the 600 Playlist. 602 Every EXT-X-STREAM-INF tag MUST include the BANDWIDTH attribute. 604 PROGRAM-ID 606 The value is a decimal-integer that uniquely identifies a particular 607 presentation within the scope of the Playlist file. 609 A Playlist file MAY contain multiple EXT-X-STREAM-INF tags with the 610 same PROGRAM-ID to identify different encodings of the same 611 presentation. These variant playlists MAY contain additional EXT-X- 612 STREAM-INF tags. 614 CODECS 616 The value is a quoted-string containing a comma-separated list of 617 formats, where each format specifies a media sample type that is 618 present in a media segment in the Playlist file. Valid format 619 identifiers are those in the ISO File Format Name Space defined by 620 RFC 6381 [RFC6381]. 622 Every EXT-X-STREAM-INF tag SHOULD include a CODECS attribute. 624 RESOLUTION 626 The value is a decimal-resolution describing the approximate encoded 627 horizontal and vertical resolution of video within the presentation. 629 AUDIO 631 The value is a quoted-string. It MUST match the value of the 632 GROUP-ID attribute of an EXT-X-MEDIA tag elsewhere in the Playlist 633 whose TYPE attribute is AUDIO. It indicates the set of audio 634 renditions that MAY be used when playing the presentation. See 635 Section 3.4.10.1. 637 VIDEO 639 The value is a quoted-string. It MUST match the value of the 640 GROUP-ID attribute of an EXT-X-MEDIA tag elsewhere in the Playlist 641 whose TYPE attribute is VIDEO. It indicates the set of video 642 renditions that MAY be used when playing the presentation. See 643 Section 3.4.10.1. 645 SUBTITLES 647 The value is a quoted-string. It MUST match the value of the 648 GROUP-ID attribute of an EXT-X-MEDIA tag elsewhere in the Playlist 649 whose TYPE attribute is SUBTITLES. It indicates the set of subtitle 650 renditions that MAY be used when playing the presentation. See 651 Section 3.4.10.1. 653 3.4.10.1. Alternative Renditions 655 When an EXT-X-STREAM-INF tag contains an AUDIO, VIDEO, or SUBTITLE 656 attribute, it indicates that alternative renditions of the content 657 are available for playback of that variant. 659 When defining alternative renditions, the following constraints MUST 660 be met: 662 o All playable combinations of renditions associated with an EXT-X- 663 STREAM-INF tag MUST have an aggregate bandwidth less than or equal 664 to the BANDWIDTH attribute of the EXT-X-STREAM-INF tag. 666 o If an EXT-X-STREAM-INF tag contains a RESOLUTION attribute and a 667 VIDEO attribute, then every alternative video rendition MUST match 668 the value of the RESOLUTION attribute. 670 o Every alternative rendition associated with an EXT-X-STREAM-INF 671 tag MUST meet the constraints for a variant stream described in 672 Section 6.2.4. 674 The URI attribute of an EXT-X-MEDIA tag is optional. If it is 675 missing, it indicates that the rendition described by the EXT-X-MEDIA 676 tag is present in the main Playlist described by the EXT-X-STREAM-INF 677 tag. 679 Note that if a client chooses to play renditions of audio and video 680 that are not present in the main Playlist described by the EXT-X- 681 STREAM-INF tag, or if the client chooses to play an audio rendition 682 and the main Playlist is audio-only, then the client MAY ignore the 683 main Playlist and its media. 685 3.4.11. EXT-X-DISCONTINUITY 687 The EXT-X-DISCONTINUITY tag indicates an encoding discontinuity 688 between the media segment that follows it and the one that preceded 689 it. The set of characteristics that MAY change is: 691 o file format 693 o number and type of tracks 695 o encoding parameters 697 o encoding sequence 699 o timestamp sequence 701 Its format is: 703 #EXT-X-DISCONTINUITY 705 See Section 4, Section 6.2.1, and Section 6.3.3 for more information 706 about the EXT-X-DISCONTINUITY tag. 708 3.4.12. EXT-X-I-FRAMES-ONLY 710 The EXT-X-I-FRAMES-ONLY tag indicates that each media segment in the 711 Playlist describes a single I-frame. I-frames (or Intra frames) are 712 encoded video frames whose encoding does not depend on any other 713 frame. 715 The EXT-X-I-FRAMES-ONLY tag applies to the entire Playlist. Its 716 format is: 718 #EXT-X-I-FRAMES-ONLY 720 In a Playlist with the EXT-X-I-FRAMES-ONLY tag, the media segment 721 duration (EXTINF tag value) is the time between the presentation time 722 of the I-frame in the media segment and the presentation time of the 723 next I-frame in the Playlist, or the end of the presentation if it is 724 the last I-frame in the Playlist. 726 Media resources containing I-frame segments MUST begin with either a 727 Transport Stream PAT/PMT or be accompanied by an EXT-X-MAP tag 728 indicating the proper PAT/PMT. The byte range of an I-frame segment 729 with an EXT-X-BYTERANGE tag applied to it (Section 3.4.1) MUST NOT 730 include a PAT/PMT. 732 The EXT-X-I-FRAMES-ONLY tag appeared in version 4 of the protocol. 734 3.4.13. EXT-X-MAP 736 The EXT-X-MAP tag specifies how to obtain the Transport Stream PAT/ 737 PMT for the applicable media segment. It applies to every media 738 segment that appears after it in the Playlist until the next EXT-X- 739 DISCONTINUITY tag, or until the end of the playlist. 741 The EXT-X-MAP tag MUST NOT appear unless the Playlist also contains 742 the EXT-X-I-FRAMES-ONLY tag. It is RECOMMENDED that the EXT-X-MAP 743 tag only be used for segments whose resource does not start with a 744 PAT/PMT. 746 Its format is: 748 #EXT-X-MAP:<attribute-list> 750 The following attributes are defined: 752 URI 754 The value is a quoted-string containing a URI that identifies a 755 resource that contains the Transport Stream PAT/PMT. This attribute 756 is mandatory. 758 BYTERANGE 760 The value is a quoted-string specifying a byte range into the 761 resource identified by the URI attribute. This range SHOULD contain 762 only the Transport Stream PAT/PMT. The format of the byte range is 763 described in Section 3.4.1. This attribute is optional; if it is not 764 present, the byte range is the entire resource indicated by the URI. 766 The EXT-X-MAP tag appeared in version 5 of the protocol. 768 3.4.14. EXT-X-I-FRAME-STREAM-INF 770 The EXT-X-I-FRAME-STREAM-INF tag identifies a Playlist file 771 containing the I-frames of a multimedia presentation. It stands 772 alone, in that it does not apply to a particular URI in the Playlist. 773 Its format is: 775 #EXT-X-I-FRAME-STREAM-INF:<attribute-list> 777 All attributes defined for the EXT-X-STREAM-INF tag (Section 3.4.10) 778 are also defined for the EXT-X-I-FRAME-STREAM-INF tag, except for the 779 AUDIO and SUBTITLES attributes. In addition, the following attribute 780 is defined: 782 URI 784 The value is a quoted-string containing a URI that identifies the 785 I-frame Playlist file. 787 Every EXT-X-I-FRAME-STREAM-INF tag MUST include a BANDWIDTH attribute 788 and a URI attribute. 790 The provisions in Section 3.4.10.1 also apply to EXT-X-I-FRAME- 791 STREAM-INF tags with a VIDEO attribute. 793 A Playlist that specifies alternative VIDEO renditions and I-frame 794 Playlists SHOULD include an alternative I-frame VIDEO rendition for 795 each regular VIDEO rendition, with the same NAME and LANGUAGE 796 attributes. 798 The EXT-X-I-FRAME-STREAM-INF tag appeared in version 4 of the 799 protocol. Clients that do not implement protocol version 4 or higher 800 MUST ignore it. 802 3.4.15. EXT-X-VERSION 804 The EXT-X-VERSION tag indicates the compatibility version of the 805 Playlist file. The Playlist file, its associated media, and its 806 server MUST comply with all provisions of the most-recent version of 807 this document describing the protocol version indicated by the tag 808 value. 810 The EXT-X-VERSION tag applies to the entire Playlist file. Its 811 format is: 813 #EXT-X-VERSION:<n> 815 where n is an integer indicating the protocol version. 817 A Playlist file MUST NOT contain more than one EXT-X-VERSION tag. A 818 Playlist file that does not contain an EXT-X-VERSION tag MUST comply 819 with version 1 of this protocol. 821 4. Media segments 823 Each media URI in a Playlist file specifies a media segment which is 824 part of the overall presentation. If a media URI has an EXT-X- 825 BYTERANGE tag applied to it, the segment is a sub-range of the media 826 file identified by the URI. Otherwise, the segment is the entire 827 media file. 829 Each media segment MUST be formatted as an MPEG-2 Transport Stream 830 [ISO_13818], an MPEG audio elementary stream [ISO_11172], or a WebVTT 831 [WebVTT] file. 833 Transport Stream segments MUST contain a single MPEG-2 Program. 834 There SHOULD be a Program Association Table (PAT) and a Program Map 835 Table (PMT) at the start of each segment. A segment that contains 836 video SHOULD have at least one key frame and enough information to 837 completely initialize a video decoder. 839 A Transport Stream or audio elementary stream segment MUST be the 840 continuation of the encoded media at the end of the segment with the 841 previous sequence number, where values in a continuous series, such 842 as timestamps and Continuity Counters, continue uninterrupted - 843 unless the media segment was the first ever to appear in the Playlist 844 file or has an EXT-X-DISCONTINUITY tag applied to it. 846 Clients SHOULD be prepared to handle multiple tracks of a particular 847 type (e.g. audio or video). A client with no other preference SHOULD 848 choose the track with the lowest numerical PID that it can play. 850 Clients MUST ignore private streams inside Transport Streams that 851 they do not recognize. 853 The encoding parameters for samples in a stream inside a media 854 segment and between corresponding streams across multiple media 855 segments SHOULD remain consistent. However clients SHOULD deal with 856 encoding changes as they are encountered, for example by scaling 857 video content to accommodate a resolution change. 859 Subtitle segments MUST be formatted as WebVTT [WebVTT] files. Each 860 subtitle segment MUST contain all subtitle cues that are intended to 861 be displayed during the period indicated by the segment EXTINF 862 duration. The start time offset and end time offset of each cue MUST 863 indicate the total display time for that cue, even if that time range 864 extends beyond the EXTINF duration. A WebVTT segment MAY contain no 865 cues; this indicates that no subtitles are to be displayed during 866 that period. 868 Each WebVTT segment MUST have an X-TIMESTAMP-MAP metadata header. 870 This header synchronizes the cue timestamps in the WebVTT file with 871 the MPEG-2 (PES) timestamps in other streams. Its format is: 873 X-TIMESTAMP-MAP:LOCAL=<cue time>,MPEGTS=<MPEG-2 time> 874 e.g. X-TIMESTAMP-MAP:LOCAL=00:00:00.000,MPEGTS=900000 876 The cue timestamp in the X-TIMESTAMP-MAP header need not appear in 877 the WebVTT segment. 879 5. Key files 881 5.1. Introduction 883 An EXT-X-KEY tag with a URI attribute identifies a Key file. A Key 884 file contains the cipher key that MUST be used to decrypt subsequent 885 media segments in the Playlist. 887 [AES_128] encryption uses 16-octet keys. If the KEYFORMAT of an EXT- 888 X-KEY tag is "identity", the Key file is a single packed array of 16 889 octets in binary format. 891 5.2. IV for [AES_128] 893 [AES_128] requires the same 16-octet Initialization Vector (IV) to be 894 supplied when encrypting and decrypting. Varying this IV increases 895 the strength of the cipher. 897 If an EXT-X-KEY tag has a KEYFORMAT of "identity" and an IV attribute 898 is present, implementations MUST use the attribute value as the IV 899 when encrypting or decrypting with that key. The value MUST be 900 interpreted as a 128-bit number. 902 If an EXT-X-KEY tag with a KEYFORMAT of "identity" does not have the 903 IV attribute, implementations MUST use the sequence number of the 904 media segment as the IV when encrypting or decrypting that media 905 segment. The big-endian binary representation of the sequence number 906 SHALL be placed in a 16-octet buffer and padded (on the left) with 907 zeros. 909 6. Client/Server Actions 911 6.1. Introduction 913 This section describes how the server generates the Playlist and 914 media segments and how the client should download and play them. 916 6.2. Server Process 918 6.2.1. Introduction 920 The production of the media stream is outside the scope of this 921 document, which simply presumes a source of a continuous stream 922 containing the presentation. 924 The server MUST divide the stream into individual media segments 925 whose duration is less than or equal to a constant target duration. 926 The server SHOULD attempt to divide the stream at points that support 927 effective decode of individual media segments, e.g. on packet and key 928 frame boundaries. 930 The server MUST create a URI for every media segment that enables its 931 clients to obtain the segment data. If a server supports partial 932 loading of resources (e.g. via HTTP Range requests), it MAY specify 933 segments as sub-ranges of larger resources using the EXT-X-BYTERANGE 934 tag. 936 If WebVTT segments are distributed by HTTP, the server SHOULD support 937 client requests to use the "gzip" Content-Encoding. 939 The server MUST create a Playlist file. The Playlist file MUST 940 conform to the format described in Section 3. A URI for each media 941 segment that the server wishes to make available MUST appear in the 942 Playlist in the order in which it is to be played. The entire media 943 segment MUST be available to clients if its URI is in the Playlist 944 file. 946 The Playlist file MUST contain an EXT-X-TARGETDURATION tag. Its 947 value MUST be equal to or greater than the EXTINF value of any media 948 segment that appears or will appear in the Playlist file. Its value 949 MUST NOT change. A typical target duration is 10 seconds. 951 The Playlist file SHOULD contain one EXT-X-VERSION tag which 952 indicates the compatibility version of the stream. Its value MUST be 953 the lowest protocol version with which the server, Playlist file, and 954 associated media segments all comply. Its value MUST NOT change. 956 The server MUST create a URI for the Playlist file that will allow 957 its clients to obtain the file. 959 If the Playlist file is distributed by HTTP, the server SHOULD 960 support client requests to use "gzip" Content-Encoding. 962 Changes to the Playlist file MUST be made atomically from the point 963 of view of the clients. 965 The server MUST NOT change the Playlist file, except to: 967 Append lines to it (Section 6.2.1). 969 Remove media segment URIs from the Playlist in the order that they 970 appear, along with any tags that apply only to those segments 971 (Section 6.2.2). 973 Increment the value of the EXT-X-MEDIA-SEQUENCE tag 974 (Section 6.2.2). 976 Add or remove EXT-X-STREAM-INF tags or EXT-X-I-FRAME-STREAM-INF 977 tags (Section 6.2.4). Note that clients are not required to 978 reload variant Playlist files, so changing them may not have 979 immediate effect. 981 Add an EXT-X-ENDLIST tag to the Playlist (Section 6.2.1). 983 Furthermore, the Playlist file MAY contain an EXT-X-PLAYLIST-TYPE tag 984 with a value of either EVENT or VOD. If the tag is present and has a 985 value of EVENT, the server MUST NOT change or delete any part of the 986 Playlist file (although it MAY append lines to it). If the tag is 987 present and has a value of VOD, the Playlist file MUST NOT change. 989 Every media segment in a Playlist MUST have an EXTINF tag applied to 990 it indicating the duration of the media segment. 992 The server MAY associate an absolute date and time with a media 993 segment by applying an EXT-X-PROGRAM-DATE-TIME tag to the segment. 994 The date and time value provides an informative mapping of the 995 timeline of the media to an appropriate wall-clock time, which may be 996 used as a basis for seeking, for display, or for other purposes. If 997 a server provides this mapping, it SHOULD apply an EXT-X-PROGRAM- 998 DATE-TIME tag to every segment that has an EXT-X-DISCONTINUITY tag 999 applied to it. 1001 If the Playlist contains the final media segment of the presentation 1002 then the Playlist file MUST contain the EXT-X-ENDLIST tag. 1004 If the Playlist does not contain the EXT-X-ENDLIST tag, the server 1005 MUST make a new version of the Playlist file available that contains 1006 at least one new media segment. It MUST be made available relative 1007 to the time that the previous version of the Playlist file was made 1008 available: no earlier than one-half the target duration after that 1009 time, and no later than 1.5 times the target duration after that 1010 time. 1012 If the server wishes to remove an entire presentation, it MUST make 1013 the Playlist file unavailable to clients. It SHOULD ensure that all 1014 media segments in the Playlist file remain available to clients for 1015 at least the duration of the Playlist file at the time of removal. 1017 6.2.2. Sliding Window Playlists 1019 The server MAY limit the availability of media segments by removing 1020 media segments from the Playlist file (Section 6.2.1). If media 1021 segments are to be removed, the Playlist file MUST contain exactly 1022 one EXT-X-MEDIA-SEQUENCE tag. Its value MUST be incremented by 1 for 1023 every media segment that is removed from the Playlist file. 1025 Media segments MUST be removed from the Playlist file in the order 1026 that they appear in the Playlist. 1028 The server MUST NOT remove a media segment from the Playlist file if 1029 the duration of the Playlist file minus the duration of the segment 1030 is less than three times the target duration. 1032 When the server removes a media segment from the Playlist, the 1033 corresponding media URI SHOULD remain available to clients for a 1034 period of time equal to the duration of the segment plus the duration 1035 of the longest Playlist file distributed by the server containing 1036 that segment. 1038 If a server plans to remove a media segment after it is delivered to 1039 clients over HTTP, it SHOULD ensure that the HTTP response contains 1040 an Expires header that reflects the planned time-to-live. 1042 6.2.3. Encrypting media segments 1044 If media segments are to be encrypted the server MUST define a URI 1045 which will allow authorized clients to obtain a Key file containing a 1046 decryption key. The Key file MUST conform to the format described in 1047 Section 5. 1049 The server MAY set the HTTP Expires header in the key response to 1050 indicate that the key may be cached. 1052 The server MUST encrypt every media segment in a Playlist according 1053 to the EXT-X-KEY tag that applies to its URI in the Playlist file. 1054 Media segments with an EXT-X-KEY tag whose METHOD is NONE, or which 1055 do not have an EXT-X-KEY tag applied to them, MUST NOT be encrypted. 1057 If the encryption METHOD is AES-128 and the Playlist does not contain 1058 the EXT-X-I-FRAMES-ONLY tag, AES-128 CBC encryption with PKCS7 1059 padding [RFC5652] SHALL be applied to individual media segments. The 1060 entire segment MUST be encrypted. Cipher Block Chaining MUST NOT be 1061 applied across media segments. The IV used for encryption MUST be 1062 either the sequence number of the media segment or the value of the 1063 IV attribute of the EXT-X-KEY tag, as described in Section 5.2. 1065 If the encryption METHOD is AES-128 and the Playlist contains an EXT- 1066 X-I-FRAMES-ONLY tag, AES-128 CBC encryption with PKCS7 padding 1067 [RFC5652] MUST be applied to the entire resource. The entire 1068 resource MUST be encrypted. Encryption MAY be restarted on 16-byte 1069 block boundaries, unless the first block contains an I-frame. The IV 1070 used for encryption MUST be either the sequence number of the media 1071 segment or the value of the IV attribute of the EXT-X-KEY tag, as 1072 described in Section 5.2. 1074 If the encryption METHOD is SAMPLE-AES, certain elementary streams 1075 MAY be encrypted prior to encapsulation in a media segment. The 1076 encryption format for H.264, AAC and AC-3 elementary streams is 1077 described by [SampleEnc]. 1079 The server MUST NOT remove an EXT-X-KEY tag from the Playlist file if 1080 it applies to any media segment in the Playlist file. 1082 6.2.4. Providing variant streams 1084 A server MAY offer multiple Playlist files to provide different 1085 encodings of the same presentation. If it does so it SHOULD provide 1086 a variant Playlist file that lists each variant stream to allow 1087 clients to switch between encodings dynamically. 1089 Variant Playlists MUST contain an EXT-X-STREAM-INF tag or EXT-X-I- 1090 FRAME-STREAM-INF tag for each variant stream. Each tag identifying 1091 an encoding of the same presentation MUST have the same PROGRAM-ID 1092 attribute value. The PROGRAM-ID value for each presentation MUST be 1093 unique within the variant Playlist. 1095 If an EXT-X-STREAM-INF tag or EXT-X-I-FRAME-STREAM-INF tag contains 1096 the CODECS attribute, the attribute value MUST include every format 1097 defined by [RFC6381] that is present in any media segment that 1098 appears or will appear in the Playlist file. 1100 The server MUST meet the following constraints when producing variant 1101 streams: 1103 Each variant stream MUST present the same content, including 1104 stream discontinuities. 1106 Each variant Playlist file MUST have the same target duration. 1107 The only exception is that SUBTITLES renditions with a EXT-X- 1108 PLAYLIST-TYPE of VOD MAY have longer target durations. 1110 Content that appears in one variant Playlist file but not in 1111 another MUST appear either at the beginning or at the end of the 1112 Playlist file and MUST NOT be longer than the target duration. 1114 Matching content in variant streams MUST have matching timestamps. 1115 This allows clients to synchronize the streams. 1117 Each Elementary Audio Stream segment MUST signal the timestamp of 1118 its first sample with an ID3 PRIV tag [ID3] at the beginning of 1119 the segment. The ID3 PRIV owner identifier MUST be 1120 "com.apple.streaming.transportStreamTimestamp". The ID3 payload 1121 MUST be a 33-bit MPEG-2 Program Elementary Stream timestamp 1122 expressed as a big-endian eight-octet number, with the upper 31 1123 bits set to zero. 1125 In addition, all variant streams SHOULD contain the same encoded 1126 audio bitstream. This allows clients to switch between streams 1127 without audible glitching. 1129 The rules for variant streams also apply to alternate renditions - 1130 see Section 3.4.10.1. 1132 6.3. Client Process 1134 6.3.1. Introduction 1136 How the client obtains the URI to the Playlist file is outside the 1137 scope of this document; it is presumed to have done so. 1139 The client MUST obtain the Playlist file from the URI. If the 1140 Playlist file so obtained is a variant Playlist, the client MUST 1141 obtain the Playlist file from the variant Playlist. 1143 This document does not specify the treatment of variant streams by 1144 clients. 1146 6.3.2. Loading the Playlist file 1148 Every time a Playlist file is loaded or reloaded from the Playlist 1149 URI: 1151 The client MUST ensure that the Playlist file begins with the 1152 EXTM3U tag and that the EXT-X-VERSION tag, if present, specifies a 1153 protocol version supported by the client; if not, the client MUST 1154 NOT attempt to use the Playlist. 1156 The client SHOULD ignore any tags and attributes it does not 1157 recognize. 1159 The client MUST determine the next media segment to load, as 1160 described in Section 6.3.5. 1162 If the Playlist contains the EXT-X-MEDIA-SEQUENCE tag, the client 1163 SHOULD assume that each media segment in it will become unavailable 1164 at the time that the Playlist file was loaded plus the duration of 1165 the Playlist file. 1167 6.3.3. Playing the Playlist file 1169 The client SHALL choose which media segment to play first from the 1170 Playlist when playback starts. If the EXT-X-ENDLIST tag is not 1171 present and the client intends to play the media regularly (i.e. in 1172 playlist order at the nominal playback rate), the client SHOULD NOT 1173 choose a segment which starts less than three target durations from 1174 the end of the Playlist file. Doing so can trigger playback stalls. 1176 To achieve regular playback, media segments MUST be played in the 1177 order that they appear in the Playlist file. The client MAY present 1178 the available media in any way it wishes, including regular playback, 1179 random access, and trick modes. 1181 The client MUST be prepared to reset its parser(s) and decoder(s) 1182 before playing a media segment that has an EXT-X-DISCONTINUITY tag 1183 applied to it. 1185 The client SHOULD attempt to load media segments in advance of when 1186 they will be required for uninterrupted playback to compensate for 1187 temporary variations in latency and throughput. 1189 If the Playlist file contains the EXT-X-ALLOW-CACHE tag and its value 1190 is NO, the client MUST NOT cache downloaded media segments after they 1191 have been played. Otherwise the client MAY cache downloaded media 1192 segments indefinitely for later replay. 1194 The client MAY use the value of the EXT-X-PROGRAM-DATE-TIME tag to 1195 display the program origination time to the user. If the value 1196 includes time zone information the client SHALL take it into account, 1197 but if it does not the client MUST NOT infer an originating time 1198 zone. 1200 The client MUST NOT depend upon the correctness or the consistency of 1201 the value of the EXT-X-PROGRAM-DATE-TIME tag. 1203 6.3.4. Reloading the Playlist file 1205 The client MUST periodically reload the Playlist file unless it 1206 contains the EXT-X-ENDLIST tag. 1208 However the client MUST NOT attempt to reload the Playlist file more 1209 frequently than specified by this section. 1211 When a client loads a Playlist file for the first time or reloads a 1212 Playlist file and finds that it has changed since the last time it 1213 was loaded, the client MUST wait for a period of time before 1214 attempting to reload the Playlist file again. This period is called 1215 the initial minimum reload delay. It is measured from the time that 1216 the client began loading the Playlist file. 1218 The initial minimum reload delay is the duration of the last media 1219 segment in the Playlist. Media segment duration is specified by the 1220 EXTINF tag. 1222 If the client reloads a Playlist file and finds that it has not 1223 changed then it MUST wait for a period of one-half the target 1224 duration before retrying. 1226 In order to reduce server load, the client SHOULD NOT reload the 1227 Playlist files of variant streams that are not currently being 1228 played. If it decides to switch playback to a different variant, it 1229 SHOULD stop reloading the Playlist of the old variant and begin 1230 loading the Playlist of the new variant. It can use the EXTINF 1231 durations and the constraints in Section 6.2.4 to determine the 1232 approximate location of corresponding media. Once media from the new 1233 variant has been loaded, the timestamps in the media segments can be 1234 used to synchronize the old and new timelines precisely. A client 1235 MUST NOT assume that segments with the same media sequence number in 1236 different variants or renditions contain matching content. 1238 6.3.5. Determining the next segment to load 1240 The client MUST examine the Playlist file every time it is loaded or 1241 reloaded to determine the next media segment to load. 1243 The first segment to load MUST be the segment that the client has 1244 chosen to play first, as described in Section 6.3.3. 1246 If the first segment to be played has been loaded and the Playlist 1247 file does not contain the EXT-X-MEDIA-SEQUENCE tag then the client 1248 MUST verify that the current Playlist file contains the URI of the 1249 last loaded media segment at the offset it was originally found at, 1250 halting playback if it does not. The next media segment to load MUST 1251 be the first media segment following the last-loaded segment in the 1252 Playlist. 1254 If the first segment to be played has been loaded and the Playlist 1255 file contains the EXT-X-MEDIA-SEQUENCE tag then the next media 1256 segment to load SHALL be the one with the lowest sequence number that 1257 is greater than the sequence number of the last media segment loaded. 1259 6.3.6. Decrypting encrypted media segments 1261 If a Playlist file contains an EXT-X-KEY tag that specifies a Key 1262 file URI, the client MUST obtain that key file and use the key inside 1263 it to decrypt all media segments to which that EXT-X-KEY tag applies. 1265 A client MUST NOT attempt to use an EXT-X-KEY tag with an unsupported 1266 or unrecognized KEYFORMAT attribute. A client SHOULD fail playback 1267 if the Playlist contains a media segment to which only EXT-X-KEY tags 1268 with unrecognized or unsupported KEYFORMAT attributes are applied. 1270 If the encryption METHOD is AES-128, AES-128 CBC decryption SHALL be 1271 applied to individual media segments. The entire segment MUST be 1272 decrypted. Cipher Block Chaining MUST NOT be applied across media 1273 segments. The IV used for decryption MUST be either the sequence 1274 number of the media segment or the value of the IV attribute of the 1275 EXT-X-KEY tag, as described in Section 5.2. 1277 If the encryption METHOD is AES-128 and the media segment is part of 1278 an I-frame playlist (Section 3.4.12) special care MUST be taken in 1279 loading and decrypting the segment, because the resource identified 1280 by the URI is encrypted in 16-byte blocks from the start of the 1281 resource (offset 0). The sub-range specified by the EXT-X-BYTERANGE 1282 tag MUST be widened to include the 16-byte blocks in which the 1283 beginning and end of the sub-range fall. Next, it MUST be widened 1284 further to include the previous 16-byte block. That range MUST be 1285 loaded and decrypted with AES-128 CBC using an arbitrary IV. The 1286 decrypted segment will then be in the original (unwidened) sub-range. 1288 If the encryption METHOD is SAMPLE-AES, AES-128 decryption SHALL be 1289 applied to encrypted elementary streams within the media segment. 1290 The encryption format for H.264, AAC and AC-3 elementary streams is 1291 described by [SampleEnc]. 1293 An EXT-X-KEY tag with a METHOD of NONE indicates that the media 1294 segments it applies to are not encrypted. 1296 7. Protocol version compatibility 1298 Clients and servers MUST implement protocol version 2 or higher to 1299 use: 1301 o The IV attribute of the EXT-X-KEY tag. 1303 Clients and servers MUST implement protocol version 3 or higher to 1304 use: 1306 o Floating-point EXTINF duration values. 1308 Clients and servers MUST implement protocol version 4 or higher to 1309 use: 1311 o The EXT-X-BYTERANGE tag. 1313 o The EXT-X-I-FRAME-STREAM-INF tag. 1315 o The EXT-X-I-FRAMES-ONLY tag. 1317 o The EXT-X-MEDIA tag. 1319 o The AUDIO and VIDEO attributes of the EXT-X-STREAM-INF tag. 1321 Clients and servers MUST implement protocol version 5 or higher to 1322 use: 1324 o The KEYFORMAT and KEYFORMATVERSIONS attributes of the EXT-X-KEY 1325 tag. 1327 o The EXT-X-MAP tag. 1329 8. Examples 1331 8.1. Introduction 1333 This section contains several example Playlist files. 1335 8.2. Simple Playlist file 1337 #EXTM3U 1338 #EXT-X-VERSION:3 1339 #EXT-X-TARGETDURATION:5220 1340 #EXTINF:5219.2, 1341 http://media.example.com/entire.ts 1342 #EXT-X-ENDLIST 1344 8.3. Sliding Window Playlist, using HTTPS 1346 #EXTM3U 1347 #EXT-X-VERSION:3 1348 #EXT-X-TARGETDURATION:8 1349 #EXT-X-MEDIA-SEQUENCE:2680 1351 #EXTINF:7.975, 1352 https://priv.example.com/fileSequence2680.ts 1353 #EXTINF:7.941, 1354 https://priv.example.com/fileSequence2681.ts 1355 #EXTINF:7.975, 1356 https://priv.example.com/fileSequence2682.ts 1358 8.4. Playlist file with encrypted media segments 1360 #EXTM3U 1361 #EXT-X-VERSION:3 1362 #EXT-X-MEDIA-SEQUENCE:7794 1363 #EXT-X-TARGETDURATION:15 1365 #EXT-X-KEY:METHOD=AES-128,URI="https://priv.example.com/key.php?r=52" 1367 #EXTINF:2.833, 1368 http://media.example.com/fileSequence52-A.ts 1369 #EXTINF:15.0, 1370 http://media.example.com/fileSequence52-B.ts 1371 #EXTINF:13.333, 1372 http://media.example.com/fileSequence52-C.ts 1374 #EXT-X-KEY:METHOD=AES-128,URI="https://priv.example.com/key.php?r=53" 1376 #EXTINF:15.0, 1377 http://media.example.com/fileSequence53-A.ts 1379 8.5. Variant Playlist file 1381 #EXTM3U 1382 #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1280000 1383 http://example.com/low.m3u8 1384 #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=2560000 1385 http://example.com/mid.m3u8 1386 #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=7680000 1387 http://example.com/hi.m3u8 1388 #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=65000,CODECS="mp4a.40.5" 1389 http://example.com/audio-only.m3u8 1391 8.6. Variant Playlist with I-Frames 1393 In this example, the PROGRAM-ID attributes have been left out: 1395 #EXTM3U 1396 #EXT-X-STREAM-INF:BANDWIDTH=1280000 1397 low/audio-video.m3u8 1398 #EXT-X-I-FRAME-STREAM-INF:BANDWIDTH=86000,URI="low/iframe.m3u8" 1399 #EXT-X-STREAM-INF:BANDWIDTH=2560000 1400 mid/audio-video.m3u8 1401 #EXT-X-I-FRAME-STREAM-INF:BANDWIDTH=150000,URI="mid/iframe.m3u8" 1402 #EXT-X-STREAM-INF:BANDWIDTH=7680000 1403 hi/audio-video.m3u8 1404 #EXT-X-I-FRAME-STREAM-INF:BANDWIDTH=550000,URI="hi/iframe.m3u8" 1405 #EXT-X-STREAM-INF:BANDWIDTH=65000,CODECS="mp4a.40.5" 1406 audio-only.m3u8 1408 8.7. Variant Playlist with Alternative audio 1410 In this example, the PROGRAM-ID attributes have been left out. The 1411 CODECS attributes have been condensed for space. A '\' is used to 1412 indicate that the tag continues on the following line with whitespace 1413 removed: 1415 #EXTM3U 1416 #EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="aac",NAME="English", \ 1417 DEFAULT=YES,AUTOSELECT=YES,LANGUAGE="en", \ 1418 URI="main/english-audio.m3u8" 1419 #EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="aac",NAME="Deutsche", \ 1420 DEFAULT=NO,AUTOSELECT=YES,LANGUAGE="de", \ 1421 URI="main/german-audio.m3u8" 1422 #EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="aac",NAME="Commentary", \ 1423 DEFAULT=NO,AUTOSELECT=NO,URI="commentary/audio-only.m3u8" 1424 #EXT-X-STREAM-INF:BANDWIDTH=1280000,CODECS="...",AUDIO="aac" 1425 low/video-only.m3u8 1426 #EXT-X-STREAM-INF:BANDWIDTH=2560000,CODECS="...",AUDIO="aac" 1427 mid/video-only.m3u8 1428 #EXT-X-STREAM-INF:BANDWIDTH=7680000,CODECS="...",AUDIO="aac" 1429 hi/video-only.m3u8 1430 #EXT-X-STREAM-INF:BANDWIDTH=65000,CODECS="mp4a.40.5",AUDIO="aac" 1431 main/english-audio.m3u8 1433 8.8. Variant Playlist with Alternative video 1435 In this example, the PROGRAM-ID attributes have been left out. The 1436 CODECS attributes have been condensed for space. A '\' is used to 1437 indicate that the tag continues on the following line with whitespace 1438 removed: 1440 #EXTM3U 1441 #EXT-X-MEDIA:TYPE=VIDEO,GROUP-ID="low",NAME="Main", \ 1442 DEFAULT=YES,URI="low/main/audio-video.m3u8" 1443 #EXT-X-MEDIA:TYPE=VIDEO,GROUP-ID="low",NAME="Centerfield", \ 1444 DEFAULT=NO,URI="low/centerfield/audio-video.m3u8" 1445 #EXT-X-MEDIA:TYPE=VIDEO,GROUP-ID="low",NAME="Dugout", \ 1446 DEFAULT=NO,URI="low/dugout/audio-video.m3u8" 1448 #EXT-X-STREAM-INF:BANDWIDTH=1280000,CODECS="...",VIDEO="low" 1449 low/main/audio-video.m3u8 1451 #EXT-X-MEDIA:TYPE=VIDEO,GROUP-ID="mid",NAME="Main", \ 1452 DEFAULT=YES,URI="mid/main/audio-video.m3u8" 1453 #EXT-X-MEDIA:TYPE=VIDEO,GROUP-ID="mid",NAME="Centerfield", \ 1454 DEFAULT=NO,URI="mid/centerfield/audio-video.m3u8" 1455 #EXT-X-MEDIA:TYPE=VIDEO,GROUP-ID="mid",NAME="Dugout", \ 1456 DEFAULT=NO,URI="mid/dugout/audio-video.m3u8" 1458 #EXT-X-STREAM-INF:BANDWIDTH=2560000,CODECS="...",VIDEO="mid" 1459 mid/main/audio-video.m3u8 1461 #EXT-X-MEDIA:TYPE=VIDEO,GROUP-ID="hi",NAME="Main", \ 1462 DEFAULT=YES,URI="hi/main/audio-video.m3u8" 1463 #EXT-X-MEDIA:TYPE=VIDEO,GROUP-ID="hi",NAME="Centerfield", \ 1464 DEFAULT=NO,URI="hi/centerfield/audio-video.m3u8" 1465 #EXT-X-MEDIA:TYPE=VIDEO,GROUP-ID="hi",NAME="Dugout", \ 1466 DEFAULT=NO,URI="hi/dugout/audio-video.m3u8" 1468 #EXT-X-STREAM-INF:BANDWIDTH=7680000,CODECS="...",VIDEO="hi" 1469 hi/main/audio-video.m3u8 1471 #EXT-X-STREAM-INF:BANDWIDTH=65000,CODECS="mp4a.40.5" 1472 main/audio-only.m3u8 1474 9. Contributors 1476 Significant contributions to the design of this protocol were made by 1477 Jim Batson, David Biderman, Bill May, Roger Pantos, and Alan Tseng. 1479 10. IANA Considerations 1481 This memo requests that the following MIME type [RFC2046] be 1482 registered with the IANA: 1484 Type name: "application" 1485 Subtype name: "vnd.apple.mpegurl" 1487 Required parameters: (none) 1489 Optional parameters: (none) 1491 Encoding considerations: encoded as text. See Section 3 for more 1492 information. 1494 Security considerations: See Section 11. 1496 Compression: this media type does not employ compression. 1498 Interoperability considerations: There are no byte-ordering issues, 1499 since files are 7- or 8-bit text. Applications could encounter 1500 unrecognized tags, which SHOULD be ignored. 1502 Published specification: see Section 3. 1504 Applications that use this media type: Multimedia applications such 1505 as the iPhone media player in iOS 3.0 and later and QuickTime Player 1506 in Mac OS X version 10.6 and later. 1508 Additional information: files begin with the magic number #EXTM3U. 1509 Filenames normally end with .m3u8 or .m3u (see Section 3). No 1510 Macintosh file type codes have been registered. 1512 Person & email address to contact for further information: David 1513 Singer, singer AT apple.com. 1515 Intended usage: LIMITED USE 1517 Restrictions on usage: (none) 1519 Author: Roger Pantos 1521 Change Controller: David Singer 1523 11. Security Considerations 1525 Since the protocol generally uses HTTP to transfer data, most of the 1526 same security considerations apply. See section 15 of RFC 2616 1527 [RFC2616]. 1529 Media file parsers are typically subject to "fuzzing" attacks. 1530 Clients SHOULD take care when parsing segments received from a server 1531 that non-compliant segments are rejected. 1533 Playlist files contain URIs, which clients will use to make network 1534 requests of arbitrary entities. Clients SHOULD range-check responses 1535 to prevent buffer overflows. See also the Security Considerations 1536 section of RFC 3986 [RFC3986]. 1538 Clients SHOULD load resources identified by URI lazily to avoid 1539 contributing to denial-of-service attacks. 1541 HTTP requests often include session state ("cookies"), which may 1542 contain private user data. Implementations MUST follow cookie 1543 restriction and expiry rules specified by RFC 6265 [RFC6265]. See 1544 also the Security Considerations section of RFC 6265, and RFC 2964 1545 [RFC2964]. 1547 Encryption keys are specified by URI. The delivery of these keys 1548 SHOULD be secured by a mechanism such as HTTP over TLS [RFC5246] 1549 (formerly SSL) in conjunction with a secure realm or a session 1550 cookie. 1552 12. References 1554 12.1. Normative References 1556 [AC_3] Advanced Television Systems Committee, "ATSC Standard: 1557 A/52:2010: Digital Audio Compression (AC-3) (E-AC-3) 1558 Standard", November 2010, 1559 <http://www.atsc.org/cms/standards/a_52-2010.pdf>. 1561 [AES_128] U.S. Department of Commerce/National Institute of 1562 Standards and Technology, "Advanced Encryption Standard 1563 (AES), FIPS PUB 197", November 2001, <http:// 1564 csrc.nist.gov/publications/fips/fips197/fips-197.pdf>. 1566 [H_264] International Telecommunications Union, "Advanced video 1567 coding for generic audiovisual services", January 2012, 1568 <http://www.itu.int/rec/T-REC-H.264>. 1570 [ISO_11172] 1571 International Organization for Standardization, "ISO/IEC 1572 International Standard 11172-1; Coding of moving pictures 1573 and associated audio for digital storage media -- Part 1: 1574 Systems", 1993, <http://www.iso.org/iso/ 1575 catalogue_detail.htm?csnumber=19180>. 1577 [ISO_13818] 1578 International Organization for Standardization, "ISO/IEC 1579 International Standard 13818; Generic coding of moving 1580 pictures and associated audio information", October 2007, 1581 <http://www.iso.org/iso/catalogue_detail?csnumber=44169>. 1583 [ISO_14496] 1584 International Organization for Standardization, "ISO/IEC 1585 14496-3:2009 Information technology -- Coding of audio- 1586 visual objects -- Part 3: Audio", 2009, <http:// 1587 www.iso.org/iso/iso_catalogue/catalogue_ics/ 1588 catalogue_detail_ics.htm?csnumber=53943>. 1590 [ISO_8601] 1591 International Organization for Standardization, "ISO/IEC 1592 International Standard 8601:2004; Data elements and 1593 interchange formats -- Information interchange -- 1594 Representation of dates and times", December 2004, 1595 <http://www.iso.org/iso/catalogue_detail?csnumber=40874>. 1597 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1598 Extensions (MIME) Part Two: Media Types", RFC 2046, 1599 November 1996. 1601 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1602 Requirement Levels", BCP 14, RFC 2119, March 1997. 1604 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1605 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1606 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1608 [RFC2964] Moore, K. and N. Freed, "Use of HTTP State Management", 1609 BCP 44, RFC 2964, October 2000. 1611 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1612 10646", STD 63, RFC 3629, November 2003. 1614 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1615 Resource Identifier (URI): Generic Syntax", STD 66, 1616 RFC 3986, January 2005. 1618 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1619 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1621 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying 1622 Languages", BCP 47, RFC 5646, September 2009. 1624 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1625 RFC 5652, September 2009. 1627 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 1628 April 2011. 1630 [RFC6381] Gellens, R., Singer, D., and P. Frojdh, "The 'Codecs' and 1631 'Profiles' Parameters for "Bucket" Media Types", RFC 6381, 1632 August 2011. 1634 [US_ASCII] 1635 American National Standards Institute, "ANSI X3.4-1986, 1636 Information Systems -- Coded Character Sets 7-Bit American 1637 National Standard Code for Information Interchange (7-Bit 1638 ASCII)", December 1986. 1640 12.2. Informative References 1642 [ID3] ID3.org, "The ID3 audio file data tagging format", 1643 <http://www.id3.org/Developer_Information>. 1645 [M3U] Nullsoft, Inc., "The M3U Playlist format, originally 1646 invented for the Winamp media player", 1647 <http://wikipedia.org/wiki/M3U>. 1649 [SampleEnc] 1650 Apple Inc., "MPEG-2 Stream Encryption Format for HTTP Live 1651 Streaming", <https://developer.apple.com/library/ios/ 1652 documentation/AudioVideo/Conceptual/ 1653 HLS_Sample_Encryption/>. 1655 [UTI] Apple Inc., "Uniform Type Identifier", <http:// 1656 developer.apple.com/library/ios/#documentation/general/ 1657 conceptual/DevPedia-CocoaCore/UniformTypeIdentifier.html>. 1659 [WebVTT] World Wide Web Consortium (W3C), "WebVTT Standard", 1660 September 2012, <http://dev.w3.org/html5/webvtt/>. 1662 Authors' Addresses 1664 Roger Pantos (editor) 1665 Apple Inc. 1666 Cupertino, California 1667 United States 1669 Email: http-live-streaming-review@group.apple.com 1670 William May, Jr. 1671 Apple Inc. 1672 Cupertino, California 1673 United States 1675 Email: http-live-streaming-review@group.apple.com