HLS协议草案（中文翻译）
文档的内容原样摘自苹果提交给IETF的第4个HLS草案
Informational R. Pantos, Ed.
Internet-Draft W. May
Intended status: Informational Apple Inc.
Expires: December 7, 2010 June 5, 2010
HTTP Live Streaming
draft-pantos-http-live-streaming-04
Abstract
[译]摘要
This document describes a protocol for transferring unbounded streams
of multimedia data. It specifies the data format of the files and
the actions to be taken by the server (sender) and the clients
(receivers) of the streams. It describes version 2 of this protocol.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, and it may not be
published except as an Internet-Draft.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker\.ietf\.org/drafts/current/\.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as “work in progress.“
This Internet-Draft will expire on December 7, 2010.
Copyright Notice
[译]版权说明
Copyright (c) 2010 IETF Trust and the persons identified as the
Pantos & May Expires December 7, 2010 [Page 1]
Internet-Draft HTTP Live Streaming June 2010
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust’s Legal
Provisions Relating to IETF Documents
(http://trustee\.ietf\.org/license\-info\) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Pursuant to Section 8.f. of the Legal Provisions (see the IETF
Trust’s Legal Provisions Relating to IETF Documents effective
December 28, 2009), Section 4 of the Legal Provisions does not apply
to this document. Thus, to the extent that this Informational
Internet Draft contains one or more Code Components, no license to
such Code Components is granted. Furthermore, this document may not
be modified, and derivative works of it may not be created, and it
may not be published except as an Internet-Draft.
Furthermore, this Informational Internet Draft is submitted as an RFC
Editor Contribution and/or non-IETF Document (not as a Contribution,
IETF Contribution, nor IETF Document) in accordance with BCP 78 and
BCP 79.
Pantos & May Expires December 7, 2010 [Page 2]
Internet-Draft HTTP Live Streaming June 2010
Table of Contents
[译]目录结构
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
[译]1. 简介
2. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
[译]2. 概述
3. The Playlist file . . . . . . . . . . . . . . . . . . . . . . 4
[译]3. 播放列表文件
3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
[译]3.1. 简介
3.2. New Tags . . . . . . . . . . . . . . . . . . . . . . . . . 5
[译]3.2. 新标签
3.2.1. EXT-X-TARGETDURATION . . . . . . . . . . . . . . . . . 6
[译]3.2.1. EXT-X-TARGETDURATION
3.2.2. EXT-X-MEDIA-SEQUENCE . . . . . . . . . . . . . . . . . 6
[译]3.2.2. EXT-X-MEDIA-SEQUENCE
3.2.3. EXT-X-KEY . . . . . . . . . . . . . . . . . . . . . . 6
[译]3.2.3. EXT-X-KEY
3.2.4. EXT-X-PROGRAM-DATE-TIME . . . . . . . . . . . . . . . 7
[译]3.2.4. EXT-X-PROGRAM-DATE-TIME
3.2.5. EXT-X-ALLOW-CACHE . . . . . . . . . . . . . . . . . . 7
[译]3.2.5. EXT-X-ALLOW-CACHE
3.2.6. EXT-X-ENDLIST . . . . . . . . . . . . . . . . . . . . 7
[译]3.2.6. EXT-X-ENDLIST
3.2.7. EXT-X-STREAM-INF . . . . . . . . . . . . . . . . . . . 8
[译]3.2.7. EXT-X-STREAM-INF
3.2.8. EXT-X-DISCONTINUITY . . . . . . . . . . . . . . . . . 8
[译]3.2.8. EXT-X-DISCONTINUITY
3.2.9. EXT-X-VERSION . . . . . . . . . . . . . . . . . . . . 9
[译]3.2.9. EXT-X-VERSION
4. Media files . . . . . . . . . . . . . . . . . . . . . . . . . 9
[译]4. 媒体文件
5. Key files . . . . . . . . . . . . . . . . . . . . . . . . . . 10
[译]5. 密钥文件
5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 10
[译]5.1. 介绍
5.2. IV for AES-128 . . . . . . . . . . . . . . . . . . . . . . 10
[译]5.2. AES-128的初始化向量
6. Client/Server Actions . . . . . . . . . . . . . . . . . . . . 11
[译]6. 客户端/服务器处理
6.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 11
[译]6.1. 介绍
6.2. Server Process . . . . . . . . . . . . . . . . . . . . . . 11
[译]6.2. 服务器处理
6.2.1. Introduction . . . . . . . . . . . . . . . . . . . . . 11
[译]6.2.1. 介绍
6.2.2. Sliding Window Playlists . . . . . . . . . . . . . . . 12
[译]6.2.2. 播放列表的滑动窗口
6.2.3. Encrypting media files . . . . . . . . . . . . . . . . 13
[译]6.2.3. 加密媒体文件
6.2.4. Providing variant streams . . . . . . . . . . . . . . 13
[译]6.2.4. 提供可变码流
6.3. Client Process . . . . . . . . . . . . . . . . . . . . . . 14
[译]6.3. 客户端处理
6.3.1. Introduction . . . . . . . . . . . . . . . . . . . . . 14
[译]6.3.1. 介绍
6.3.2. Loading the Playlist file . . . . . . . . . . . . . . 14
[译]6.3.2. 加载播放列表
6.3.3. Playing the Playlist file . . . . . . . . . . . . . . 15
[译]6.3.3. 播放播放列表文件
6.3.4. Reloading the Playlist file . . . . . . . . . . . . . 16
[译]6.3.4. 重载播放列表文件
6.3.5. Determining the next file to load . . . . . . . . . . 16
[译]6.3.5. 确定下一个要加载的文件
6.3.6. Decrypting encrypted media files . . . . . . . . . . . 16
[译]6.3.6. 解密加密的媒体文件
7. Protocol version compatibility . . . . . . . . . . . . . . . . 17
[译]7. 协议版本的兼容性
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
[译]8. 示例
8.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 17
[译]8.1. 介绍
8.2. Simple Playlist file . . . . . . . . . . . . . . . . . . . 17
[译]8.2. 播放列表文件示例
8.3. Sliding Window Playlist, using HTTPS . . . . . . . . . . . 18
[译]8.3. 使用HTTPS的滑动窗口播放列表
8.4. Playlist file with encrypted media files . . . . . . . . . 18
[译]8.4. 包含加密媒体文件的播放列表
8.5. Variant Playlist file . . . . . . . . . . . . . . . . . . 18
[译]8.5. 可变播放列表文件
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19
[译]9. 贡献者
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
[译]10. IANA 注意事项
11. Security Considerations . . . . . . . . . . . . . . . . . . . 20
[译]11. 安全注意事项
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
[译]12. 引用
12.1. Normative References . . . . . . . . . . . . . . . . . . . 20
[译]12.1. 规范引用
12.2. Informative References . . . . . . . . . . . . . . . . . . 22
[译]12.2. 信息引用
Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
[译]作者地址
Pantos & May Expires December 7, 2010 [Page 3]
Internet-Draft HTTP Live Streaming June 2010
1. Introduction
[译]1. 简介
This document describes a protocol for transferring unbounded streams
of multimedia data. The protocol supports the encryption of media
data and the provision of alternate versions (e.g. bitrates) of a
stream. Media data can be transferred soon after it is created,
allowing it to be played in near real-time. Data is usually carried
over HTTP [RFC2616].
[译]本文档介绍了一种建立在HTTP [RFC2616]之上的多媒体数据流传输协议。该协议支持对媒体数据的加密，并提供流的替换版本（如不同比特率的流）。媒体数据在创建后可以被快速地传输，达到几乎实时的播放。
External references that describe related standards such as HTTP are
listed in Section 11.
[译]在第11章中，介绍了相关标准的外部引用，如HTTP协议。
2. Summary
[译]2. 概述
A multimedia presentation is specified by a URI [RFC3986] to a
Playlist file, which is an ordered list of media URIs and
informational tags. Each media URI refers to a media file which is a
segment of a single contiguous stream.
[译]多媒体演示文稿是由播放列表中的URI [RFC3986]指定的，播放列表是一个由URI和信息标签组成的有序列表。每一个媒体URI都指向一个媒体文件，该媒体文件是一个连续数据流的一个分片。
To play the stream, the client first obtains the Playlist file and
then obtains and plays each media file in the Playlist. It reloads
the Playlist file as described in this document to discover
additional segments.
[译]为了播放数据流，客户端首选要获取播放列表文件，然后获取并播放列表中的每一个媒体文件。正如本文档所描述的那样，客户端通过重载播放列表文件来发现新增的分片。
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”,
“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this
document are to be interpreted as described in RFC 2119 [RFC2119].
[译]本文档中的关键词“必须”，“不准”，“需要”，“应该”，“不应该”，“应该”，“不应该”,“推荐”，“可能”，“可选”的解释参照 RFC2119 文档中对应的描述。
3. The Playlist file
[译]3. 播放列表文件
3.1. Introduction
[译]3.1. 简介
Playlists MUST be Extended M3U Playlist files [M3U]. This document
extends the M3U file format by defining additional tags.
[译]播放列表文件必须是扩展的M3U文件。该文档通过定义新的标签扩展了M3U文件的格式。
An M3U Playlist is a text file that consists of individual lines.
Lines are terminated by either a single LF character or a CR
character followed by an LF character. Each line is a URI, a blank,
or starts with the comment character ‘#‘. Blank lines are ignored.
White space MUST NOT be present, except for elements in which it is
explicitly specified.
[译]M3U播放列表是一个文本文件，由多个独立的行组成。每一行以 LF 或 CR+LF 作为结束标识。行可以是一个URI，空行，或以注释字符#开头。空行将会被忽略。空格只能作为特殊指定的元素出现。
A URI line identifies a media file or a variant Playlist file (see
Section 3.2.7).
[译]一个URI行表示一个媒体文件，或播放列表文件（见3.2.7章节）。
URIs MAY be relative. A relative URI MUST be resolved against the
[译]URI可以是相对地址。一个相对地址的URI必须能够被解析，借助于包含它的播放列表文件的URI。
Pantos & May Expires December 7, 2010 [Page 4]
Internet-Draft HTTP Live Streaming June 2010
URI of the Playlist file that contains it.
Lines that start with the comment character ‘#‘ are either comments
or tags. Tags begin with #EXT. All other lines that begin with ‘#‘
are comments and SHOULD be ignored.
[译]以字符#开头的行，可能是注释或标签。标签以#EXT开头。除标签以外的以#开头的注释行都应该被忽略。
The duration of a Playlist file is the sum of the durations of the
media files within it.
[译]播放列表文件的持续时间，是它所包含的所有媒体文件的持续时间的总和。
M3U Playlist files whose names end in .m3u8 and/or have the HTTP
Content-Type “application/vnd.apple.mpegurl” are encoded in UTF-8
[RFC3629]. Files whose names end with .m3u and/or have the HTTP
Content-Type [RFC2616] “audio/mpegurl” are encoded in US-ASCII
[US_ASCII].
Playlist files MUST have names that end in .m3u8 and/or have the
Content-Type “application/vnd.apple.mpegurl” (if transferred over
HTTP), or have names that end in .m3u and/or have the HTTP Content-
Type type “audio/mpegurl” (for compatibility).
[译]播放列表文件名必须以.m3u8作为后缀，和/或使用”application/vnd.apple.mpegurl”作为Content-Type（如果使用HTTP传输）；或者必须以.m3u作为后缀，和/或使用”audio/mpegurl”作为HTTP Content-Type。
The Extended M3U file format defines two tags: EXTM3U and EXTINF. An
Extended M3U file is distinguished from a basic M3U file by its first
line, which MUST be #EXTM3U.
[译]扩展的M3U文件格式扩展了两个标签：EXTM3U和EXTINF。区分扩展的M3U文件和普通M3U文件，只需要看文件的第一行是否为#EXTM3U。
EXTINF is a record marker that describes the media file identified by
the URI that follows it. Each media file URI MUST be preceded by an
EXTINF tag. Its format is:
[译]EXTINF是记录标记，描述了下一行的URI指向的媒体文件。每一个媒体文件URI的上一行必须是EXTINF标签。格式如下：
#EXTINF:<duration>,<title>
“duration” is an integer that specifies the duration of the media
file in seconds. Durations SHOULD be rounded to the nearest integer.
The remainder of the line following the comma is the title of the
media file, which is an optional human-readable informative title of
the media segment.
[译]duration是一个整数，指定了媒体文件的持续时间，以秒为单位。持续时间应该四舍五入到最接近的整数。该行逗号后面的部分是媒体文件的标题，是该媒体分片的适宜阅读的标题信息。
This document defines the following new tags: EXT-X-TARGETDURATION,
EXT-X-MEDIA-SEQUENCE, EXT-X-KEY, EXT-X-PROGRAM-DATE-TIME, EXT-X-
ALLOW-CACHE, EXT-X-STREAM-INF, EXT-X-ENDLIST, EXT-X-DISCONTINUITY,
and EXT-X-VERSION.
[译]该文档定义了如下的新标签：EXT-X-TARGETDURATION, EXT-X-MEDIA-SEQUENCE, EXT-X-KEY, EXT-X-PROGRAM-DATE-TIME, EXT-X-ALLOW-CACHE, EXT-X-STREAM-INF, EXT-X-ENDLIST, EXT-X-DISCONTINUITY, EXT-X-VERSION。
3.2. New Tags
[译]3.2. 新标签
Pantos & May Expires December 7, 2010 [Page 5]
Internet-Draft HTTP Live Streaming June 2010
3.2.1. EXT-X-TARGETDURATION
[译]3.2.1. EXT-X-TARGETDURATION
The EXT-X-TARGETDURATION tag specifies the maximum media file
duration. The EXTINF duration of each media file in the Playlist
file MUST be less than or equal to the target duration. This tag
MUST appear once in the Playlist file. Its format is:
[译]该标签指定了媒体文件的持续时间的最大值。播放列表文件中的每一个媒体文件的EXTINF持续时间都必须小于等于该标签指定的持续时间。该标签必须在播放列表中出现一次。格式如下：
#EXT-X-TARGETDURATION:<s>
where s is an integer indicating the target duration in seconds.
[译]s是一个整数，代表了目标持续时间的秒数。
3.2.2. EXT-X-MEDIA-SEQUENCE
[译]3.2.2. EXT-X-MEDIA-SEQUENCE
Each media file URI in a Playlist has a unique sequence number. The
sequence number of a URI is equal to the sequence number of the URI
that preceded it plus one. The EXT-X-MEDIA-SEQUENCE tag indicates
the sequence number of the first URI that appears in a Playlist file.
Its format is:
[译]播放列表文件中的每个媒体文件的URI都有一个唯一的序列号。URI的序列号等于它前一个URI的序列号加一。该标签指定了出现在播放列表中的第一个URI的序列号。格式如下：
#EXT-X-MEDIA-SEQUENCE:<number>
A Playlist file MUST NOT contain more than one EXT-X-MEDIA-SEQUENCE
tag. If the Playlist file does not contain an EXT-X-MEDIA-SEQUENCE
tag then the sequence number of the first URI in the playlist SHALL
be considered to be 0.
[译]该标签在播放列表中至多允许出现一次。如果播放列表中没有包含该标签，那么该列表中的第一个URI的序列号可以认为是零。
A media file’s sequence number is not required to appear in its URI.
[译]一个媒体文件的序列号不是必须出现在它的URI中的。
See Section 6.3.2 and Section 6.3.5 for information on handling the
EXT-X-MEDIA-SEQUENCE tag.
[译]关于如何处理该标签的方法详见6.3.2章节，和6.3.5章节。
3.2.3. EXT-X-KEY
[译]3.2.3. EXT-X-KEY
Media files MAY be encrypted. The EXT-X-KEY tag provides information
necessary to decrypt media files that follow it. Its format is:
[译]媒体文件可能是加密的。该标签提供了解密媒体文件的必要信息。格式如下：
#EXT-X-KEY:METHOD=<method>[,URI=”<URI>”][,IV=<IV>]
The METHOD attribute specifies the encryption method. Two encryption
methods are defined: NONE and AES-128.
[译]media属性指定了加密的方法。目前官方定义了两种加密方法：NONE和AES-128。
An encryption method of NONE means that media files are not
encrypted. If the encryption method is NONE, the URI and the IV
attributes MUST NOT be present.
[译]NONE加密方法表示媒体文件没有加密。如果使用这种加密方法，URI和IV属性是不允许存在的。
An encryption method of AES-128 means that media files are encrypted
using the Advanced Encryption Standard [AES_128] with a 128-bit key
and PKCS7 padding [RFC5652]. If the encryption method is AES-128,
[译]AES-128加密方法表示媒体文件使用了高级加密标准的128位密钥和PKCS7信息。如果使用这种加密方法，URI属性必须存在，IV属性可有可无。有关IV属性的信息见5.2章节。
Pantos & May Expires December 7, 2010 [Page 6]
Internet-Draft HTTP Live Streaming June 2010
the URI attribute MUST be present. The IV attribute MAY be present;
see Section 5.2.
The URI attribute, if present, specifies how to obtain the key. The
IV attribute, if present, specifies the Initialization Vector to be
used with the key. The IV attribute appeared in protocol version 2.
[译]URI属性（如果存在）指明了获取密钥的方法。IV属性（如果存在）指定了密钥的初始化向量。IV属性出现在当前协议的第二个版本中。
A new EXT-X-KEY supersedes any prior EXT-X-KEY.
[译]新的EXT-X-KEY将会取代之前的EXT-X-KEY。
If the Playlist file does not contain an EXT-X-KEY tag then media
files are not encrypted.
[译]如果播放列表文件没有包含EXT-X-KEY标签，那么媒体文件是不加密的。
See Section 5 for the format of the key file, and Section 5.2,
Section 6.2.3 and Section 6.3.6 for additional information on media
file encryption.
[译]有关密钥文件的格式详见第五章，媒体文件的加密信息见5.2章节，6.2.3章节和6.3.6章节。
3.2.4. EXT-X-PROGRAM-DATE-TIME
[译]3.2.4. EXT-X-PROGRAM-DATE-TIME
The EXT-X-PROGRAM-DATE-TIME tag associates the beginning of the next
media file with an absolute date and/or time. The date/time
representation is ISO/IEC 8601:2004 [ISO_8601] and SHOULD indicate a
time zone. For example:
[译]该标签将下一个媒体文件的开头和绝对日期关联起来。日期/时间的表示基于ISO/IEC标准，并且要指明时区。例如：
#EXT-X-PROGRAM-DATE-TIME:<YYYY-MM-DDThh:mm:ssZ>
See Section 6.2.1 and Section 6.3.3 for more information on the EXT-
X-PROGRAM-DATE-TIME tag.
[译]有关该标签的更多信息见6.2.1章节和6.3.3章节。
3.2.5. EXT-X-ALLOW-CACHE
[译]3.2.5. EXT-X-ALLOW-CACHE
The EXT-X-ALLOW-CACHE tag indicates whether the client MAY or MUST
NOT cache downloaded media files for later replay. It MAY occur
anywhere in the Playlist file; it MUST NOT occur more than once. The
EXT-X-ALLOW-CACHE tag applies to all segments in the playlist. Its
format is:
[译]该标签指定客户端可以/不允许缓存已下载的媒体文件用于回放。它可能会出现在播放列表文件的任何地方，但是至多允许出现一次。该标签适应于播放列表中的所有分片。格式如下：
#EXT-X-ALLOW-CACHE:<YES|NO>
See Section 6.3.3 for more information on the EXT-X-ALLOW-CACHE tag.
[译]有关该标签的更多信息见6.3.3章节。
3.2.6. EXT-X-ENDLIST
[译]3.2.6. EXT-X-ENDLIST
The EXT-X-ENDLIST tag indicates that no more media files will be
added to the Playlist file. It MAY occur anywhere in the Playlist
file; it MUST NOT occur more than once. Its format is:
[译]该标签指明了播放列表中不会再有媒体文件加入。它可能出现在播放列表的任何位置，但至多出现一次。格式如下：
#EXT-X-ENDLIST
Pantos & May Expires December 7, 2010 [Page 7]
Internet-Draft HTTP Live Streaming June 2010
3.2.7. EXT-X-STREAM-INF
[译]3.2.7. EXT-X-STREAM-INF
The EXT-X-STREAM-INF tag indicates that the next URI in the Playlist
file identifies another Playlist file. Its format is:
[译]该标签指定了当前播放列表中的其他播放列表文件的URI。格式如下：
#EXT-X-STREAM-INF:[attribute=value][,attribute=value]*
<URI>
An attribute MUST NOT occur more than once in the same EXT-X-STREAM-
INF tag. The following attributes are defined:
[译]同一个EXT-STREAM-INF标签中attribute至多允许出现一次。属性有如下：
BANDWIDTH=<n>
where n is a number of bits per second. It MUST be an upper bound of
the overall bitrate of each media file, calculated to include
container overhead, that appears or will appear in the Playlist.
[译]n为每秒的比特率。它必须是经过计和的播放列表中出现的和将要出现的所有媒体文件的比特率的最大值。
PROGRAM-ID=<i>
where i is a number that uniquely identifies a particular
presentation within the scope of the Playlist file.
[译]i是一个数字，在播放列表文件的范围内唯一的标识了一个特定的演示文稿。
A Playlist file MAY contain multiple EXT-X-STREAM-INF tags with the
same PROGRAM-ID to identify different encodings of the same
presentation. These variant playlists MAY contain additional EXT-X-
STREAM-INF tags.
[译]一个播放列表文件可能包含多个具有相同PROGRAM-ID的EXT-X-STREAM-INF标签来标识某个演示文稿的不同编码。这些可变的播放列表可能包含额外的EXT-X-STREAM-INF标签。
CODECS=”[format][,format]*“
where each format specifies a media sample type that is present in a
media file in the Playlist file.
[译]每一种格式都指定了播放列表文件中的一种媒体文件类型。
Valid format identifiers are those in the ISO File Format Name Space
defined by RFC 4281 [RFC4281].
[译]有效的媒体格式参见RFC4281文档中定义的ISO文件格式名。
RESOLUTION=<N>x<M>
where N is the approximate encoded horizontal resolution of video
within the stream, expressed as a number of pixels, and M is the
approximate encoded vertical resolution.
[译]N是视频流中水平编码分辨率，以像素为单位；M是垂直编码分辨率。
3.2.8. EXT-X-DISCONTINUITY
[译]3.2.8. EXT-X-DISCONTINUITY
The EXT-X-DISCONTINUITY tag indicates an encoding discontinuity
between the media file that follows it and the one that preceded it.
The set of characteristics that MAY change is:
[译]EXT-X-DISCONTINUITY标签表示该标签前和后的媒体文件之间的编码间断。可能改变的一组特性如下：
Pantos & May Expires December 7, 2010 [Page 8]
Internet-Draft HTTP Live Streaming June 2010
o file format
o number and type of tracks
o encoding parameters
o encoding sequence
o timestamp sequence
Its format is:
#EXT-X-DISCONTINUITY
See Section 4, Section 6.2.1, and Section 6.3.3 for more information
about the EXT-X-DISCONTINUITY tag.
[译]有关该标签的更多信息详见第4章，6.2.1章节和6.3.3章节。
3.2.9. EXT-X-VERSION
[译]3.2.9. EXT-X-VERSION
The EXT-X-VERSION tag indicates the compatibility version of the
Playlist file. The Playlist file, its associated media, and its
server MUST comply with all provisions of the most-recent version of
this document describing the protocol version indicated by the tag
value.
[译]EXT-X-VERSION标签指定了播放列表文件的兼容性。播放列表文件，相关联媒体文件和服务器必须遵守最新版本的所有规定。
Its format is:
[译]格式如下：
#EXT-X-VERSION:<n>
where n is an integer indicating the protocol version.
[译]n是整数，表示协议的版本号。
A Playlist file MUST NOT contain more than one EXT-X-VERSION tag. A
Playlist file that does not contain an EXT-X-VERSION tag MUST comply
with version 1 of this protocol.
[译]一个播放列表文件至多允许包含一个EXT-X-VERSION标签。如果播放列表文件中没有包含该标签，那么必须兼容该协议的第1个版本。
4. Media files
[译]4. 媒体文件
Each media file URI in a Playlist file MUST identify a media file
which is a segment of the overall presentation. Each media file MUST
be formatted as an MPEG-2 Transport Stream or an MPEG-2 audio
elementary stream [ISO_13818].
[译]播放列表文件中的每一个媒体文件URI必须标识一个媒体文件，该文件是整个演示文稿的一个分片。每个媒体文件必须遵照MPEG-2传输流格式或MPEG-2音频流格式。
Transport Stream files MUST contain a single MPEG-2 Program. There
SHOULD be a Program Association Table and a Program Map Table at the
start of each file. A file that contains video SHOULD have at least
one key frame and enough information to completely initialize a video
decoder.
[译]传输流文件必须包含一个MPEG-2节目。在每个文件的开始应该有一个节目关联表和一个节目映射表。包含的视频文件应该至少有一个关键帧和足够的信息来完全初始化一个视频解码器。
Pantos & May Expires December 7, 2010 [Page 9]
Internet-Draft HTTP Live Streaming June 2010
A media file in a Playlist MUST be the continuation of the encoded
stream at the end of the media file with the previous sequence number
unless it was the first media file to appear in the Playlist file or
if it is preceded by an EXT-X-DISCONTINUITY tag.
[译]播放列表中的媒体文件，必须是上一个媒体文件的编码流的继续，除非它是播放列表的第一个媒体文件，或者位于EXT-X-DISCONTINUITY标签之后。
Clients SHOULD be prepared to handle multiple tracks of a particular
type (e.g. audio or video). A client with no other preference SHOULD
choose the one with the lowest numerical PID that it can play.
[译]客户端应该准备好多个轨道来处理一个特定类型的音频或视频。如果客户端没有特定的偏好，应该选择一个它能播放的具有最小数字编号的轨道。
Clients MUST ignore private streams inside Transport Streams that
they do not recognize.
[译]客户端必须忽略传输流内部他们不能识别的私有流。
The encoding parameters for samples within a stream inside a media
file and between corresponding streams across multiple media files
SHOULD remain consistent. However clients SHOULD deal with encoding
changes as they are encountered, for example by scaling video content
to accommodate a resolution change.
[译]媒体文件内样本流和相应的多媒体流的编码参数应保持一致。客户端应该解决编码的变化带来的问题，如缩放视频内容以适应分辨率的改变。
5. Key files
[译]5. 密钥文件
5.1. Introduction
[译]5.1. 介绍
An EXT-X-KEY tag with the URI attribute identifies a Key file. A Key
file contains the cipher key that MUST be used to decrypt subsequent
media files in the Playlist.
[译]URI属性中的EXT-X-KEY标签标识了一个密钥文件。密钥文件包含了解密播放列表中媒体文件的密钥。
The AES-128 encryption method uses 16-octet keys. The format of the
Key file is simply a packed array of these 16 octets in binary
format.
[译]AES-128加密算法使用16字节的密钥。密钥文件的格式为16字节的二进制数组。
5.2. IV for AES-128
[译]5.2. AES-128的初始化向量
128-bit AES requires the same 16-octet Initialization Vector (IV) to
be supplied when encrypting and decrypting. Varying this IV
increases the strength of the cipher.
[译]128位AES在加密和解密的时候，需要使用相同的16字节的初始化向量。变换初始化向量可以提高密钥的健壮性。
If the EXT-X-KEY tag has the IV attribute, implementations MUST use
the attribute value as the IV when encrypting or decrypting with that
key. The value MUST be interpreted as a 128-bit hexadecimal number
and MUST be prefixed with 0x or 0X.
[译]如果EXT-X-KEY标签有IV属性，在加密或解决的时候必须使用此属性值作为IV。这个属性值必须被解析为一个128位的16进制数，且必须以0x或0X作为前缀。
If the EXT-X-KEY tag does not have the IV attribute, implementations
MUST use the sequence number of the media file as the IV when
encrypting or decrypting that media file. The big-endian binary
representation of the sequence number SHALL be placed in a 16-octet
buffer and padded (on the left) with zeros.
[译]如果EXT-X-KEY标签没有IV属性，在加密或解决的时候必须使用序列号作为IV值。以大端二进制表示的序列号应该放在16字节缓冲区中，且在左边补零。
Pantos & May Expires December 7, 2010 [Page 10]
Internet-Draft HTTP Live Streaming June 2010
6. Client/Server Actions
[译]6. 客户端/服务器处理
6.1. Introduction
[译]6.1. 介绍
This section describes how the server generates the Playlist and
media files and how the client should download and play them.
[译]本意介绍服务器怎样生成播放列表和媒体文件，以及客户端怎样下载并播放他们。
6.2. Server Process
[译]6.2. 服务器处理
6.2.1. Introduction
[译]6.2.1. 介绍
The production of the MPEG-2 stream is outside the scope of this
document, which simply presumes a source of a continuous stream
containing the presentation.
[译]有关MPEG-2流的介绍不在本文档范围内，本文档假设已经有一个现成的数据流。
The server MUST divide the stream into individual media files whose
duration is approximately equal. The server SHOULD attempt to divide
the stream at points that support effective decode of individual
media files, e.g. on packet and key frame boundaries.
[译]服务器必须将数据流分割成持续时间大致相等的媒体文件，服务器应该尝试使用包和关键帧的边界来分割流，以支持对单个媒体文件的有效解码。
The server MUST create a URI for each media file that will allow its
clients to obtain the file.
[译]服务器必须为每个媒体文件创建URI，从而客户端可以获取到媒体文件。
The server MUST create a Playlist file. The Playlist file MUST
conform to the format described in Section 3. A URI for each media
file that the server wishes to make available MUST appear in the
Playlist in the order in which it is to be played. The entire media
file MUST be available to clients if its URI is in the Playlist file.
[译]服务器必须创建播放列表文件。播放列表文件的格式必须符合第3章的描述。服务器要提供的媒体文件的URI必须按顺序出现在播放列表中。如果URI出现在播放列表中，那么这个媒体文件对于客户端必须是可用的。
The Playlist file MUST contain an EXT-X-TARGETDURATION tag. It MUST
indicate the maximum EXTINF value of any media file added to the
Playlist file. Its value MUST remain constant for the entire
presentation. A typical target duration is 10 seconds.
[译]播放列表文件必须包含一个EXT-X-TARGETDURATION标签。它必须指明播放列表中媒体文件的最大的EXTINF值。一个演示文稿的持续时间必须保持不变。典型持续时间为10秒。
The Playlist file SHOULD contain one EXT-X-VERSION tag which
indicates the compatibility version of the stream. Its value SHOULD
be the lowest protocol version with which the server, Playlist file,
and associated media files all comply.
[译]播放列表文件应该包含EXT-X-VERSION标签，用来说明流对于版本的兼容性。它的值应该是服务器，播放列表文件和其关联的媒体文件都能兼容的最低协议版本。
The server MUST create a URI for the Playlist file that will allow
its clients to obtain the file.
[译]服务器必须为播放列表文件创建一个URI，以允许客户端获取到它。
If the Playlist file is distributed by HTTP, the server SHOULD
support client requests to use the “gzip” Content-Encoding.
[译]如果播放列表文件通过HTTP传输，那么服务器应该支持客户端使用GZIP的方式请求。
Changes to the Playlist file MUST be made atomically from the point
of view of the clients.
[译]从客户端的角度来看，播放列表的变更必须是自动的。
Pantos & May Expires December 7, 2010 [Page 11]
Internet-Draft HTTP Live Streaming June 2010
The server MUST NOT change the value of the EXT-X-ALLOW-CACHE tag.
[译]服务器不可以修改EXT-X-ALLOW-CACHE标签的值（在整个演示文稿当中）。
Every media file URI in a Playlist MUST be prefixed with an EXTINF
tag indicating the rounded duration of the media file.
[译]播放列表中的每个媒体文件的URI必须以EXTINF作为前缀来说明媒体文件的持续时间。
The server MAY associate an absolute date and time with a media file
by prefixing its URI with an EXT-X-PROGRAM-DATE-TIME tag. The value
of the date and time provides an informative mapping of the timeline
of the media to an appropriate wall-clock time, which may be used as
a basis for seeking, for display, or for other purposes. If a server
provides this mapping, it SHOULD place an EXT-X-PROGRAM-DATE-TIME tag
after every EXT-X-DISCONTINUITY tag in the Playlist file.
[译]服务器可以将媒体文件和绝对日期时间关联起来，以在媒体文件的URI前添加一个EXT-X-PROGRAM-DATE-TIME标签的方式。日期和时间提供了一个媒体时间表到挂钟时间信息的映射，该挂钟时间可以作为搜索，显示或其他目的的基准。如果服务器提供了这个映射，那么它应该在每个EXT-X-DISCONTUNUITY标签的后边添加一个EXT-X-PROGRAM-DATE-TIME标签。
If the Playlist contains the final media file of the presentation
then the Playlist file MUST contain the EXT-X-ENDLIST tag.
[译]如果播放列表中包含了演示文稿的最后一个分片，那么应该添加一个EXT-ENDLIST标签。
If the Playlist does not contain the EXT-X-ENDLIST tag, the server
MUST make a new version of the Playlist file available that contains
at least one new media file URI. It MUST be made available relative
to the time that the previous version of the Playlist file was made
available: no earlier than one-half the target duration after that
time, and no later than 1.5 times the target duration after that
time.
[译]如果播放列表没有包含EXT-X-ENDLIST标签，那么服务器必须创建一个新的播放列表，并至少包含一个新的媒体文件URI。俗人的播放列表必须与前一个播放列表在相对时间内有效：从上一个播放列表文件的开始时间算起，不早于0.5倍持续时间，不晚于1.5倍有效时间。
If the server wishes to remove an entire presentation, it MUST make
the Playlist file unavailable to clients. It SHOULD ensure that all
media files in the Playlist file remain available to clients for at
least the duration of the Playlist file at the time of removal.
[译]如果服务器希望移除播放列表，它必须使播放列表文件对于和客户端不可用，在播放列表被清除时，它应该确保播放列表文件中的所有媒体文件对于客户端来说，至少在一个持续时间内是可用的。
6.2.2. Sliding Window Playlists
[译]6.2.2. 播放列表的滑动窗口
The server MAY limit the availability of media files to those which
have been most recently added to the Playlist. To do so the Playlist
file MUST ALWAYS contain exactly one EXT-X-MEDIA-SEQUENCE tag. Its
value MUST be incremented by 1 for every media file URI that is
removed from the Playlist file.
[译]服务器可以限制最近一段时间内添加到播放列表中的媒体文件的可用性，为了达到这个目的，播放列表必须包含准确的EXT-X-MEDIA-SEQUENCE标签。标签的值是按照从播放列表中移除的媒体文件的URI递增的。
Media file URIs MUST be removed from the Playlist file in the order
in which they were added.
[译]媒体文件的URI必须按照它加入的顺序移除。
When the server removes a media file URI from the Playlist, the media
file SHOULD remain available to clients for a period of time equal to
the duration of the media file plus the duration of the longest
Playlist file in which the media file has appeared.
[译]当服务器从播放列表中移除URI时，媒体文件在一段时间内必须保持可用，该时间等于媒体文件的时间加上包含该媒体文件的最长播放列表文件的时间。
If a server plans to remove a media file after it is delivered to
clients over HTTP, it SHOULD ensure that the HTTP response contains
an Expires header that reflects the planned time-to-live.
[译]当一个媒体文件通过HTTP的方式传输给客户端后，如果服务器打算移除该文件，那么它应该确保HTTP的响应头中包含了想要的生存期（过期时间）。
Pantos & May Expires December 7, 2010 [Page 12]
Internet-Draft HTTP Live Streaming June 2010
The duration of a Playlist file that does not contain the EXT-X-
ENDLIST tag MUST be at least three times the target duration.
[译]如果播放列表中没有包含EXT-X-ENDLIST标签，那么该播放列表的持续时间至少为三个持续时间标签的时间。
6.2.3. Encrypting media files
[译]6.2.3. 加密媒体文件
If media files are to be encrypted the server MUST define a URI which
will allow authorized clients to obtain a Key file containing a
decryption key. The Key file MUST conform to the format described in
Section 5.
[译]如果媒体文件需要加密，那么服务器必须定义一个URI来允许客户端获取包含解密密钥的文件。密钥文件的格式必须符合第5章的描述。
The server MAY set the HTTP Expires header in the key response to
indicate that the key may be cached.
[译]服务器可以在密钥响应头中设置超时来表明密钥可以被缓存。
If the encryption METHOD is AES-128, AES-128 CBC encryption SHALL be
applied to individual media files. The entire file MUST be
encrypted. Cipher Block Chaining MUST NOT be applied across media
files. The IV used for encryption MUST be either the sequence number
of the media file or the value of the IV attribute of the EXT-X-KEY
tag, as described in Section 5.2.
[译]如果采用AES-128加密算法，那么AES-128 CBC加密模式一样适用于每一个媒体文件。整个文件必须加密的。密钥链不能跨媒体文件使用。用于密钥的初始化向量必须是媒体文件的序列号或EXT-X-KEY标签的IV属性值。
The server MUST encrypt every media file in a Playlist using the
method and other attributes specified by the EXT-X-KEY tag that most
immediately precedes its URI in the Playlist file. Media files
preceded by an EXT-X-KEY tag whose METHOD is NONE, or not preceded by
any EXT-X-KEY tag, MUST NOT be encrypted.
[译]服务器必须使用这种加密算法和其他播放列表文件URI的EXT-X-KEY标签所指定的属性来加密的播放列表中的每一个媒体文件。如果EXT-X-KEY标签中方法为NONE或者没有该标签，那么媒体文件不能被加密。
The server MUST NOT remove an EXT-X-KEY tag from the Playlist file if
the Playlist file contains a URI to a media file encrypted with that
key.
[译]如果播放列表文件包含了一个经过加密的媒体文件的URI，那么服务器不可以将EXT-X-KEY标签从播放列表中移除。
6.2.4. Providing variant streams
[译]6.2.4. 提供可变码流
A server MAY offer multiple Playlist files to provide different
encodings of the same presentation. If it does so it SHOULD provide
a variant Playlist file that lists each variant stream to allow
clients to switch between encodings dynamically.
[译]服务器可以提供多个播放列表文件来支持对同一个演示文稿的不同编码。可变播放列表文件中提供了每一种码率的流，从而使客户端可以在不同编码流之间动态切换。
Variant Playlists MUST contain an EXT-X-STREAM-INF tag for each
variant stream. Each EXT-X-STREAM-INF tag for the same presentation
MUST have the same PROGRAM-ID attribute value. The PROGRAM-ID value
for each presentation MUST be unique within the variant Playlist.
[译]在可变的播放列表中每一个EXT-X-STREAM-INF标签对应一种编码流。同一演示文稿的每个EXT-X-STREAM-INF标签内都必须使用相同的PROGRAM-ID属性值。每个演示文稿的PROGRAM-ID在可变播放列表内必须是唯一的。
If an EXT-X-STREAM-INF tag contains the CODECS attribute, the
attribute value MUST include every format defined by [RFC4281] that
is present in any media file that appears or will appear in the
Playlist file.
[译]如果EXT-X-STREAM-INF标签包含CODECS属性，那么该属性必须包含出现在播放列表中的并且符合RFC4281定义的所有格式。
The server MUST meet the following constraints when producing variant
Pantos & May Expires December 7, 2010 [Page 13]
Internet-Draft HTTP Live Streaming June 2010
streams:
[译]服务器在生成可变流的时候，应该遵守以下规则：
Each variant stream MUST present the same content, including
stream discontinuities.
[译]每一种可变流必须呈现相同的内容，包括流的间断性。
Each variant Playlist file MUST have the same target duration.
[译]每一种可变流必须包含相同的目标持续时间。
Content that appears in one variant Playlist file but not in
another MUST appear either at the beginning or at the end of the
Playlist file and MUST NOT be longer than the target duration.
[译]只在个别可变播放列表文件中出现的内容必须放在列表的头或尾，并且不能超过目标持续时间。
Matching content in variant streams MUST have matching timestamps.
This allows clients to synchronize the streams.
[译]在不同的可变流之间匹配内容，必须依据时间戳。这可以使客户端保持流同步。
Elementary Audio Stream files MUST signal the timestamp of the
first sample in the file by prepending an ID3 PRIV tag [ID3] with
an owner identifier of
“com.apple.streaming.transportStreamTimestamp”. The binary data
MUST be a 33-bit MPEG-2 Program Elementary Stream timestamp
expressed as a big-endian eight-octet number.
[译]普通的音频流文件必须在文件第一个样本的采样信号的时间戳前添加一个ID3 PRIV标签，标签的所有者为”com.apple.streaming.transportStreamTimestamp”。数据必须是33位的MPEG-2基本时间戳，并且使用8字节的数字表示。
In addition, all variant streams SHOULD contain the same encoded
audio bitstream. This allows clients to switch between streams
without audible glitching.
[译]另外，所有的可变流都应该包含相同编码的音频流。这使得客户端在不同的流之间切换时没有尖刺声。
6.3. Client Process
[译]6.3. 客户端处理
6.3.1. Introduction
[译]6.3.1. 介绍
How the client obtains the URI to the Playlist file is outside the
scope of this document; it is presumed to have done so.
[译]客户端如何获取播放列表的URI不在本文档讨论范围内，我们假设已经获取到了此URI。
The client MUST obtain the Playlist file from the URI. If the
Playlist file so obtained is a variant Playlist, the client MUST
obtain the Playlist file from the variant Playlist.
[译]客户端必须根据URI来获取播放列表文件。如果获取到的播放列表是可变的，那么客户端必须从播放列表中获取新的可变播放列表。
This document does not specify the treatment of variant streams by
clients.
[译]本文档不提供客户端如何处理可变流的方法。
6.3.2. Loading the Playlist file
[译]6.3.2. 加载播放列表
Every time a Playlist file is loaded or reloaded from the Playlist
URI:
[译]每一次加载或重载播放列表文件时：
The client MUST ensure that the Playlist file begins with the
EXTM3U tag and that the EXT-X-VERSION tag, if present, specifies a
protocol version supported by the client; if not, the client MUST
NOT attempt to use the Playlist.
[译]客户端必须保证播放列表以EXTM3U标签开头，并且如果协议版本存在，客户端必须支持该版本。否则客户端不可以试图使用该播放列表。
Pantos & May Expires December 7, 2010 [Page 14]
Internet-Draft HTTP Live Streaming June 2010
The client SHOULD ignore any tags and attributes it does not
recognize.
[译]客户端可以忽略它不能识别的标签和属性。
The client MUST determine the next media file to load as described
in Section 6.3.5.
[译]客户端必须决定下一个将要加载的媒体文件，根据6.3.5章节的描述。
If the Playlist contains the EXT-X-MEDIA-SEQUENCE tag, the client
SHOULD assume that each media file in it will become unavailable at
the time that the Playlist file was loaded plus the duration of the
Playlist file. The duration of a Playlist file is the sum of the
durations of the media files within it.
[译]如果播放列表包含了EXT-X-MEDIA-SEQUENCE标签，那么客户端应该假设在播放列表补加载的时间内以及播放列表的持续时间内媒体文件将变得不可用。播放列表的持续时间等于它所包含的所有媒体文件时长的总和。
6.3.3. Playing the Playlist file
[译]6.3.3. 播放播放列表文件
The client SHALL choose which media file to play first from the
Playlist when playback starts. If the EXT-X-ENDLIST tag is not
present and the client intends to play the media regularly (i.e. in
playlist order at the nominal playback rate), the client SHOULD NOT
choose a file which starts less than three target durations from the
end of the Playlist file. Doing so can trigger playback stalls.
[译]当开始播放的时候，客户端从播放列表中选择第一个播放的媒体文件。如果播放列表中不存在EXT-X-ENDLIST标签，并且客户端想要正常播放媒体（按顺序以标准速率播放），那么客户端就不应该从播放列表尾部选择少于三个目标持续时间的媒体文件。如此，客户端就可以触发播放了。
To achieve regular playback, media files MUST be played in the order
that they appear in the Playlist file. The client MAY present the
available media in any way it wishes, including regular playback,
random access, and trick modes.
[译]为了达到正常播放的目的，客户端必须按照媒体文件出现在播放列表中的顺序播放它们。客户端可以用任何方式播放，比如顺序播放，随机播放，物资播放等。
The client MUST be prepared to reset its parser(s) and decoder(s)
before playing a media file that is preceded by an EXT-X-
DISCONTINUITY tag.
[译]对于存在EXT-X-DISCONTINUITY标签的媒体文件，客户端在播放之前必须重置解析器和解码器。
The client SHOULD attempt to load media files in advance of when they
will be required for uninterrupted playback to compensate for
temporary variations in latency and throughput.
[译]客户端应该提前载入媒体文件，以应对延时和吞吐量带来的网络变化。
If the Playlist file contains the EXT-X-ALLOW-CACHE tag and its value
is NO, the client MUST NOT cache downloaded media files after they
have been played. Otherwise the client MAY cache downloaded media
files indefinitely for later replay.
[译]如果播放列表包含EXT-X-ALLOW-CACHE标签，并且值为NO，那么客户端在播放以后不可以缓存媒体文件。否则允许客户端缓存用于回放。
The client MAY use the value of the EXT-X-PROGRAM-DATE-TIME tag to
display the program origination time to the user. If the value
includes time zone information the client SHALL take it into account,
but if it does not the client MUST NOT infer an originating time
zone.
[译]客户端可以使用EXT-X-PROGRAM-DATE-TIME标签来为用户显示节目的起始时间。如果这个值包含了时区信息，那么客户端应该做相应的处理。如果没有包含时区信息，客户端不可以推测时区。
The client MUST NOT depend upon the correctness or the consistency of
the value of the EXT-X-PROGRAM-DATE-TIME tag.
[译]客户端不能依赖EXT-X-PROGRAM-DATE-TIME标签的正确性和一致性。
Pantos & May Expires December 7, 2010 [Page 15]
Internet-Draft HTTP Live Streaming June 2010
6.3.4. Reloading the Playlist file
[译]6.3.4. 重载播放列表文件
The client MUST periodically reload the Playlist file unless it
contains the EXT-X-ENDLIST tag.
[译]客户端必须阶段性的重载播放列表文件，直到它包含了EXT-X-ENDLIST标签。
However the client MUST NOT attempt to reload the Playlist file more
frequently than specified by this section.
[译]然而，客户端重载播放列表的频率不能超过本章的描述。
When a client loads a Playlist file for the first time or reloads a
Playlist file and finds that it has changed since the last time it
was loaded, the client MUST wait for a period of time before
attempting to reload the Playlist file again. This period is called
the initial minimum reload delay. It is measured from the time that
the client began loading the Playlist file.
[译]当客户端第一次加载播放列表或者已经载入但是发现文件与上次载入的不一样时，客户端必须等待一段时间才可以再次载入。这段时间被称为原始最小重载延迟，它是从客户端开始载入播放列表文件开始计算的。
The initial minimum reload delay is the duration of the last media
file in the Playlist. Media file duration is specified by the EXTINF
tag.
[译]原始最小重载延迟是播放列表文件中最后一个媒体文件的持续时间。媒体文件的持续时间由EXTINF标签指定。
If the client reloads a Playlist file and finds that it has not
changed then it MUST wait for a period of time before retrying. The
minimum delay is a multiple of the target duration. This multiple is
0.5 for the first attempt, 1.5 for the second, and 3.0 thereafter.
[译]如果客户端重载了一个播放列表文件，但是发现文件并没有变化，那么它在重试之前必须等待一段时间。最小延迟是 target duration 的倍数。第一次是0.5倍，第二次是1.5倍，其他的是3.0倍。
6.3.5. Determining the next file to load
[译]6.3.5. 确定下一个要加载的文件
The client MUST examine the Playlist file every time it is loaded or
reloaded to determine the next media file to load.
[译]客户端必须检查每次加载或重载的播放列表文件，以此来确定下一个要加载的媒体文件。
The first file to load MUST be the file that the client has chosen to
play first, as described in Section 6.3.3.
[译]客户端第一个加载的文件，必须是第一个被播放的，就如同6.3.3章节的描述。
If the first file to be played has been loaded and the Playlist file
does not contain the EXT-X-MEDIA-SEQUENCE tag then the client MUST
verify that the current Playlist file contains the URI of the last
loaded media file at the offset it was originally found at, halting
playback if it does not. The next media file to load MUST be the
first media file URI following the last-loaded URI in the Playlist.
[译]如果要播放的文件已经载入，并且播放列表文件不包含EXT-X-MEDIA-SEQUENCE标签，那么客户端必须确认播放列表文件包含了最后一个被载入的媒体文件的URI，如果不包含，则暂停播放。要载入的下一个媒体文件必须是上一次载入的媒体文件URI之后的第一个媒体文件的URI。
If the first file to be played has been loaded and the Playlist file
contains the EXT-X-MEDIA-SEQUENCE tag then the next media file to
load SHALL be the one with the lowest sequence number that is greater
than the sequence number of the last media file loaded.
[译]如果要播放的文件已经载入，并且播放列表文件包含EXT-X-MEDIA-SEQUENCE标签，那么要载入的下一个媒体文件就是比上一次载入的文件的序列号大的媒体文件中的序列号的最小者。
6.3.6. Decrypting encrypted media files
[译]6.3.6. 解密加密的媒体文件
If a Playlist file contains an EXT-X-KEY tag that specifies a Key
file URI, the client MUST obtain that key file and use the key inside
Pantos & May Expires December 7, 2010 [Page 16]
Internet-Draft HTTP Live Streaming June 2010
it to decrypt all media files following the EXT-X-KEY tag until
another EXT-X-KEY tag is encountered.
[译]如果播放列表文件包含了一个标识密钥文件URI的EXT-X-KEY标签，客户端必须获取密钥文件，并且使用其中的密钥来解密KEY标签之后的所有媒体文件，直到另外一个EXT-X-KEY标签出现（代替当前密钥）。
If the encryption METHOD is AES-128, AES-128 CBC decryption SHALL be
applied to individual media files. The entire file MUST be
decrypted. Cipher Block Chaining MUST NOT be applied across media
files. The IV used for decryption MUST be either the sequence number
of the media file or the value of the IV attribute of the EXT-X-KEY
tag, as described in Section 5.2.
[译]如果加密方法是AES-128，AES CBC解密算法应该应用在独立的媒体文件上。所有的文件必须被解密（才可以使用）。密码链不允许跨媒体文件使用。解密用的初始化向量必须是媒体文件的序列号，或EXT-X-KEY标签的IV属性，相关描述参照5.2章节。
If the encryption METHOD is NONE, the client MUST treat all media
files following the EXT-X-KEY tag as cleartext (not encrypted) until
another EXT-X-KEY tag is encountered.
[译]如果加密方法为空，客户端必须把EXT-X-KEY标签后面的媒体文件视作没有加密的，直到遇到另一个EXT-X-KEY标签。
7. Protocol version compatibility
[译]7. 协议版本的兼容性
Clients and servers MUST implement protocol version 2 or higher to
use:
[译]客户端和服务器必须使用版本2以及更高的版本。
o The IV attribute of the EXT-X-KEY tag.
8. Examples
[译]8. 示例
8.1. Introduction
[译]8.1. 介绍
This section contains several example Playlist files.
[译]本章包含了一些播放列表文件的示例。
8.2. Simple Playlist file
[译]8.2. 播放列表文件示例
#EXTM3U
#EXT-X-TARGETDURATION:5220
#EXTINF:5220,
http://media\.example\.com/entire\.ts
#EXT-X-ENDLIST
Pantos & May Expires December 7, 2010 [Page 17]
Internet-Draft HTTP Live Streaming June 2010
8.3. Sliding Window Playlist, using HTTPS
[译]8.3. 使用HTTPS的滑动窗口播放列表
#EXTM3U
#EXT-X-TARGETDURATION:8
#EXT-X-MEDIA-SEQUENCE:2680
#EXTINF:8,
https://priv\.example\.com/fileSequence2680\.ts
#EXTINF:8,
https://priv\.example\.com/fileSequence2681\.ts
#EXTINF:8,
https://priv\.example\.com/fileSequence2682\.ts
8.4. Playlist file with encrypted media files
[译]8.4. 包含加密媒体文件的播放列表
#EXTM3U
#EXT-X-MEDIA-SEQUENCE:7794
#EXT-X-TARGETDURATION:15
#EXT-X-KEY:METHOD=AES-128,URI=”https://priv\.example\.com/key\.php?r=52“
#EXTINF:15,
http://media\.example\.com/fileSequence52\-1\.ts
#EXTINF:15,
http://media\.example\.com/fileSequence52\-2\.ts
#EXTINF:15,
http://media\.example\.com/fileSequence52\-3\.ts
#EXT-X-KEY:METHOD=AES-128,URI=”https://priv\.example\.com/key\.php?r=53“
#EXTINF:15,
http://media\.example\.com/fileSequence53\-1\.ts
8.5. Variant Playlist file
[译]8.5. 可变播放列表文件
#EXTM3U
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1280000
http://example\.com/low\.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=2560000
http://example\.com/mid\.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=7680000
http://example\.com/hi\.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=65000,CODECS=”mp4a.40.5”
http://example\.com/audio\-only\.m3u8
Pantos & May Expires December 7, 2010 [Page 18]
Internet-Draft HTTP Live Streaming June 2010
9. Contributors
[译]9. 贡献者
Significant contributions to the design of this protocol were made by
Jim Batson, David Biderman, Bill May, Roger Pantos, and Alan Tseng.
10. IANA Considerations
[译]10. IANA注意事项
This memo requests that the following MIME type [RFC2046] be
registered with the IANA:
Type name: “application”
Subtype name: “vnd.apple.mpegurl”
Required parameters: (none)
Optional parameters: (none)
Encoding considerations: encoded as text. See Section 3 for more
information.
Security considerations: See Section 11.
Compression: this media type does not employ compression.
Interoperability considerations: There are no byte-ordering issues,
since files are 7- or 8-bit text. Applications could encounter
unrecognized tags, which SHOULD be ignored.
Published specification: see Section 3.
Applications that use this media type: Multimedia applications such
as the iPhone media player (OS 3.0) and QuickTime Player in Mac OS X
Snow Leopard.
Additional information: files begin with the magic number #EXTM3U.
Filenames normally end with .m3u8 or .m3u (see Section 3). No
Macintosh file type codes have been registered.
Person & email address to contact for further information: David
Singer, singer AT apple.com.
Intended usage: LIMITED USE
Restrictions on usage: (none)
Author: Roger Pantos
Pantos & May Expires December 7, 2010 [Page 19]
Internet-Draft HTTP Live Streaming June 2010
Change Controller: David Singer
11. Security Considerations
[译]11. 安全注意事项
Since the protocol generally uses HTTP to transfer data, most of the
same security considerations apply. See section 15 of RFC 2616
[RFC2616].
Media file parsers are typically subject to “fuzzing” attacks.
Clients SHOULD take care when parsing files received from a server so
that non-compliant files are rejected.
Playlist files contain URIs, which clients will use to make network
requests of arbitrary entities. Clients SHOULD range-check responses
to prevent buffer overflows. See also the Security Considerations
section of RFC 3986 [RFC3986].
Clients SHOULD load resources identified by URI lazily to avoid
contributing to denial-of-service attacks.
HTTP requests often include session state (“cookies”), which may
contain private user data. Implementations MUST follow cookie
restriction and expiry rules specified by RFC 2965 [RFC2965]. See
also the Security Considerations section of RFC 2965, and RFC 2964
[RFC2964].
Encryption keys are specified by URI. The delivery of these keys
SHOULD be secured by a mechanism such as HTTP over TLS [RFC5246]
(formerly SSL) in conjunction with a secure realm or a session
cookie.
12. References
[译]12. 引用
12.1. Normative References
[译]12.1. 规范引用
[AES_128] U.S. Department of Commerce/National Institute of
Standards and Technology, “Advanced Encryption Standard
(AES), FIPS PUB 197”, November 2001, <http://
csrc.nist.gov/publications/fips/fips197/fips-197.pdf>.
[ISO_13818]
International Organization for Standardization, “ISO/IEC
International Standard 13818; Generic coding of moving
pictures and associated audio information”, October 2007,
<http://www\.iso\.org/iso/catalogue\_detail?csnumber=44169>\.
Pantos & May Expires December 7, 2010 [Page 20]
Internet-Draft HTTP Live Streaming June 2010
[ISO_8601]
International Organization for Standardization, “ISO/IEC
International Standard 8601:2004; Data elements and
interchange formats -- Information interchange --
Representation of dates and times”, December 2004,
<http://www\.iso\.org/iso/catalogue\_detail?csnumber=40874>\.
[RFC2046] Freed, N. and N. Borenstein, “Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types”, RFC 2046,
November 1996.
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate
Requirement Levels”, BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext
Transfer Protocol -- HTTP/1.1”, RFC 2616, June 1999.
[RFC2964] Moore, K. and N. Freed, “Use of HTTP State Management”,
BCP 44, RFC 2964, October 2000.
[RFC2965] Kristol, D. and L. Montulli, “HTTP State Management
Mechanism”, RFC 2965, October 2000.
[RFC3629] Yergeau, F., “UTF-8, a transformation format of ISO
10646”, STD 63, RFC 3629, November 2003.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform
Resource Identifier (URI): Generic Syntax”, STD 66,
RFC 3986, January 2005.
[RFC4281] Gellens, R., Singer, D., and P. Frojdh, “The Codecs
Parameter for “Bucket” Media Types”, RFC 4281,
November 2005.
[RFC5246] Dierks, T. and E. Rescorla, “The Transport Layer Security
(TLS) Protocol Version 1.2”, RFC 5246, August 2008.
[RFC5652] Housley, R., “Cryptographic Message Syntax (CMS)“,
RFC 5652, September 2009.
[US_ASCII]
American National Standards Institute, “ANSI X3.4-1986,
Information Systems -- Coded Character Sets 7-Bit American
National Standard Code for Information Interchange (7-Bit
ASCII)“, December 1986.
Pantos & May Expires December 7, 2010 [Page 21]
Internet-Draft HTTP Live Streaming June 2010
12.2. Informative References
[译]12.2. 信息引用
[ID3] ID3.org, “The ID3 audio file data tagging format”,
<http://www\.id3\.org/Developer\_Information>\.
[M3U] Nullsoft, Inc., “The M3U Playlist format, originally
invented for the Winamp media player”,
<http://wikipedia\.org/wiki/M3U>\.
Authors’ Addresses
[译]作者地址
Roger Pantos (editor)
Apple Inc.
Cupertino, California
United States
Email: http-live-streaming-review@group.apple.com
William May, Jr.
Apple Inc.
Cupertino, California
United States
Email: http-live-streaming-review@group.apple.com
Pantos & May Expires December 7, 2010 [Page 22]