idnits 2.17.1 draft-pantos-http-live-streaming-08.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 (March 23, 2012) is 4417 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: September 24, 2012 March 23, 2012 7 HTTP Live Streaming 8 draft-pantos-http-live-streaming-08 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 4 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 September 24, 2012. 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 . . . . . . . . . . . . . . . 9 69 3.4.6. EXT-X-ALLOW-CACHE . . . . . . . . . . . . . . . . . . 9 70 3.4.7. EXT-X-PLAYLIST-TYPE . . . . . . . . . . . . . . . . . 10 71 3.4.8. EXT-X-ENDLIST . . . . . . . . . . . . . . . . . . . . 10 72 3.4.9. EXT-X-MEDIA . . . . . . . . . . . . . . . . . . . . . 10 73 3.4.9.1. Rendition Groups . . . . . . . . . . . . . . . . . 11 74 3.4.10. EXT-X-STREAM-INF . . . . . . . . . . . . . . . . . . . 12 75 3.4.10.1. Alternative Renditions . . . . . . . . . . . . . . 13 76 3.4.11. EXT-X-DISCONTINUITY . . . . . . . . . . . . . . . . . 14 77 3.4.12. EXT-X-I-FRAMES-ONLY . . . . . . . . . . . . . . . . . 14 78 3.4.13. EXT-X-I-FRAME-STREAM-INF . . . . . . . . . . . . . . . 15 79 3.4.14. EXT-X-VERSION . . . . . . . . . . . . . . . . . . . . 16 80 4. Media segments . . . . . . . . . . . . . . . . . . . . . . . . 16 81 5. Key files . . . . . . . . . . . . . . . . . . . . . . . . . . 17 82 5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 17 83 5.2. IV for AES-128 . . . . . . . . . . . . . . . . . . . . . . 17 84 6. Client/Server Actions . . . . . . . . . . . . . . . . . . . . 17 85 6.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 17 86 6.2. Server Process . . . . . . . . . . . . . . . . . . . . . . 18 87 6.2.1. Introduction . . . . . . . . . . . . . . . . . . . . . 18 88 6.2.2. Sliding Window Playlists . . . . . . . . . . . . . . . 20 89 6.2.3. Encrypting media segments . . . . . . . . . . . . . . 20 90 6.2.4. Providing variant streams . . . . . . . . . . . . . . 21 91 6.3. Client Process . . . . . . . . . . . . . . . . . . . . . . 22 92 6.3.1. Introduction . . . . . . . . . . . . . . . . . . . . . 22 93 6.3.2. Loading the Playlist file . . . . . . . . . . . . . . 22 94 6.3.3. Playing the Playlist file . . . . . . . . . . . . . . 22 95 6.3.4. Reloading the Playlist file . . . . . . . . . . . . . 23 96 6.3.5. Determining the next segment to load . . . . . . . . . 24 97 6.3.6. Decrypting encrypted media segments . . . . . . . . . 24 98 7. Protocol version compatibility . . . . . . . . . . . . . . . . 25 99 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 100 8.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 26 101 8.2. Simple Playlist file . . . . . . . . . . . . . . . . . . . 26 102 8.3. Sliding Window Playlist, using HTTPS . . . . . . . . . . . 26 103 8.4. Playlist file with encrypted media segments . . . . . . . 26 104 8.5. Variant Playlist file . . . . . . . . . . . . . . . . . . 27 105 8.6. Variant Playlist with I-Frames . . . . . . . . . . . . . . 27 106 8.7. Variant Playlist with Alternative audio . . . . . . . . . 27 107 8.8. Variant Playlist with Alternative video . . . . . . . . . 28 108 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 29 109 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 110 11. Security Considerations . . . . . . . . . . . . . . . . . . . 30 111 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 112 12.1. Normative References . . . . . . . . . . . . . . . . . . . 31 113 12.2. Informative References . . . . . . . . . . . . . . . . . . 32 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 116 1. Introduction 118 This document describes a protocol for transferring unbounded streams 119 of multimedia data. The protocol supports the encryption of media 120 data and the provision of alternate versions (e.g. bitrates) of a 121 stream. Media data can be transferred soon after it is created, 122 allowing it to be played in near real-time. Data is usually carried 123 over HTTP [RFC2616]. 125 External references that describe related standards such as HTTP are 126 listed in Section 11. 128 2. Summary 130 A multimedia presentation is specified by a URI [RFC3986] to a 131 Playlist file, which is an ordered list of media URIs and 132 informational tags. The URIs and their associated tags specify a 133 series of media segments. 135 To play the stream, the client first obtains the Playlist file and 136 then obtains and plays each media segment in the Playlist. It 137 reloads the Playlist file as described in this document to discover 138 additional segments. 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in RFC 2119 [RFC2119]. 144 3. The Playlist file 146 3.1. Introduction 148 Playlists MUST be Extended M3U Playlist files [M3U]. This document 149 extends the M3U file format further by defining additional tags. 151 An M3U Playlist is a text file that consists of individual lines. 152 Lines are terminated by either a single LF character or a CR 153 character followed by an LF character. Each line is a URI, blank, or 154 starts with the character '#'. Blank lines are ignored. White space 155 MUST NOT be present, except for elements in which it is explicitly 156 specified. 158 A URI line identifies a media segment or a variant Playlist file (see 159 Section 3.4.10). Each media segment is specified by a media URI and 160 the tags that apply to it. 162 Lines that start with the character '#' are either comments or tags. 164 Tags begin with #EXT. All other lines that begin with '#' are 165 comments and SHOULD be ignored. 167 A URI in a Playlist, whether it is a URI line or part of a tag, MAY 168 be relative. Relative URIs MUST be resolved against the URI of the 169 Playlist file that contains it. 171 The duration of a Playlist file is the sum of the durations of the 172 media segments within it. 174 Playlist files whose names end in .m3u8 and/or have the HTTP Content- 175 Type "application/vnd.apple.mpegurl" are encoded in UTF-8 [RFC3629]. 176 Files whose names end with .m3u and/or have the HTTP Content-Type 177 [RFC2616] "audio/mpegurl" are encoded in US-ASCII [US_ASCII]. 179 Playlist files MUST have names that end in .m3u8 and/or have the 180 Content-Type "application/vnd.apple.mpegurl" (if transferred over 181 HTTP), or have names that end in .m3u and/or have the HTTP Content- 182 Type type "audio/mpegurl" (for compatibility). 184 3.2. Attribute Lists 186 Certain extended M3U tags have values which are Attribute Lists. An 187 Attribute List is a comma-separated list of attribute/value pairs 188 with no whitespace. 190 An attribute/value pair has the following syntax: 192 AttributeName=AttributeValue 194 An AttributeName is an unquoted string containing characters from the 195 set [A..Z] and '-'. 197 An AttributeValue is one of the following: 199 o decimal-integer: an unquoted string of characters from the set 200 [0..9] expressing an integer in base-10 arithmetic. 202 o hexadecimal-integer: an unquoted string of characters from the set 203 [0..9] and [A..F] that is prefixed with 0x or 0X and which 204 expresses an integer in base-16 arithmetic. 206 o decimal-floating-point: an unquoted string of characters from the 207 set [0..9] and '.' which expresses a floating-point number in 208 decimal positional notation. 210 o quoted-string: a string of characters within a pair of double- 211 quotes ("). The set of characters allowed in the string and any 212 rules for escaping special characters are specified by the 213 Attribute definition, but any double-quote (") character and any 214 carriage-return or linefeed will always be replaced by an escape 215 sequence. 217 o enumerated-string: an unquoted character string from a set which 218 is explicitly defined by the Attribute. An enumerated-string will 219 never contain double-quotes ("), commas (,), or whitespace. 221 o decimal-resolution: two decimal-integers separated by the "x" 222 character. The first integer is a horizontal pixel dimension 223 (width); the second is a vertical pixel dimension (height). 225 The type of the AttributeValue for a given AttributeName is specified 226 by the Attribute definition. 228 A given AttributeName MUST NOT appear more than once in a given 229 Attribute List. 231 An Attribute/value pair with an unrecognized AttributeName MUST be 232 ignored by the client. 234 Attribute/value pairs of type enumerated-string that contain 235 unrecognized values SHOULD be ignored by the client. 237 3.3. Standard Tags 239 3.3.1. EXTM3U 241 An Extended M3U file is distinguished from a basic M3U file by its 242 first line, which MUST be the tag #EXTM3U. 244 3.3.2. EXTINF 246 The EXTINF tag specifies the duration of a media segment. It applies 247 only to the media URI that follows it. Each media segment URI MUST 248 be preceded by an EXTINF tag. Its format is: 250 #EXTINF:, 252 "duration" is an integer or floating-point number in decimal 253 positional notation that specifies the duration of the media segment 254 in seconds. Durations that are reported as integers SHOULD be 255 rounded to the nearest integer. Durations MUST be integers if the 256 protocol version of the Playlist file is less than 3. The remainder 257 of the line following the comma is an optional human-readable 258 informative title of the media segment. 260 3.4. New Tags 262 This document defines the following new tags: EXT-X-BYTERANGE, EXT-X- 263 TARGETDURATION, EXT-X-MEDIA-SEQUENCE, EXT-X-KEY, EXT-X-PROGRAM-DATE- 264 TIME, EXT-X-ALLOW-CACHE, EXT-X-PLAYLIST-TYPE, EXT-X-STREAM-INF, EXT- 265 X-I-FRAME-STREAM-INF, EXT-X-I-FRAMES-ONLY, EXT-X-MEDIA, EXT-X- 266 ENDLIST, EXT-X-DISCONTINUITY, and EXT-X-VERSION. 268 3.4.1. EXT-X-BYTERANGE 270 The EXT-X-BYTERANGE tag indicates that a media segment is a sub-range 271 of the resource identified by its media URI. It applies only to the 272 next media URI that follows it in the Playlist. Its format is: 274 #EXT-X-BYTERANGE:<n>[@o] 276 where n is a decimal-integer indicating the length of the sub-range 277 in bytes. If present, o is a decimal-integer indicating the start of 278 the sub-range, as a byte offset from the beginning of the resource. 279 If o is not present, the sub-range begins at the next byte following 280 the sub-range of the previous media segment. 282 If o is not present, a previous media segment MUST appear in the 283 Playlist file and MUST be a sub-range of the same media resource. 285 A media URI with no EXT-X-BYTERANGE tag applied to it specifies a 286 media segment that consists of the entire resource. 288 The EXT-X-BYTERANGE tag appeared in version 4 of the protocol. 290 3.4.2. EXT-X-TARGETDURATION 292 The EXT-X-TARGETDURATION tag specifies the maximum media segment 293 duration. The EXTINF duration of each media segment in the Playlist 294 file MUST be less than or equal to the target duration. This tag 295 MUST appear once in the Playlist file. It applies to the entire 296 Playlist file. Its format is: 298 #EXT-X-TARGETDURATION:<s> 300 where s is an integer indicating the target duration in seconds. 302 3.4.3. EXT-X-MEDIA-SEQUENCE 304 Each media URI in a Playlist has a unique integer sequence number. 305 The sequence number of a URI is equal to the sequence number of the 306 URI that preceded it plus one. The EXT-X-MEDIA-SEQUENCE tag 307 indicates the sequence number of the first URI that appears in a 308 Playlist file. Its format is: 310 #EXT-X-MEDIA-SEQUENCE:<number> 312 A Playlist file MUST NOT contain more than one EXT-X-MEDIA-SEQUENCE 313 tag. If the Playlist file does not contain an EXT-X-MEDIA-SEQUENCE 314 tag then the sequence number of the first URI in the playlist SHALL 315 be considered to be 0. 317 A media URI is not required to contain its sequence number. 319 See Section 6.3.2 and Section 6.3.5 for information on handling the 320 EXT-X-MEDIA-SEQUENCE tag. 322 3.4.4. EXT-X-KEY 324 Media segments MAY be encrypted. The EXT-X-KEY tag specifies how to 325 decrypt them. It applies to every media URI that appears between it 326 and the next EXT-X-KEY tag in the Playlist file (if any). Its format 327 is: 329 #EXT-X-KEY:<attribute-list> 331 The following attributes are defined: 333 The METHOD attribute specifies the encryption method. It is of type 334 enumerated-string. Each EXT-X-KEY tag MUST contain a METHOD 335 attribute. 337 Two methods are defined: NONE and AES-128. 339 An encryption method of NONE means that media segments are not 340 encrypted. If the encryption method is NONE, the URI and the IV 341 attributes MUST NOT be present. 343 An encryption method of AES-128 means that media segments are 344 encrypted using the Advanced Encryption Standard [AES_128] with a 345 128-bit key and PKCS7 padding [RFC5652]. If the encryption method is 346 AES-128, the URI attribute MUST be present. The IV attribute MAY be 347 present; see Section 5.2. 349 The URI attribute specifies how to obtain the key. Its value is a 350 quoted-string that contains a URI [RFC3986] for the key. 352 The IV attribute, if present, specifies the Initialization Vector to 353 be used with the key. Its value is a hexadecimal-integer. The IV 354 attribute appeared in protocol version 2. 356 If the Playlist file does not contain an EXT-X-KEY tag then media 357 segments are not encrypted. 359 See Section 5 for the format of the key file, and Section 5.2, 360 Section 6.2.3 and Section 6.3.6 for additional information on media 361 segment encryption. 363 3.4.5. EXT-X-PROGRAM-DATE-TIME 365 The EXT-X-PROGRAM-DATE-TIME tag associates the first sample of a 366 media segment with an absolute date and/or time. It applies only to 367 the next media URI. 369 The date/time representation is ISO/IEC 8601:2004 [ISO_8601] and 370 SHOULD indicate a time zone: 372 #EXT-X-PROGRAM-DATE-TIME:<YYYY-MM-DDThh:mm:ssZ> 374 For example: 376 #EXT-X-PROGRAM-DATE-TIME:2010-02-19T14:54:23.031+08:00 378 See Section 6.2.1 and Section 6.3.3 for more information on the EXT- 379 X-PROGRAM-DATE-TIME tag. 381 3.4.6. EXT-X-ALLOW-CACHE 383 The EXT-X-ALLOW-CACHE tag indicates whether the client MAY or MUST 384 NOT cache downloaded media segments for later replay. It MAY occur 385 anywhere in the Playlist file; it MUST NOT occur more than once. The 386 EXT-X-ALLOW-CACHE tag applies to all segments in the playlist. Its 387 format is: 389 #EXT-X-ALLOW-CACHE:<YES|NO> 391 See Section 6.3.3 for more information on the EXT-X-ALLOW-CACHE tag. 393 3.4.7. EXT-X-PLAYLIST-TYPE 395 The EXT-X-PLAYLIST-TYPE tag provides mutability information about the 396 Playlist file. It applies to the entire Playlist file. It is 397 optional. Its format is: 399 #EXT-X-PLAYLIST-TYPE:<EVENT|VOD> 401 Section 6.2.1 defines the implications of the EXT-X-PLAYLIST-TYPE 402 tag. 404 3.4.8. EXT-X-ENDLIST 406 The EXT-X-ENDLIST tag indicates that no more media segments will be 407 added to the Playlist file. It MAY occur anywhere in the Playlist 408 file; it MUST NOT occur more than once. Its format is: 410 #EXT-X-ENDLIST 412 3.4.9. EXT-X-MEDIA 414 The EXT-X-MEDIA tag is used to relate Playlists that contain 415 alternative renditions of the same content. For example, three EXT- 416 X-MEDIA tags can be used to identify audio-only Playlists that 417 contain English, French and Spanish renditions of the same 418 presentation. Or two EXT-X-MEDIA tags can be used to identify video- 419 only Playlists that show two different camera angles. 421 The EXT-X-MEDIA tag stands alone, in that it does not apply to a 422 particular URI in the Playlist. Its format is: 424 #EXT-X-MEDIA:<attribute-list> 426 The following attributes are defined: 428 URI 430 The value is a quoted-string containing a URI that identifies the 431 Playlist file. This attribute is optional; see Section 3.4.10.1. 433 TYPE 435 The value is enumerated-string; valid strings are AUDIO and VIDEO. 436 If the value is AUDIO, the Playlist described by the tag MUST contain 437 audio media. If the value is VIDEO, the Playlist MUST contain video 438 media. 440 GROUP-ID 442 The value is a quoted-string identifying a mutually-exclusive group 443 of renditions. The presence of this attribute signals membership in 444 the group. See Section 3.4.9.1. 446 LANGUAGE 448 The value is a quoted-string containing an RFC 5646 [RFC5646] 449 language tag that identifies the primary language used in the 450 rendition. This attribute is optional. 452 NAME 454 The value is a quoted-string containing a human-readable description 455 of the rendition. If the LANGUAGE attribute is present then this 456 description SHOULD be in that language. 458 DEFAULT 460 The value is enumerated-string; valid strings are YES and NO. If the 461 value is YES, then the client SHOULD play this rendition of the 462 content in the absence of information from the user indicating a 463 different choice. This attribute is optional. Its absence indicates 464 an implicit value of NO. 466 AUTOSELECT 468 The value is enumerated-string; valid strings are YES and NO. This 469 attribute is optional. Its absence indicates an implicit value of 470 NO. If the value is YES, then the client MAY choose to play this 471 rendition in the absence of explicit user preference because it 472 matches the current playback environment, such as chosen system 473 language. 475 The EXT-X-MEDIA tag appeared in version 4 of the protocol. 477 3.4.9.1. Rendition Groups 479 A set of EXT-X-MEDIA tags with the same GROUP-ID value forms a group 480 of renditions. Each member of the group MUST represent an 481 alternative rendition of the same content. 483 All EXT-X-MEDIA tags in a Playlist MUST meet the following 484 constraints: 486 o All EXT-X-MEDIA tags in the same group MUST have the same TYPE 487 attribute. 489 o All EXT-X-MEDIA tags in the same group MUST have different NAME 490 attributes. 492 o A group MUST NOT have more than one member with a DEFAULT 493 attribute of YES. 495 o All members of a group whose AUTOSELECT attribute has a value of 496 YES MUST have LANGUAGE [RFC5646] attributes with unique values. 498 o All members of a group with TYPE=AUDIO MUST use the same audio 499 sample format. 501 o All members of a group with TYPE=VIDEO MUST use the same video 502 sample format. 504 A Playlist MAY contain multiple groups of the same TYPE in order to 505 provide multiple encodings of each rendition. If it does so, each 506 group of the same TYPE SHOULD contain corresponding members with the 507 same NAME attribute, LANGUAGE attribute, and rendition. 509 3.4.10. EXT-X-STREAM-INF 511 The EXT-X-STREAM-INF tag identifies a media URI as a Playlist file 512 containing a multimedia presentation and provides information about 513 that presentation. It applies only to the URI that follows it. Its 514 format is: 516 #EXT-X-STREAM-INF:<attribute-list> 517 <URI> 519 The following attributes are defined: 521 BANDWIDTH 523 The value is a decimal-integer of bits per second. It MUST be an 524 upper bound of the overall bitrate of each media segment (calculated 525 to include container overhead) that appears or will appear in the 526 Playlist. 528 Every EXT-X-STREAM-INF tag MUST include the BANDWIDTH attribute. 530 PROGRAM-ID 532 The value is a decimal-integer that uniquely identifies a particular 533 presentation within the scope of the Playlist file. 535 A Playlist file MAY contain multiple EXT-X-STREAM-INF tags with the 536 same PROGRAM-ID to identify different encodings of the same 537 presentation. These variant playlists MAY contain additional EXT-X- 538 STREAM-INF tags. 540 CODECS 542 The value is a quoted-string containing a comma-separated list of 543 formats, where each format specifies a media sample type that is 544 present in a media segment in the Playlist file. Valid format 545 identifiers are those in the ISO File Format Name Space defined by 546 RFC 6381 [RFC6381]. 548 Every EXT-X-STREAM-INF tag SHOULD include a CODECS attribute. 550 RESOLUTION 552 The value is a decimal-resolution describing the approximate encoded 553 horizontal and vertical resolution of video within the presentation. 555 AUDIO 557 The value is a quoted-string. It MUST match the value of the 558 GROUP-ID attribute of an EXT-X-MEDIA tag elsewhere in the Playlist 559 whose TYPE attribute is AUDIO. It indicates the set of audio 560 renditions that MAY be used when playing the presentation. See 561 Section 3.4.10.1. 563 VIDEO 565 The value is a quoted-string. It MUST match the value of the 566 GROUP-ID attribute of an EXT-X-MEDIA tag elsewhere in the Playlist 567 whose TYPE attribute is VIDEO. It indicates the set of video 568 renditions that MAY be used when playing the presentation. See 569 Section 3.4.10.1. 571 3.4.10.1. Alternative Renditions 573 When an EXT-X-STREAM-INF tag contains an AUDIO or a VIDEO attribute, 574 it indicates that alternative renditions of the content are available 575 for playback of that variant. 577 When defining alternative renditions, the following constraints MUST 578 be met: 580 o All playable combinations of renditions associated with an EXT-X- 581 STREAM-INF tag MUST have an aggregate bandwidth less than or equal 582 to the BANDWIDTH attribute of the EXT-X-STREAM-INF tag. 584 o If an EXT-X-STREAM-INF tag contains a RESOLUTION attribute and a 585 VIDEO attribute, then every alternative video rendition MUST match 586 the value of the RESOLUTION attribute. 588 o Every alternative rendition associated with an EXT-X-STREAM-INF 589 tag MUST meet the constraints for a variant stream described in 590 Section 6.2.4. 592 The URI attribute of an EXT-X-MEDIA tag is optional. If it is 593 missing, it indicates that the rendition described by the EXT-X-MEDIA 594 tag is present in the main Playlist described by the EXT-X-STREAM-INF 595 tag. 597 Note that if a client chooses to play renditions of audio and video 598 that are not present in the main Playlist described by the EXT-X- 599 STREAM-INF tag, or if the client chooses to play an audio rendition 600 and the main Playlist is audio-only, then the client MAY ignore the 601 main Playlist and its media. 603 3.4.11. EXT-X-DISCONTINUITY 605 The EXT-X-DISCONTINUITY tag indicates an encoding discontinuity 606 between the media segment that follows it and the one that preceded 607 it. The set of characteristics that MAY change is: 609 o file format 611 o number and type of tracks 613 o encoding parameters 615 o encoding sequence 617 o timestamp sequence 619 Its format is: 621 #EXT-X-DISCONTINUITY 623 See Section 4, Section 6.2.1, and Section 6.3.3 for more information 624 about the EXT-X-DISCONTINUITY tag. 626 3.4.12. EXT-X-I-FRAMES-ONLY 628 The EXT-X-I-FRAMES-ONLY tag indicates that each media segment in the 629 Playlist describes a single I-frame. I-frames (or Intra frames) are 630 encoded video frames whose encoding does not depend on any other 631 frame. 633 The EXT-X-I-FRAMES-ONLY tag applies to the entire Playlist. Its 634 format is: 636 #EXT-X-I-FRAMES-ONLY 638 In a Playlist with the EXT-X-I-FRAMES-ONLY tag, the media segment 639 duration (EXTINF tag value) is the time between the presentation time 640 of the I-frame in the media segment and the presentation time of the 641 next I-frame in the Playlist, or the end of the presentation if it is 642 the last I-frame in the Playlist. 644 Media resources containing I-frame segments MUST begin with a 645 Transport Stream PAT/PMT. The byte range of an I-frame segment with 646 an EXT-X-BYTERANGE tag applied to it (Section 3.4.1) MUST NOT include 647 a PAT/PMT. 649 The EXT-X-I-FRAMES-ONLY tag appeared in version 4 of the protocol. 651 3.4.13. EXT-X-I-FRAME-STREAM-INF 653 The EXT-X-I-FRAME-STREAM-INF tag identifies a Playlist file 654 containing the I-frames of a multimedia presentation. It stands 655 alone, in that it does not apply to a particular URI in the Playlist. 656 Its format is: 658 #EXT-X-I-FRAME-STREAM-INF:<attribute-list> 660 All attributes defined for the EXT-X-STREAM-INF tag (Section 3.4.10) 661 are also defined for the EXT-X-I-FRAME-STREAM-INF tag, except for the 662 AUDIO attribute. In addition, the following attribute is defined: 664 URI 666 The value is a quoted-string containing a URI that identifies the 667 I-frame Playlist file. 669 Every EXT-X-I-FRAME-STREAM-INF tag MUST include a BANDWIDTH attribute 670 and a URI attribute. 672 The provisions in Section 3.4.10.1 also apply to EXT-X-I-FRAME- 673 STREAM-INF tags with a VIDEO attribute. 675 A Playlist that specifies alternative VIDEO renditions and I-frame 676 Playlists SHOULD include an alternative I-frame VIDEO rendition for 677 each regular VIDEO rendition, with the same NAME and LANGUAGE 678 attributes. 680 The EXT-X-I-FRAME-STREAM-INF tag appeared in version 4 of the 681 protocol. Clients that do not implement protocol version 4 or higher 682 MUST ignore it. 684 3.4.14. EXT-X-VERSION 686 The EXT-X-VERSION tag indicates the compatibility version of the 687 Playlist file. The Playlist file, its associated media, and its 688 server MUST comply with all provisions of the most-recent version of 689 this document describing the protocol version indicated by the tag 690 value. 692 The EXT-X-VERSION tag applies to the entire Playlist file. Its 693 format is: 695 #EXT-X-VERSION:<n> 697 where n is an integer indicating the protocol version. 699 A Playlist file MUST NOT contain more than one EXT-X-VERSION tag. A 700 Playlist file that does not contain an EXT-X-VERSION tag MUST comply 701 with version 1 of this protocol. 703 4. Media segments 705 Each media URI in a Playlist file specifies a media segment which is 706 part of the overall presentation. If a media URI has an EXT-X- 707 BYTERANGE tag applied to it, the segment is a sub-range of the media 708 file identified by the URI. Otherwise, the segment is the entire 709 media file. 711 Each media segment MUST be formatted as an MPEG-2 Transport Stream or 712 an MPEG-2 audio elementary stream [ISO_13818]. 714 Transport Stream segments MUST contain a single MPEG-2 Program. 715 There SHOULD be a Program Association Table (PAT) and a Program Map 716 Table (PMT) at the start of each segment. A segment that contains 717 video SHOULD have at least one key frame and enough information to 718 completely initialize a video decoder. 720 A media segment MUST be the continuation of the encoded media at the 721 end of the segment with the previous sequence number, where values in 722 a continuous series, such as timestamps and Continuity Counters, 723 continue uninterrupted - unless the media segment was the first ever 724 to appear in the Playlist file or has an EXT-X-DISCONTINUITY tag 725 applied to it. 727 Clients SHOULD be prepared to handle multiple tracks of a particular 728 type (e.g. audio or video). A client with no other preference SHOULD 729 choose the track with the lowest numerical PID that it can play. 731 Clients MUST ignore private streams inside Transport Streams that 732 they do not recognize. 734 The encoding parameters for samples in a stream inside a media 735 segment and between corresponding streams across multiple media 736 segments SHOULD remain consistent. However clients SHOULD deal with 737 encoding changes as they are encountered, for example by scaling 738 video content to accommodate a resolution change. 740 5. Key files 742 5.1. Introduction 744 An EXT-X-KEY tag with a URI attribute identifies a Key file. A Key 745 file contains the cipher key that MUST be used to decrypt subsequent 746 media segments in the Playlist. 748 The AES-128 encryption method uses 16-octet keys. The format of the 749 Key file is a single packed array of 16 octets in binary format. 751 5.2. IV for AES-128 753 128-bit AES requires the same 16-octet Initialization Vector (IV) to 754 be supplied when encrypting and decrypting. Varying this IV 755 increases the strength of the cipher. 757 If the EXT-X-KEY tag has the IV attribute, implementations MUST use 758 the attribute value as the IV when encrypting or decrypting with that 759 key. The value MUST be interpreted as a 128-bit hexadecimal number 760 and MUST be prefixed with 0x or 0X. 762 If the EXT-X-KEY tag does not have the IV attribute, implementations 763 MUST use the sequence number of the media segment as the IV when 764 encrypting or decrypting that media segment. The big-endian binary 765 representation of the sequence number SHALL be placed in a 16-octet 766 buffer and padded (on the left) with zeros. 768 6. Client/Server Actions 770 6.1. Introduction 772 This section describes how the server generates the Playlist and 773 media segments and how the client should download and play them. 775 6.2. Server Process 777 6.2.1. Introduction 779 The production of the MPEG-2 stream is outside the scope of this 780 document, which simply presumes a source of a continuous stream 781 containing the presentation. 783 The server MUST divide the stream into individual media segments 784 whose duration is less than or equal to a constant target duration. 785 The server SHOULD attempt to divide the stream at points that support 786 effective decode of individual media segments, e.g. on packet and key 787 frame boundaries. 789 The server MUST create a URI for every media segment that enables its 790 clients to obtain the segment data. If a server supports partial 791 loading of resources (e.g. via HTTP Range requests), it MAY specify 792 segments as sub-ranges of larger resources using the EXT-X-BYTERANGE 793 tag. 795 The server MUST create a Playlist file. The Playlist file MUST 796 conform to the format described in Section 3. A URI for each media 797 segment that the server wishes to make available MUST appear in the 798 Playlist in the order in which it is to be played. The entire media 799 segment MUST be available to clients if its URI is in the Playlist 800 file. 802 The Playlist file MUST contain an EXT-X-TARGETDURATION tag. Its 803 value MUST be equal to or greater than the EXTINF value of any media 804 segment that appears or will appear in the Playlist file. Its value 805 MUST NOT change. A typical target duration is 10 seconds. 807 The Playlist file SHOULD contain one EXT-X-VERSION tag which 808 indicates the compatibility version of the stream. Its value MUST be 809 the lowest protocol version with which the server, Playlist file, and 810 associated media segments all comply. Its value MUST NOT change. 812 The server MUST create a URI for the Playlist file that will allow 813 its clients to obtain the file. 815 If the Playlist file is distributed by HTTP, the server SHOULD 816 support client requests to use "gzip" Content-Encoding. 818 Changes to the Playlist file MUST be made atomically from the point 819 of view of the clients. 821 The server MUST NOT change the Playlist file, except to: 823 Append lines to it (Section 6.2.1). 825 Remove media URIs from the Playlist in the order that they appear, 826 along with any tags that apply only to those media URIs 827 (Section 6.2.2). 829 Increment the value of the EXT-X-MEDIA-SEQUENCE tag 830 (Section 6.2.2). 832 Add or remove EXT-X-STREAM-INF tags or EXT-X-I-FRAME-STREAM-INF 833 tags (Section 6.2.4). Note that clients are not required to 834 reload variant Playlist files, so changing them may not have 835 immediate effect. 837 Add an EXT-X-ENDLIST tag to the Playlist (Section 6.2.1). 839 Furthermore, the Playlist file MAY contain an EXT-X-PLAYLIST-TYPE tag 840 with a value of either EVENT or VOD. If the tag is present and has a 841 value of EVENT, the server MUST NOT change or delete any part of the 842 Playlist file (although it MAY append lines to it). If the tag is 843 present and has a value of VOD, the Playlist file MUST NOT change. 845 Every media URI in a Playlist MUST have an EXTINF tag applied to it 846 indicating the duration of the media segment. 848 The server MAY associate an absolute date and time with a media 849 segment by applying an EXT-X-PROGRAM-DATE-TIME tag to its URI. The 850 date and time value provides an informative mapping of the timeline 851 of the media to an appropriate wall-clock time, which may be used as 852 a basis for seeking, for display, or for other purposes. If a server 853 provides this mapping, it SHOULD apply an EXT-X-PROGRAM-DATE-TIME tag 854 to every segment that has an EXT-X-DISCONTINUITY tag applied to it. 856 If the Playlist contains the final media segment of the presentation 857 then the Playlist file MUST contain the EXT-X-ENDLIST tag. 859 If the Playlist does not contain the EXT-X-ENDLIST tag, the server 860 MUST make a new version of the Playlist file available that contains 861 at least one new media segment. It MUST be made available relative 862 to the time that the previous version of the Playlist file was made 863 available: no earlier than one-half the target duration after that 864 time, and no later than 1.5 times the target duration after that 865 time. 867 If the server wishes to remove an entire presentation, it MUST make 868 the Playlist file unavailable to clients. It SHOULD ensure that all 869 media segments in the Playlist file remain available to clients for 870 at least the duration of the Playlist file at the time of removal. 872 6.2.2. Sliding Window Playlists 874 The server MAY limit the availability of media segments by removing 875 media URIs from the Playlist file. If media URIs are to be removed, 876 the Playlist file MUST contain exactly one EXT-X-MEDIA-SEQUENCE tag. 877 Its value MUST be incremented by 1 for every media URI that is 878 removed from the Playlist file. 880 Media URIs MUST be removed from the Playlist file in the order that 881 they appear in the Playlist. 883 The server MUST NOT remove a media URI specifying a segment from the 884 Playlist file if the duration of the Playlist file minus the duration 885 of the segment is less than three times the target duration. 887 When the server removes a media URI from the Playlist, the 888 corresponding media segment SHOULD remain available to clients for a 889 period of time equal to the duration of the segment plus the duration 890 of the longest Playlist file distributed by the server containing 891 that segment. 893 If a server plans to remove a media segment after it is delivered to 894 clients over HTTP, it SHOULD ensure that the HTTP response contains 895 an Expires header that reflects the planned time-to-live. 897 6.2.3. Encrypting media segments 899 If media segments are to be encrypted the server MUST define a URI 900 which will allow authorized clients to obtain a Key file containing a 901 decryption key. The Key file MUST conform to the format described in 902 Section 5. 904 The server MAY set the HTTP Expires header in the key response to 905 indicate that the key may be cached. 907 The server MUST encrypt every media segment in a Playlist according 908 to the EXT-X-KEY tag that applies to its URI in the Playlist file. 909 Media segments with an EXT-X-KEY tag whose METHOD is NONE, or which 910 do not have an EXT-X-KEY tag applied to them, MUST NOT be encrypted. 912 If the encryption METHOD is AES-128 and the Playlist does not contain 913 the EXT-X-I-FRAMES-ONLY tag, AES-128 CBC encryption with PKCS7 914 padding [RFC5652] SHALL be applied to individual media segments. The 915 entire segment MUST be encrypted. Cipher Block Chaining MUST NOT be 916 applied across media segments. The IV used for encryption MUST be 917 either the sequence number of the media segment or the value of the 918 IV attribute of the EXT-X-KEY tag, as described in Section 5.2. 920 If the encryption METHOD is AES-128 and the Playlist contains an EXT- 921 X-I-FRAMES-ONLY tag, AES-128 CBC encryption with PKCS7 padding 922 [RFC5652] MUST be applied to the entire media resource. The entire 923 resource MUST be encrypted. Encryption MAY be restarted on 16-byte 924 block boundaries, unless the first block contains an I-frame. The IV 925 used for encryption MUST be either the sequence number of the media 926 segment or the value of the IV attribute of the EXT-X-KEY tag, as 927 described in Section 5.2. 929 The server MUST NOT remove an EXT-X-KEY tag from the Playlist file if 930 it applies to any media URI in the Playlist file. 932 6.2.4. Providing variant streams 934 A server MAY offer multiple Playlist files to provide different 935 encodings of the same presentation. If it does so it SHOULD provide 936 a variant Playlist file that lists each variant stream to allow 937 clients to switch between encodings dynamically. 939 Variant Playlists MUST contain an EXT-X-STREAM-INF tag or EXT-X-I- 940 FRAME-STREAM-INF tag for each variant stream. Each tag identifying 941 an encoding of the same presentation MUST have the same PROGRAM-ID 942 attribute value. The PROGRAM-ID value for each presentation MUST be 943 unique within the variant Playlist. 945 If an EXT-X-STREAM-INF tag or EXT-X-I-FRAME-STREAM-INF tag contains 946 the CODECS attribute, the attribute value MUST include every format 947 defined by [RFC6381] that is present in any media segment that 948 appears or will appear in the Playlist file. 950 The server MUST meet the following constraints when producing variant 951 streams: 953 Each variant stream MUST present the same content, including 954 stream discontinuities. 956 Each variant Playlist file MUST have the same target duration. 958 Content that appears in one variant Playlist file but not in 959 another MUST appear either at the beginning or at the end of the 960 Playlist file and MUST NOT be longer than the target duration. 962 Matching content in variant streams MUST have matching timestamps. 963 This allows clients to synchronize the streams. 965 Each Elementary Audio Stream segment MUST signal the timestamp of 966 its first sample with an ID3 PRIV tag [ID3] at the beginning of 967 the segment. The ID3 PRIV owner identifier MUST be 968 "com.apple.streaming.transportStreamTimestamp". The ID3 payload 969 MUST be a 33-bit MPEG-2 Program Elementary Stream timestamp 970 expressed as a big-endian eight-octet number, with the upper 31 971 bits set to zero. 973 In addition, all variant streams SHOULD contain the same encoded 974 audio bitstream. This allows clients to switch between streams 975 without audible glitching. 977 6.3. Client Process 979 6.3.1. Introduction 981 How the client obtains the URI to the Playlist file is outside the 982 scope of this document; it is presumed to have done so. 984 The client MUST obtain the Playlist file from the URI. If the 985 Playlist file so obtained is a variant Playlist, the client MUST 986 obtain the Playlist file from the variant Playlist. 988 This document does not specify the treatment of variant streams by 989 clients. 991 6.3.2. Loading the Playlist file 993 Every time a Playlist file is loaded or reloaded from the Playlist 994 URI: 996 The client MUST ensure that the Playlist file begins with the 997 EXTM3U tag and that the EXT-X-VERSION tag, if present, specifies a 998 protocol version supported by the client; if not, the client MUST 999 NOT attempt to use the Playlist. 1001 The client SHOULD ignore any tags and attributes it does not 1002 recognize. 1004 The client MUST determine the next media segment to load, as 1005 described in Section 6.3.5. 1007 If the Playlist contains the EXT-X-MEDIA-SEQUENCE tag, the client 1008 SHOULD assume that each media segment in it will become unavailable 1009 at the time that the Playlist file was loaded plus the duration of 1010 the Playlist file. 1012 6.3.3. Playing the Playlist file 1014 The client SHALL choose which media segment to play first from the 1015 Playlist when playback starts. If the EXT-X-ENDLIST tag is not 1016 present and the client intends to play the media regularly (i.e. in 1017 playlist order at the nominal playback rate), the client SHOULD NOT 1018 choose a segment which starts less than three target durations from 1019 the end of the Playlist file. Doing so can trigger playback stalls. 1021 To achieve regular playback, media segments MUST be played in the 1022 order that they appear in the Playlist file. The client MAY present 1023 the available media in any way it wishes, including regular playback, 1024 random access, and trick modes. 1026 The client MUST be prepared to reset its parser(s) and decoder(s) 1027 before playing a media segment that has an EXT-X-DISCONTINUITY tag 1028 applied to it. 1030 The client SHOULD attempt to load media segments in advance of when 1031 they will be required for uninterrupted playback to compensate for 1032 temporary variations in latency and throughput. 1034 If the Playlist file contains the EXT-X-ALLOW-CACHE tag and its value 1035 is NO, the client MUST NOT cache downloaded media segments after they 1036 have been played. Otherwise the client MAY cache downloaded media 1037 segments indefinitely for later replay. 1039 The client MAY use the value of the EXT-X-PROGRAM-DATE-TIME tag to 1040 display the program origination time to the user. If the value 1041 includes time zone information the client SHALL take it into account, 1042 but if it does not the client MUST NOT infer an originating time 1043 zone. 1045 The client MUST NOT depend upon the correctness or the consistency of 1046 the value of the EXT-X-PROGRAM-DATE-TIME tag. 1048 6.3.4. Reloading the Playlist file 1050 The client MUST periodically reload the Playlist file unless it 1051 contains the EXT-X-ENDLIST tag. 1053 However the client MUST NOT attempt to reload the Playlist file more 1054 frequently than specified by this section. 1056 When a client loads a Playlist file for the first time or reloads a 1057 Playlist file and finds that it has changed since the last time it 1058 was loaded, the client MUST wait for a period of time before 1059 attempting to reload the Playlist file again. This period is called 1060 the initial minimum reload delay. It is measured from the time that 1061 the client began loading the Playlist file. 1063 The initial minimum reload delay is the duration of the last media 1064 segment in the Playlist. Media segment duration is specified by the 1065 EXTINF tag. 1067 If the client reloads a Playlist file and finds that it has not 1068 changed then it MUST wait for a period of one-half the target 1069 duration before retrying. 1071 In order to reduce server load, the client SHOULD NOT reload the 1072 Playlist files of variant streams that are not currently being 1073 played. If it decides to switch playback to a different variant, it 1074 SHOULD stop reloading the Playlist of the old variant and begin 1075 loading the Playlist of the new variant. It can use the EXTINF 1076 durations and the constraints in Section 6.2.4 to determine the 1077 approximate location of corresponding media. Once media from the new 1078 variant has been loaded, the timestamps in the media segments can be 1079 used to synchronize the old and new timelines precisely. 1081 6.3.5. Determining the next segment to load 1083 The client MUST examine the Playlist file every time it is loaded or 1084 reloaded to determine the next media segment to load. 1086 The first segment to load MUST be the segment that the client has 1087 chosen to play first, as described in Section 6.3.3. 1089 If the first segment to be played has been loaded and the Playlist 1090 file does not contain the EXT-X-MEDIA-SEQUENCE tag then the client 1091 MUST verify that the current Playlist file contains the URI of the 1092 last loaded media segment at the offset it was originally found at, 1093 halting playback if it does not. The next media segment to load MUST 1094 be the first media URI following the last-loaded URI in the Playlist. 1096 If the first segment to be played has been loaded and the Playlist 1097 file contains the EXT-X-MEDIA-SEQUENCE tag then the next media 1098 segment to load SHALL be the one with the lowest sequence number that 1099 is greater than the sequence number of the last media segment loaded. 1101 6.3.6. Decrypting encrypted media segments 1103 If a Playlist file contains an EXT-X-KEY tag that specifies a Key 1104 file URI, the client MUST obtain that key file and use the key inside 1105 it to decrypt all media segments to which that EXT-X-KEY tag applies. 1107 If the encryption METHOD is AES-128, AES-128 CBC decryption SHALL be 1108 applied to individual media segments. The entire segment MUST be 1109 decrypted. Cipher Block Chaining MUST NOT be applied across media 1110 segments. The IV used for decryption MUST be either the sequence 1111 number of the media segment or the value of the IV attribute of the 1112 EXT-X-KEY tag, as described in Section 5.2. 1114 If the media segment is part of an I-frame playlist (Section 3.4.12) 1115 special care MUST be taken in loading and decrypting the segment, 1116 because the resource identified by the URI is encrypted in 16-byte 1117 blocks from offset 0. The sub-range specified by the EXT-X-BYTERANGE 1118 tag MUST be widened to include the 16-byte blocks in which the 1119 beginning and end of the sub-range fall. Next, it MUST be widened 1120 further to include the previous 16-byte block. That range MUST be 1121 loaded and decrypted with AES-128 CBC using an arbitrary IV. The 1122 decrypted segment will then be the sub-range specified by the EXT-X- 1123 BYTERANGE tag. 1125 An EXT-X-KEY tag with a METHOD of NONE indicates that the media 1126 segments it applies to are not encrypted. 1128 7. Protocol version compatibility 1130 Clients and servers MUST implement protocol version 2 or higher to 1131 use: 1133 o The IV attribute of the EXT-X-KEY tag. 1135 Clients and servers MUST implement protocol version 3 or higher to 1136 use: 1138 o Floating-point EXTINF duration values. 1140 Clients and servers MUST implement protocol version 4 or higher to 1141 use: 1143 o The EXT-X-BYTERANGE tag. 1145 o The EXT-X-I-FRAME-STREAM-INF tag. 1147 o The EXT-X-I-FRAMES-ONLY tag. 1149 o The EXT-X-MEDIA tag. 1151 o The AUDIO and VIDEO attributes of the EXT-X-STREAM-INF tag. 1153 8. Examples 1154 8.1. Introduction 1156 This section contains several example Playlist files. 1158 8.2. Simple Playlist file 1160 #EXTM3U 1161 #EXT-X-TARGETDURATION:5220 1162 #EXTINF:5220, 1163 http://media.example.com/entire.ts 1164 #EXT-X-ENDLIST 1166 8.3. Sliding Window Playlist, using HTTPS 1168 #EXTM3U 1169 #EXT-X-TARGETDURATION:8 1170 #EXT-X-MEDIA-SEQUENCE:2680 1172 #EXTINF:8, 1173 https://priv.example.com/fileSequence2680.ts 1174 #EXTINF:8, 1175 https://priv.example.com/fileSequence2681.ts 1176 #EXTINF:8, 1177 https://priv.example.com/fileSequence2682.ts 1179 8.4. Playlist file with encrypted media segments 1181 #EXTM3U 1182 #EXT-X-MEDIA-SEQUENCE:7794 1183 #EXT-X-TARGETDURATION:15 1185 #EXT-X-KEY:METHOD=AES-128,URI="https://priv.example.com/key.php?r=52" 1187 #EXTINF:15, 1188 http://media.example.com/fileSequence52-1.ts 1189 #EXTINF:15, 1190 http://media.example.com/fileSequence52-2.ts 1191 #EXTINF:15, 1192 http://media.example.com/fileSequence52-3.ts 1194 #EXT-X-KEY:METHOD=AES-128,URI="https://priv.example.com/key.php?r=53" 1196 #EXTINF:15, 1197 http://media.example.com/fileSequence53-1.ts 1199 8.5. Variant Playlist file 1201 #EXTM3U 1202 #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1280000 1203 http://example.com/low.m3u8 1204 #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=2560000 1205 http://example.com/mid.m3u8 1206 #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=7680000 1207 http://example.com/hi.m3u8 1208 #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=65000,CODECS="mp4a.40.5" 1209 http://example.com/audio-only.m3u8 1211 8.6. Variant Playlist with I-Frames 1213 In this example, the PROGRAM-ID attributes have been left out: 1215 #EXTM3U 1216 #EXT-X-STREAM-INF:BANDWIDTH=1280000 1217 low/audio-video.m3u8 1218 #EXT-X-I-FRAME-STREAM-INF:BANDWIDTH=86000,URI="low/iframe.m3u8" 1219 #EXT-X-STREAM-INF:BANDWIDTH=2560000 1220 mid/audio-video.m3u8 1221 #EXT-X-I-FRAME-STREAM-INF:BANDWIDTH=150000,URI="mid/iframe.m3u8" 1222 #EXT-X-STREAM-INF:BANDWIDTH=7680000 1223 hi/audio-video.m3u8 1224 #EXT-X-I-FRAME-STREAM-INF:BANDWIDTH=550000,URI="hi/iframe.m3u8" 1225 #EXT-X-STREAM-INF:BANDWIDTH=65000,CODECS="mp4a.40.5" 1226 audio-only.m3u8 1228 8.7. Variant Playlist with Alternative audio 1230 In this example, the PROGRAM-ID attributes have been left out. The 1231 CODECS attributes have been condensed for space. A '\' is used to 1232 indicate that the tag continues on the following line with whitespace 1233 removed: 1235 #EXTM3U 1236 #EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="aac",NAME="English", \ 1237 DEFAULT=YES,AUTOSELECT=YES,LANGUAGE="en", \ 1238 URI="main/english-audio.m3u8" 1239 #EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="aac",NAME="Deutsche", \ 1240 DEFAULT=NO,AUTOSELECT=YES,LANGUAGE="de", \ 1241 URI="main/german-audio.m3u8" 1242 #EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="aac",NAME="Commentary", \ 1243 DEFAULT=NO,AUTOSELECT=NO,URI="commentary/audio-only.m3u8" 1244 #EXT-X-STREAM-INF:BANDWIDTH=1280000,CODECS="...",AUDIO="aac" 1245 low/video-only.m3u8 1246 #EXT-X-STREAM-INF:BANDWIDTH=2560000,CODECS="...",AUDIO="aac" 1247 mid/video-only.m3u8 1248 #EXT-X-STREAM-INF:BANDWIDTH=7680000,CODECS="...",AUDIO="aac" 1249 hi/video-only.m3u8 1250 #EXT-X-STREAM-INF:BANDWIDTH=65000,CODECS="mp4a.40.5",AUDIO="aac" 1251 main/english-audio.m3u8 1253 8.8. Variant Playlist with Alternative video 1255 In this example, the PROGRAM-ID attributes have been left out. The 1256 CODECS attributes have been condensed for space. A '\' is used to 1257 indicate that the tag continues on the following line with whitespace 1258 removed: 1260 #EXTM3U 1261 #EXT-X-MEDIA:TYPE=VIDEO,GROUP-ID="low",NAME="Main", \ 1262 DEFAULT=YES,URI="low/main/audio-video.m3u8" 1263 #EXT-X-MEDIA:TYPE=VIDEO,GROUP-ID="low",NAME="Centerfield", \ 1264 DEFAULT=NO,URI="low/centerfield/audio-video.m3u8" 1265 #EXT-X-MEDIA:TYPE=VIDEO,GROUP-ID="low",NAME="Dugout", \ 1266 DEFAULT=NO,URI="low/dugout/audio-video.m3u8" 1268 #EXT-X-STREAM-INF:BANDWIDTH=1280000,CODECS="...",VIDEO="low" 1269 low/main/audio-video.m3u8 1271 #EXT-X-MEDIA:TYPE=VIDEO,GROUP-ID="mid",NAME="Main", \ 1272 DEFAULT=YES,URI="mid/main/audio-video.m3u8" 1273 #EXT-X-MEDIA:TYPE=VIDEO,GROUP-ID="mid",NAME="Centerfield", \ 1274 DEFAULT=NO,URI="mid/centerfield/audio-video.m3u8" 1275 #EXT-X-MEDIA:TYPE=VIDEO,GROUP-ID="mid",NAME="Dugout", \ 1276 DEFAULT=NO,URI="mid/dugout/audio-video.m3u8" 1278 #EXT-X-STREAM-INF:BANDWIDTH=2560000,CODECS="...",VIDEO="mid" 1279 mid/main/audio-video.m3u8 1281 #EXT-X-MEDIA:TYPE=VIDEO,GROUP-ID="hi",NAME="Main", \ 1282 DEFAULT=YES,URI="hi/main/audio-video.m3u8" 1283 #EXT-X-MEDIA:TYPE=VIDEO,GROUP-ID="hi",NAME="Centerfield", \ 1284 DEFAULT=NO,URI="hi/centerfield/audio-video.m3u8" 1285 #EXT-X-MEDIA:TYPE=VIDEO,GROUP-ID="hi",NAME="Dugout", \ 1286 DEFAULT=NO,URI="hi/dugout/audio-video.m3u8" 1288 #EXT-X-STREAM-INF:BANDWIDTH=7680000,CODECS="...",VIDEO="hi" 1289 hi/main/audio-video.m3u8 1291 #EXT-X-STREAM-INF:BANDWIDTH=65000,CODECS="mp4a.40.5" 1292 main/audio-only.m3u8 1294 9. Contributors 1296 Significant contributions to the design of this protocol were made by 1297 Jim Batson, David Biderman, Bill May, Roger Pantos, and Alan Tseng. 1299 10. IANA Considerations 1301 This memo requests that the following MIME type [RFC2046] be 1302 registered with the IANA: 1304 Type name: "application" 1305 Subtype name: "vnd.apple.mpegurl" 1307 Required parameters: (none) 1309 Optional parameters: (none) 1311 Encoding considerations: encoded as text. See Section 3 for more 1312 information. 1314 Security considerations: See Section 11. 1316 Compression: this media type does not employ compression. 1318 Interoperability considerations: There are no byte-ordering issues, 1319 since files are 7- or 8-bit text. Applications could encounter 1320 unrecognized tags, which SHOULD be ignored. 1322 Published specification: see Section 3. 1324 Applications that use this media type: Multimedia applications such 1325 as the iPhone media player in iOS 3.0 and later and QuickTime Player 1326 in Mac OS X version 10.6 and later. 1328 Additional information: files begin with the magic number #EXTM3U. 1329 Filenames normally end with .m3u8 or .m3u (see Section 3). No 1330 Macintosh file type codes have been registered. 1332 Person & email address to contact for further information: David 1333 Singer, singer AT apple.com. 1335 Intended usage: LIMITED USE 1337 Restrictions on usage: (none) 1339 Author: Roger Pantos 1341 Change Controller: David Singer 1343 11. Security Considerations 1345 Since the protocol generally uses HTTP to transfer data, most of the 1346 same security considerations apply. See section 15 of RFC 2616 1347 [RFC2616]. 1349 Media file parsers are typically subject to "fuzzing" attacks. 1350 Clients SHOULD take care when parsing segments received from a server 1351 that non-compliant segments are rejected. 1353 Playlist files contain URIs, which clients will use to make network 1354 requests of arbitrary entities. Clients SHOULD range-check responses 1355 to prevent buffer overflows. See also the Security Considerations 1356 section of RFC 3986 [RFC3986]. 1358 Clients SHOULD load resources identified by URI lazily to avoid 1359 contributing to denial-of-service attacks. 1361 HTTP requests often include session state ("cookies"), which may 1362 contain private user data. Implementations MUST follow cookie 1363 restriction and expiry rules specified by RFC 6265 [RFC6265]. See 1364 also the Security Considerations section of RFC 6265, and RFC 2964 1365 [RFC2964]. 1367 Encryption keys are specified by URI. The delivery of these keys 1368 SHOULD be secured by a mechanism such as HTTP over TLS [RFC5246] 1369 (formerly SSL) in conjunction with a secure realm or a session 1370 cookie. 1372 12. References 1374 12.1. Normative References 1376 [AES_128] U.S. Department of Commerce/National Institute of 1377 Standards and Technology, "Advanced Encryption Standard 1378 (AES), FIPS PUB 197", November 2001, <http:// 1379 csrc.nist.gov/publications/fips/fips197/fips-197.pdf>. 1381 [ISO_13818] 1382 International Organization for Standardization, "ISO/IEC 1383 International Standard 13818; Generic coding of moving 1384 pictures and associated audio information", October 2007, 1385 <http://www.iso.org/iso/catalogue_detail?csnumber=44169>. 1387 [ISO_8601] 1388 International Organization for Standardization, "ISO/IEC 1389 International Standard 8601:2004; Data elements and 1390 interchange formats -- Information interchange -- 1391 Representation of dates and times", December 2004, 1392 <http://www.iso.org/iso/catalogue_detail?csnumber=40874>. 1394 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1395 Extensions (MIME) Part Two: Media Types", RFC 2046, 1396 November 1996. 1398 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1399 Requirement Levels", BCP 14, RFC 2119, March 1997. 1401 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1402 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1403 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1405 [RFC2964] Moore, K. and N. Freed, "Use of HTTP State Management", 1406 BCP 44, RFC 2964, October 2000. 1408 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1409 10646", STD 63, RFC 3629, November 2003. 1411 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1412 Resource Identifier (URI): Generic Syntax", STD 66, 1413 RFC 3986, January 2005. 1415 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1416 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1418 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying 1419 Languages", BCP 47, RFC 5646, September 2009. 1421 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1422 RFC 5652, September 2009. 1424 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 1425 April 2011. 1427 [RFC6381] Gellens, R., Singer, D., and P. Frojdh, "The 'Codecs' and 1428 'Profiles' Parameters for "Bucket" Media Types", RFC 6381, 1429 August 2011. 1431 [US_ASCII] 1432 American National Standards Institute, "ANSI X3.4-1986, 1433 Information Systems -- Coded Character Sets 7-Bit American 1434 National Standard Code for Information Interchange (7-Bit 1435 ASCII)", December 1986. 1437 12.2. Informative References 1439 [ID3] ID3.org, "The ID3 audio file data tagging format", 1440 <http://www.id3.org/Developer_Information>. 1442 [M3U] Nullsoft, Inc., "The M3U Playlist format, originally 1443 invented for the Winamp media player", 1444 <http://wikipedia.org/wiki/M3U>. 1446 Authors' Addresses 1448 Roger Pantos (editor) 1449 Apple Inc. 1450 Cupertino, California 1451 United States 1453 Email: http-live-streaming-review@group.apple.com 1455 William May, Jr. 1456 Apple Inc. 1457 Cupertino, California 1458 United States 1460 Email: http-live-streaming-review@group.apple.com