CN103650526A - 用于实时或近实时流传输的播放列表 - Google Patents

Abstract

描述了用于允许以不同于1X的回放速率来回放流传输媒体的方法、系统和机器可读存储介质。在一实施例中，一种方法可确定在显示期限之前可用的I帧的不同集合，其中每个集合可具有不同的节奏，并且这些集合之一可被选择来用于下载和显示以实现不同于1X的回放。来自客户端设备的字节范围请求可用于取回每个I帧。还描述了其他方法、系统和介质。

Description

用于实时或近实时流传输的播放列表

相关申请

本申请根据35U.S.C.§119（e）主张2011年6月3日提交的美国临时申请No.61/493329的提交日的权益。本美国专利申请还与以下美国专利申请相关，其每个都通过引用合并于此：

（1）2009年6月5日提交的题为“REAL-TIME OR NEARREAL-TIME STREAMING”的申请No.12/479690（案卷号P7437US1）；

（2）2009年6月5日提交的题为“VARIANT STREAMS FORREAL-TIME OR NEAR REAL-TIME STREAMING”的申请No.12/479698（案卷号P7437US2）；

（3）2009年6月5日提交的题为“UPDATABLE REAL-TIME ORNEAR REAL-TIME STREAMING”的申请No.12/479,732（案卷号P7437US3）；以及

（4）2009年6月5日提交的题为“PLAYLISTS FOR REAL-TIMEOR NEAR REAL-TIME STREAMING”的申请No.12/479735（案卷号P7437US4）。

技术领域

本发明的实施例涉及数据传送技术。更特别地，本发明的实施例涉及允许利用诸如超文本传输协议（HTTP）之类的非流传输协议对数据进行流传输（streaming）的技术。

背景技术

内容的流传输一般指的是被不断地从服务器设备发送并被客户端设备接收的多媒体内容。内容通常在其被流传输服务器递送的同时被呈现给终端用户。该名称指的是媒体的递送方法而不是媒体本身。

当前的流传输服务一般需要专门的服务器来向终端用户分发“实况”内容。在任何大规模部署中，这可导致巨大的成本，并且需要专业技术人员来设立和运行。这导致少于期望的内容库可用于流传输。

发明内容

一实施例中的一种方法可以使用在与符合HTTP实况流传输协议（参见http://tools.ietf.org/html/draft-pantos-http-live-streaming-06）的URL相关联的标签中指定的字节范围请求参数来从服务器存储的文件中取回流传输内容。客户端系统接收播放列表，该播放列表包含URL和相关联的标签，其指定节目的可根据此协议来流传输的部分，这些标签包括字节范围参数（例如，范围的长度和从文件中某一位置起的偏移量）；URL从客户端发送到服务器，服务器使用字节范围参数来取回和发送节目的该部分。这样，媒体内容可存储为单个大文件而不是多个更小的文件，并且内容的各部分可利用字节范围请求通过HTTP实况流传输协议来取回，然后被客户端处的播放器以1X回放模式呈现。

还描述了为通过HTTP流传输协议递送的流传输媒体（例如电影）提供“特技播放”模式回放（例如快进或倒回）的方法。该方法使用包括涉及I帧（I帧是可以独立于其他视频帧解码的关键帧或内编码帧）的URL的I帧播放列表。播放器设备或客户端可以下载并使用标准播放列表，其包括涉及所有内容的URL并且允许以正常（例如1X）速率进行回放，播放器设备或客户端可以下载并使用I帧播放列表，其包括关于I帧的URL，用于以正常速率之外的速率（例如8X或正常回放速率的8倍速）进行回放。I帧播放列表可以包括作为与播放列表中的URL相关联的参数的一部分的字节范围参数，其指定文件中的如下数据范围：该数据是用于视频数据的特定I帧的数据；该范围可通过数据长度（例如以字节为单位）和在文件中的开始位置（例如从文件开头起的偏移量）来指定。这样，I帧播放列表可包括指定服务器上的文件内的只涉及I帧的字节范围的那些参数，以便在客户端设备上以特技模式呈现回放。客户端设备可通过使用包含至如下文件的URL的标准播放列表文件来恢复正常回放：这个文件就是包括在I帧播放列表用于提供流传输媒体的特技播放时取回的I帧的那个文件。在一个实施例中（例如MPEG-DASH播放列表文件），用于1X播放列表的标准播放列表文件也包括指定I帧位置的数据。在一实施例中，I帧播放列表中的标签可包括涉及当前I帧与下一I帧之间的时间跨度的参数，此时间跨度可用于确定对于给定回放速率（例如8X或16X）使用哪些I帧。此外，在一实施例中，客户端设备可使用变体播放列表，该变体播放列表涉及用于节目（例如电影）的至少一个标准播放列表（1X）以及用于同一节目的特技播放模式的I帧播放列表。

短语“字节范围”将理解为包括按字节数或者按数据的其他大小或群组的数目指定的范围。字节例如可以是8比特或9比特或16比特或32比特或36比特。

在一实施例中，一种提供流传输媒体的“特技播放”模式回放的方法可接收第一播放列表，该第一播放列表包括用于第二播放列表的URL和用于第三播放列表的URL；第二播放列表可包括多个URL和关联的标签，其指定文件的包含I帧的部分（例如，以字节范围指定的部分），第三播放列表可包括用于以1X回放速度显示视频的多个URL（或单个URL）。第一播放列表可以是变体播放列表，该变体播放列表包括用于1X回放的多个URL（这些URL中的每一个提供不同的分辨率（例如640像素乘480像素等等）或质量（例如颜色比特深度））和用于仅含I帧的播放列表的多个URL（用于I帧播放列表的这些URL中的每一个提供不同的分辨率或质量，以用于1X以外的特技播放模式回放）。与第三播放列表中的多个URL相关联的标签也可包括字节范围，其每个指定用于取回内容和以1X回放速率回放内容的数据范围。该方法还可包括：（a）确定不同于1X的回放速度（例如对于快进有8X或16X或32X，或者对于倒回有-8X或-16X或-32X）；（b）响应于确定回放速度而发送用于第二播放列表的URL；（c）接收第二播放列表；（d）利用第二播放列表中的URL和关联的标签发送对I帧的请求；以及（e）以所选的回放速度呈现（例如在显示设备上显示）响应于对I帧的请求而接收到的I帧。

在一实施例中，本发明的一种方法可使用基于节奏（cadence）的I帧选择来选择可用I帧的子集，使得下载和显示的I帧在时间上至少一定程度上均匀分布；另外，该方法可将该子集限制到小于可用I帧总数的数目。此方法可包括：（a）确定一组参数，例如回放速率和可用于下载至少一个I帧的时间段；（b）确定可用I帧的第一集合，其中该第一集合是基于可随时间动态变化的参数而确定的；（c）确定I帧的多个子集，其中多个子集中的每个子集是该第一集合中的I帧的子集；（d）确定I帧的多个子集中的每个子集的估计下载时间；（e）基于估计下载时间和该组参数选择I帧的多个子集中的一个子集；以及（f）接收并显示I帧的多个子集中的所选子集中的I帧。在此方法的一个实施例中，对I帧的显示提供对I帧中的视频内容的按照回放速率的特技播放回放模式，每个I帧可利用URL和关联的标签来取回（例如下载），标签包括标识文件的包含相应I帧的部分的字节范围。该组参数可包括显示期限参数和正显示的当前I帧的当前电影时间；可用于下载至少一个I帧的时间段可根据当前电影时间和回放速率以及显示期限参数来得出，显示期限参数可被设定为固定持续时间（例如1/2秒或1秒或2秒）。在一实施例中，显示期限参数（例如1秒）被乘以回放速率以产生一乘积（例如1X（8X）），该乘积是一时间值，该时间值被与当前电影时间相加以得出可用于下载至少一个I帧的时间段。在一实施例中，可用于下载至少一个I帧的时间段就是从现在起到显示期限时间的时间。显示期限的使用可确保用户在每个期限时段将会看到至少一个I帧（例如，每秒至少一个I帧）。在一实施例中，I帧的每个子集具有预定的节奏，该节奏在I帧子集之间是不同的，从而每个子集具有相对于其他子集的节奏不同的节奏。在一实施例中，I帧的多个子集中的每个子集的预定节奏是以下之一：（a）第一集合中的可用I帧中的每一个；（b）可用I帧中的每隔一个；（c）可用I帧中的每隔两个，等等。在一实施例中，该组参数包括对每个子集中的I帧数目的限制，从而没有子集可具有比预定数目更多的I帧。

描述了其他方法，并且还描述了系统和机器可读非暂态存储介质。

上述发明内容不包括对本发明的所有方面的穷尽列表。可理解，本发明包括可根据以上概述的各方面以及具体实施方式中公开的各方面的所有适当组合实施的所有系统和方法。

附图说明

在附图中以示例而非限制方式图示了本发明，附图中相似的附图标记指示类似的元素。

图1是可发送和接收实时或近实时内容的服务器和客户端的一个实施例的框图。

图2A是一个或多个服务器设备利用非流传输协议支持媒体内容的技术的一个实施例的流程图。

图2B是一个或多个服务器设备向一个或多个客户端设备提供动态更新的播放列表的技术的一个实施例的流程图。

图2C是一个或多个服务器设备利用多个比特率向客户端设备提供媒体内容的技术的一个实施例的流程图。

图3A是客户端设备利用非流传输协议支持内容的流传输的技术的一个实施例的流程图。

图3B是客户端设备利用多个比特率支持内容的流传输的技术的一个实施例的流程图。

图4是服务器流代理的一个实施例的框图。

图5是客户端流代理的一个实施例的框图。

图6图示了具有多个标签的播放列表文件的一个实施例。

图7是用于如这里所述的组装流的回放技术的一个实施例的流程图。

图8是电子系统的一个实施例的框图。

图9A是示出客户端设备如何可在变体播放列表中的替换内容之间进行切换的示例的流程图。

图9B是示出客户端设备如何可在两个播放列表中的内容之间进行切换的另一流程图。

图9C是示出客户端设备如何可利用音频模式匹配在内容之间进行切换的示例的另一流程图。

图9D概略示出了如何利用音频模式匹配来实现图9C的方法。

图10示出了包含用于1X（正常速度）回放的多个URL的变体播放列表的示例，这些URL中的每一个提供用于不同分辨率或质量的1X回放的播放列表，该变体播放列表还包括用于1X以外速率的回放的多个URL。

图11图示了可在服务器处执行的用于创建I帧播放列表的方法。

图12是可用于处理I帧播放列表并且可执行图14或15所示的方法的客户端设备的框图表示。

图13A示出了视频文件的示例，例如电影或点播视频，在该视频文件中有I帧。

图13B示出了用于图13A所示的视频文件的I帧播放列表的示例。

图14是示出用于处理I帧播放列表的方法示例的流程图。

图15是示出用于处理I帧播放列表的另一方法示例的流程图。

图16示出了具有I帧的视频文件的示例以及如何可使用限度来排除超过I帧的限度的节奏（cadence）。

图17A、17B、17C和17D示出了表示可用I帧的不同子集的不同节奏的示例。

图18是示出在不同分辨率和/或质量的I帧播放列表之间进行切换的方法的流程图。

图19图示了在本发明的一些实施例中可使用的示范性API体系结构的框图。

图20示出了在本发明的一些实施例中可使用的软件栈的示范性实施例。

具体实施方式

在以下说明中，阐述了许多具体细节。然而，没有这些具体细节也可以实施本发明的实施例。在其他情况下，没有详细示出公知的电路、结构和技术，以免模糊对本说明书的理解。

本说明书包括受著作权保护的素材，例如对图形用户界面图像的图示。著作权所有人（包括本发明的受让人）特此保留其对这些素材的权利，包括著作权。著作权所有人不反对任何人对本专利文档或专利公开进行复制再现，只要其出现在专利商标局文件或记录中，但除此以外保留所有一切著作权。Copyright Apple Inc.2009。

本说明书的一个方面涉及在这里描述的播放列表中使用字节范围请求，并且本说明书的另一方面涉及提供流传输媒体中从I帧起的快进或倒回（倒退）回放的方法，以及对具有定时信息的播放列表的使用，定时信息允许在提供快进或倒回时选择I帧的节奏。在结合图1–9D提供背景信息之后，将结合图10–18来描述这些方面。

在一实施例中，这里描述的技术和组件可包括利用非流传输协议（例如HTTP）和其他技术（例如运动图片专家组（Motion PictureExpert Group，MPEG）流）来实现流传输体验的机制。例如，可利用HTTP来提供近实时的流传输体验，从而广播“实况”音乐或体育事件、实况新闻、网络摄像头馈送等。在一个实施例中，协议可将传入的媒体数据分段成多个媒体文件，并将这些分段的媒体文件存储在服务器上。协议还可构建播放列表文件，该播放列表文件包括将客户端引导至存储在服务器上的分段媒体文件的统一资源标识符（Uniform Resource Identifiers，URI）。当根据（一个或多个）播放列表文件来回放分段媒体文件时，客户端可向用户提供“实况”事件的近实时广播。可以以类似的方式提供预记录的内容。

在一个实施例中，服务器可将补充或替换的媒体内容（例如，广告、与体育事件有关的统计数据、主呈现的附加媒体内容）动态地引入到广播事件中。例如，在客户端对媒体事件的回放期间，服务器可向播放列表文件添加额外的URI，这些URI可标识客户端可下载补充媒体文件的位置。可以指令客户端周期性地从服务器取回一个或多个经更新的播放列表文件以便访问服务器引入的任何补充的或附加的（或者这两者）媒体内容。

在一个实施例中，服务器可在累积模式或滚动模式中操作。在累积模式中，服务器可创建播放列表文件并将媒体文件标识符附加到播放列表文件的末尾。然后客户端可从单个播放列表文件（当下载时）访问流的所有部分（例如，用户可从节目的中间开始）。在滚动模式中，服务器可通过以滚动方式从播放列表文件的开头去除媒体文件标识符来限制媒体文件的可用性，从而提供客户端设备可访问的媒体内容的滑动窗口。服务器还可向播放列表添加媒体文件标识符，并且在滚动模式中，服务器可将媒体文件的可用性限制到最近已经添加到播放列表的那些。客户端随后反复地下载播放列表文件的经更新的拷贝以继续观看。播放列表下载的滚动方式在内容可能在时间上是无限的时（例如，来自连续操作的网络摄像头的内容）可能是有用的。客户端可继续以滚动模式反复请求播放列表，直到其在播放列表中发现结束标签为止。

在一个实施例中，该机制通过提供同一呈现的变体流来支持比特率切换。例如，要提供的呈现的若干个版本可被存储在服务器上。每个版本可具有基本相同的内容，但以不同的比特率编码。这可允许客户端设备依据例如对可用带宽的检测来在比特率之间切换，而不会损害回放的连续性。

在一个实施例中，可提供保护特征来保护内容免遭未经授权的使用。例如，可以使用非顺序式媒体文件编号来防止预测。可以使用媒体文件的加密。可使用部分媒体文件列表。也可提供额外的和/或不同的保护特征。

图1是可发送和接收实时或近实时内容的服务器和客户端的一个实施例的框图。图1的示例提供简单的服务器-客户端连接，其中两个客户端经由网络与服务器耦合。利用这里描述的技术和机制可支持任何数目的客户端。另外，根据这里描述的技术和机制，多个服务器可提供内容和/或可一起操作来提供内容。例如，一个服务器可创建内容，创建播放列表并且创建多个媒体（例如文件），其他服务器存储并发送所创建的内容。

网络110可以是任何类型的网络，无论是有线的、无线的（例如，IEEE 802.11、802.16）还是其任何组合。例如，网络100可以是因特网或内联网。作为另一示例，网络110可以是蜂窝网络（例如，3G、CDMA）。在一个实施例中，客户端设备150和180可以能够通过多种网络类型进行通信（例如，每个设备可通过WiFi无线LAN进行通信，也可通过无线蜂窝电话网络进行通信）。例如，客户端设备150和180可以是能够通过蜂窝无线电电话网络以及数据网络进行通信的智能电话或者具备蜂窝能力的个人数字助理。这些设备可以能够在任一类型的网络上利用这里描述的流传输机制，或者甚至根据需要在网络之间进行切换。

服务器120可以以本领域已知的任何方式作为HTTP服务器操作。也就是说，服务器120包括利用HTTP协议提供内容的HTTP服务器代理145。虽然图1的示例是按照HTTP来描述的，但是也可以以类似方式利用其他协议。分段器130和索引器135是驻留在服务器120（或多个服务器）上来如这里所述利用播放列表文件提供媒体文件中的内容的代理。可利用HTTP协议经由HTTP服务器代理145（或经由其他服务器）通过网络110提供这些媒体文件和播放列表文件。这里论述的代理可实现为硬件、软件、固件或其组合。

分段器130可用于将媒体数据流划分成可经由HTTP协议传送的多个媒体文件。索引器135可具有如下功能：创建与分段媒体文件相对应的播放列表文件，使得客户端设备可重组装这些媒体文件来提供由服务器120提供的内容的实时或近实时传送。响应于来自客户端设备的一个或多个请求，HTTP服务器代理145（或其他服务器）可发送由索引器135生成的一个或多个播放列表文件以及由分段器130生成的内容的媒体文件。服务器120还可包括可选的安保代理140，安保代理140提供一个或多个这里论述的安保功能（例如加密）。服务器120还可包括图1未示出的额外组件。

客户端设备150和180可通过网络110接收来自服务器120的播放列表文件和媒体文件。客户端设备可以是能够接收通过网络传送的数据并且利用经由网络接收的数据来生成输出的任何类型的电子设备，例如无线移动设备、PDA、娱乐设备、消费电子设备等。输出可以是任何媒体类型或媒体类型的组合，例如包括音频、视频或其任何组合。

客户端设备150可包括组装器代理160和输出生成器代理165。类似地，客户端设备180可包括组装器代理190和输出生成器代理195。组装器代理160和180从服务器120接收播放列表文件并且使用播放列表文件来从服务器120访问和下载媒体文件。输出生成器代理165和195分别使用下载的媒体文件来生成客户端设备150和160的输出。输出可由一个或多个扬声器、一个或多个显示屏、扬声器和显示屏的组合或者任何其他输入或输出设备来提供。客户端设备还可包括存储器（例如闪存或DRAM等）以充当在媒体文件被接收到时存储媒体文件（例如经压缩的媒体文件或者经解压缩的媒体文件）的缓冲器（buffer）；缓冲器可提供超出当前正在呈现的内容的时间以外许多秒的可呈现内容，从而缓冲内容随后可在新内容正被下载的同时被显示。此缓冲器可在客户端设备正尝试通过间歇性缓慢的网络连接取回内容的同时提供可呈现内容，因此缓冲器可隐藏网络延迟或连接问题。

客户端设备150和180还可分别包括可选的安保代理170和185，其提供一个或多个这里论述的安保功能。客户端设备150和180还可包括图1未示出的额外组件。

在一个实施例中，本申请中描述的技术可用于通过非流传输协议（例如HTTP）传送无限的多媒体数据流。实施例还可包括媒体数据的加密和/或流的替换版本的提供（例如，提供替代的比特率）。因为媒体数据可在创建之后很快被发送，所以数据可被近实时地接收。提供了文件的示例数据格式以及多媒体数据流的服务器（发送者）和客户端（接收者）要采取的动作；然而，也可支持其他格式。

可作为仿真实时流（或近实时流）传送的媒体呈现由指示播放列表文件的统一资源标识符（URI）指定。在一个实施例中，播放列表文件是额外URI的有序列表。播放列表文件中的每个URI引用作为流的片段的媒体文件，该流可以是特定节目的媒体数据的单个连续流。

为了播放媒体数据流，客户端设备从服务器获得播放列表文件。客户端还获得并播放由播放列表文件指示的每个媒体数据文件。在一个实施例中，客户端可以动态地或反复地重新加载播放列表文件以发现额外的和/或不同的媒体片段。

播放列表文件例如可以是扩展M3U播放列表文件。在一个实施例中，使用有效地扩展M3U格式的额外标签。M3U指的是运动图片专家组音频第3层统一资源定位符（Moving Picture Experts GroupAudio Layer 3 Uniform Resource Locator，MP3URL），是用于存储多媒体播放列表的格式。M3U文件是包含供媒体播放器播放的一个或多个媒体文件的位置的文本文件。

播放列表文件在一个实施例中是由各个行组成的扩展M3U格式文本文件。这些行可终止于单个LF字符或者后面跟着LF字符的CR字符。每一行可以是URI、空白行或者以注释字符（例如“#”）开始。URI标识要播放的媒体文件。空白行可被忽略。

以注释字符开始的行可以是注释或标签。标签可开始于#EXT，而注释行可开始于#。注释行通常被服务器和客户端忽略。在一个实施例中，播放列表文件是以UTF-8格式编码的。UTF-8（8比特统一码变换格式）是可变长度字符编码格式。在替换实施例中，可以使用其他字符编码格式。

在接下来的示例中，利用包括如下两个标签的扩展M3U格式：EXTM3U和EXTINF。扩展M3U文件可通过包括“#EXTM3U”的第一行与基本M3U文件区分开。

EXTINF是描述由跟随在该标签之后的URI标识的媒体文件的记录标记。在一个实施例中，每个媒体文件URI之前是EXTINF标签，例如：

#EXTINF:<duration>,<title>

其中“duration”指定媒体文件的持续时间，“title”是目标媒体文件的标题。

在一个实施例中，可以使用以下标签来管理媒体文件的传输和回放：

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-TARGETDURATION标签可指示将被添加到呈现的下一媒体文件的大致持续时间。它可被包括在播放列表文件中，格式可以是：

#EXT-X-TARGETDURATION:<seconds>

其中“seconds”指示媒体文件的持续时间。在一个实施例中，实际持续时间可与该标签指示的目标持续时间略有不同。在一个实施例中，指示片段的每个URI将与该片段的大致持续时间相关联；例如，关于一片段的URI可前缀有指示该片段的大致持续时间的标签。

播放列表文件中的每个媒体文件URI可具有唯一的序列号。在一个实施例中，URI的序列号（如果存在）等于它前面的URI的序列号加一。EXT-X-MEDIA-SEQUENCE标签可指示出现在播放列表文件中的第一URI的序列号，格式可以是：

#EXT-X-MEDIA-SEQUENCE:<number>

其中“number”是URI的序列号。如果播放列表文件不包括#EXT-X-MEDIA-SEQUENCE标签，则可以认为播放列表中的第一URI的序列号为1。在一个实施例中，序列编号可以是非顺序式的；例如，诸如1、5、7、17等等之类的非顺序式序列编号可以使得难以预测序列中的下一编号，并且这可帮助保护内容免遭盗版。帮助保护内容的另一选项是在任何给定时间只揭露播放列表的一部分。

一些媒体文件可被加密。EXT-X-KEY标签提供可用于对跟随其后的媒体文件进行解密的信息，格式可以是：

#EXT-X-KEY:METHOD=<method>[,URI=″<URI>″]

METHOD参数指定加密方法，URI参数（如果存在）指定如何获得密钥。

NONE的加密方法指示没有加密。可以使用各种加密方法，例如AES-128，AES-128指示使用具有128比特密钥和PKCS7填充的高级加密标准加密[参见RFC3852]。新的EXT-X-KEY标签取代任何先前的EXT-X-KEY标签。

具有URI参数的EXT-X-KEY标签标识密钥文件。密钥文件可包含用于对播放列表文件中列出的后续媒体文件进行解密的密钥。例如，AES-128加密方法使用16个八字节的密钥。密钥文件的格式可以是二进制格式的16个八字节的压缩阵列。

使用AES-128通常要求在加密和解密时提供相同的16个八字节的初始化向量（IV）。改变IV可用于增大密码的强度。当使用AES-128加密时，在对媒体文件进行加密或解密时可使用媒体文件的序列号作为IV。

EXT-X-PROGRAM-DATE-TIME标签可将下一媒体文件的开头与绝对日期和/或时间相关联，并且可包括或指示时区。在一个实施例中，日期/时间表示是ISO/IEC 8601:2004。标签格式可以是：

EXT-X-PROGRAM-DATE-TIME:<YYYY-MM-DDThh:mm:ssZ>

EXT-X-ALLOW-CACHE标签可用于指示客户端是否可以将下载的媒体文件缓存来供以后回放。标签格式可以是：

EXT-X-ALLOW-CACHE:<YES|NO>

EXT-X-ENDLIST标签在一个实施例中指示没有更多媒体文件会被添加到播放列表文件。标签格式可以是：

EXT-X-ENDLIST

在一个实施例中，如果播放列表包含最终的片段或媒体文件，则该播放列表将具有EXT-X-ENDLIST标签。

EXT-X-STREAM-INF标签可用于指示播放列表文件中的下一URI标识另一播放列表文件。标签格式在一个实施例中可以是：

EXT-X-STREAM-INF:[attribute=value][,attribute=value]*<URI>其中可以使用以下属性。属性BANDWIDTH=<n>是表达为每秒比特数的流比特率的大致上限。属性PROGRAM-ID=<i>是唯一地标识该播放列表文件的范围内的特定呈现的编号。播放列表文件可包括具有相同PROGRAM-ID的多个EXT-X-STREAM-INF URI来描述同一呈现的变体流。变体流和变体播放列表在本公开中有进一步的描述（例如参见图9A-9D）。

前述标签和属性可被服务器设备用于组织、发送和处理表示原始媒体内容的媒体文件。客户端设备使用该信息来以向客户端设备的用户提供实时或近实时流传输体验（例如观看诸如音乐或体育事件之类的实况广播）的方式重组装并且呈现媒体文件。

播放列表文件中的每个媒体文件URI标识作为原始呈现（即，原始媒体内容）的片段的媒体文件。在一个实施例中，每个媒体文件被格式化为MPEG-2传输流、MPEG-2节目流或MPEG-2音频基本流。格式可通过指定编解码器来指定，播放列表可通过指定编解码器来指定格式。在一个实施例中，一呈现中的所有媒体文件都具有相同的格式；然而，在其他实施例中可支持多种格式。传输流文件在一个实施例中应当包含单个MPEG-2节目，并且在每个文件开始处应当具有节目关联表和节目映射表。包含视频的文件应当具有至少一个关键帧和足够的信息来完整地初始化视频解码器。客户端应当通过选择合理的子集来准备好处理特定类型（例如音频或视频）的多条轨道。客户端在一个实施例中应当忽略传输流内的其未识别出的私有流。用于一媒体文件内部的流内的和跨多个媒体文件的相应流之间的样本的编码参数应当保持一致。然而，客户端在遇到编码变化时应当应对编码变化，其方式例如是通过缩放视频内容以适应分辨率变化。

图2A是一个或多个服务器设备利用非流传输协议支持媒体内容的技术的一个实施例的流程图。图2A的示例是按照HTTP来提供的；然而，可以按类似的方式利用其他非流传输协议。图2A的示例是按照单个服务器执行某些任务来提供的。然而，可以利用任何数目的服务器。例如，向客户端设备提供媒体文件的服务器可以是与将内容分段成多个媒体文件的服务器不同的设备。

服务器设备在操作200中接收要提供的内容。内容可表示实况音频和/或视频（例如，体育事件、实况新闻、网络摄像头馈送）。内容也可表示预记录的内容（例如，已记录的音乐会、培训班等）。内容可被服务器根据本领域已知的任何格式和协议接收，无论是否是流传输格式。在一个实施例中，内容以MPEG-2流的形式被服务器接收；然而，也可支持其他格式。

服务器随后在操作210中可临时存储内容的至少一些部分。内容或内容的至少一些部分可被临时存储在例如存储设备（例如存储区域网络中的硬盘等）上或存储器中。或者，可经由存储介质（例如，致密盘、闪存盘）接收内容，内容可从该存储介质传送到存储设备或存储器。在一个实施例中，服务器具有编码器，编码器根据需要将内容转换成一个或多个流（例如MPEG-2）。此转换可在不永久存储所接收到的内容的情况下发生，并且在一些实施例中，存储操作210可被省略或者在其他实施例中其可以是更长期的存储（例如归档存储）。

在操作220中，要提供的内容被分段成多个媒体文件。在一个实施例中，服务器将流转换成分开且不同的媒体文件（即，片段），这些媒体文件可利用标准的web服务器来分发。在一个实施例中，服务器在支持个体媒体文件的有效解码的点（例如，在分组和关键帧边界上，例如PES分组边界和i帧边界）对媒体流进行分段。媒体文件可以是原始流的具有大致相等的持续时间的部分。服务器还为每个媒体文件创建URI。这些URI允许客户端设备访问媒体文件。

因为片段是利用固有地递送整个文件的HTTP服务器来提供的，所以在完整的分段媒体文件可被提供给客户端之前，服务器应当使其可用。从而，客户端可（在时间上）滞后广播，滞后量为至少一个媒体文件的长度。在一个实施例中，媒体文件大小是基于滞后时间和有太多文件之间的平衡的。

在一个实施例中，支持两种会话类型（实况会话和事件会话）。对于实况会话，只保留流的固定大小部分。在一个实施例中，过时的内容媒体文件被从节目播放列表文件中去除，并且可被从服务器中去除。第二类会话是事件会话，其中客户端可调谐到广播的任何一点（例如，从开头开始，从中间点开始）。这类会话例如可用于重广播。

在操作230中，媒体文件被存储在服务器存储器中。在操作230中存储文件之前，可通过诸如加密之类的安保特征来保护媒体文件。媒体文件被存储为准备好利用服务器设备上的Web服务器应用所支持的（或者进行发送的另一设备所支持的）网络协议（例如，HTTP或HTTPS）发送的文件。

在操作240中，生成一个或多个播放列表文件来指示应当以何种顺序组装媒体文件以重建原始内容。（一个或多个）播放列表文件可利用扩展M3U标签和这里描述的标签来提供信息供客户端设备访问和重组装媒体文件以在客户端设备上提供流传输体验。关于每个媒体文件的URI按照要播放媒体文件的顺序被包括在（一个或多个）播放列表文件中。服务器也可以为（一个或多个）播放列表文件创建一个或多个URI以允许客户端设备访问该（一个或多个）播放列表文件。

在操作250中，（一个或多个）播放列表文件可被存储在服务器上。虽然媒体文件和（一个或多个）播放列表文件的创建和存储在图2A中是按特定顺序呈现的，但也可使用不同的顺序。例如，可以在创建或存储媒体文件之前创建（一个或多个）播放列表文件。作为另一示例，（一个或多个）播放列表文件和媒体文件可在其中任一个被存储之前被创建。

如果媒体文件要被加密，则（一个或多个）播放列表文件可定义URI，该URI允许经授权的客户端设备获得包含加密密钥的密钥文件来对媒体文件进行解密。可利用安全连接（例如HTTPS）来传送加密密钥。作为另一示例，可利用HTTPS来传送（一个或多个）播放列表文件。作为又一示例，可按不可预测的顺序布置媒体文件，以使得客户端在没有（一个或多个）播放列表文件的情况下不能重建流。

如果加密方法是AES-128，则例如AES-128 CBC加密可被应用到各个媒体文件。在一个实施例中，整个文件被加密。在一个实施例中，通常不跨媒体文件应用密码块链接。媒体文件的序列如上所述被用作IV。在一个实施例中，服务器向播放列表文件的末尾添加具有密钥URI的EXT-X-KEY标签。服务器随后利用该密钥来对所有后续媒体文件加密，直到作出加密配置的改变为止。

为了切换到新的加密密钥，服务器可经由与该呈现中使用的所有先前的密钥URI不同的新URI来使新密钥可用。服务器还向播放列表文件的末尾添加具有新密钥URI的EXT-X-KEY标签，并且利用该新密钥对所有后续的媒体文件进行加密。

为了结束加密，服务器可在播放列表文件的末尾处添加具有加密方法NONE的EXT-X-KEY标签。该标签（以“NONE”作为方法）在一个实施例中不包括URI参数。如上所述，所有后续的媒体文件不被加密，直到作出加密配置的改变为止。服务器不从播放列表文件中去除EXT-X-KEY标签，如果该播放列表文件包含去到利用该密钥加密的媒体文件的URI的话。在操作270中，服务器可响应于客户端请求通过网络发送（一个或多个）播放列表文件和媒体文件，这将联系图3A来更详细地描述。

在一个实施例中，服务器响应于接收到来自客户端设备的对播放列表文件的请求而向客户端设备发送该播放列表文件。客户端设备可利用已提供给该客户端设备的URI来访问/请求播放列表文件。URI指示播放列表文件在服务器上的位置。作为响应，服务器可将播放列表文件提供给客户端设备。客户端设备可利用播放列表文件中的标签和URI（或其他标识符）来访问多个媒体文件。

在一个实施例中，服务器可将媒体文件的可用性限制于最近添加到（一个或多个）播放列表文件的那些。为此，每个播放列表文件可包括仅一个EXT-X-MEDIA-SEQUENCE标签，并且对于从播放列表文件中去除的每个媒体文件URI，该值可被递增1。媒体文件URI可按其被添加的顺序被从（一个或多个）播放列表文件中去除。在一个实施例中，当服务器从（一个或多个）播放列表文件中去除媒体文件URI时，该媒体文件在一段时间中对客户端保持可用，该段时间的长度等于该媒体文件的持续时间加上该媒体文件出现于其中的最长播放列表文件的持续时间。

播放列表文件的持续时间是该播放列表文件内的媒体文件的持续时间的总和。也可使用其他持续时间。在一个实施例中，服务器可始终在播放列表中维持至少三个主呈现媒体文件，除非存在EXT-X-ENDLIST标签。

图2B是一个或多个服务器设备向一个或多个客户端设备提供动态更新的播放列表的技术的一个实施例的流程图。可利用这里描述的累积模式或滚动模式来更新播放列表。图2B的示例是按照HTTP来提供的；然而，可以按类似的方式利用其他非流传输协议（例如，HTTPS等等）。图2B的示例是按照一服务器执行某些任务来提供的。然而，可以利用任何数目的服务器。例如，向客户端设备提供媒体文件的服务器与将内容分段成多个媒体文件的服务器可以是不同的设备。

服务器设备在操作205中接收要提供的内容。服务器随后在操作215中可临时存储内容的至少一些部分。操作215可与图2A中的操作210类似。在操作225中，要提供的内容被分段成多个媒体文件。在操作235中，媒体文件可被存储在服务器存储器中。在操作235中存储文件之前，可通过诸如加密之类的安保特征来保护媒体文件。

在操作245中，生成一个或多个播放列表文件来指示应当以何种顺序组装媒体文件以重建原始内容。在操作255中，（一个或多个）播放列表文件可被存储在服务器上。虽然媒体文件和（一个或多个）播放列表文件的创建和存储在图2B中是按特定顺序给出的，但也可使用不同的顺序。

在操作275中，服务器（或另一服务器）可响应于客户端请求而通过网络发送（一个或多个）播放列表文件和媒体文件，这将联系图3A-3B来更详细地描述。

服务器可出于各种原因而更新（一个或多个）播放列表文件。在操作285中，服务器可接收要提供给客户端设备的额外数据。额外数据可以是在操作255中存储（一个或多个）播放列表文件之后接收的。额外数据例如可以是实况呈现的额外部分，或者关于现有呈现的额外信息。额外数据可包括广告或统计数据（例如，与体育事件有关的得分或数据）。额外数据可（通过半透明）被覆盖在呈现上或者在侧边栏用户界面中呈现。额外数据可按与原始接收的数据相同的方式被分段。如果额外数据构成广告或者要插入到播放列表所表示的节目中的其他内容，则额外数据可在操作215中被（至少临时地）存储，在操作225中被分段并且在操作235中被存储；在存储分段的额外数据之前，额外数据的片段可被加密。然后在操作245中，将生成经更新的播放列表，其包含节目和额外数据。播放列表基于额外数据被更新并且在操作255中再次被存储。对（一个或多个）播放列表文件的改变从客户端设备的角度来看应当以原子的方式进行。经更新的播放列表在一实施例中替代先前的播放列表。如下文更详细论述的那样，客户端设备可多次请求播放列表。这些请求使得客户端设备能够利用最近的播放列表。在一个实施例中，额外数据可以是元数据；在此情况下，播放列表不需要被更新，但是片段可被更新来包括元数据。例如，元数据可包含可与片段中的时间戳匹配的时间戳，并且元数据可被添加到具有匹配的时间戳的片段。

经更新的播放列表也可导致媒体文件的去除。在一个实施例中，服务器应当按照关于媒体文件的URI被添加到播放列表的顺序从播放列表中去除关于媒体文件的URI。在一个实施例中，如果服务器去除整个呈现，则其使得（一个或多个）播放列表文件对于客户端设备不可用。在一个实施例中，服务器维持媒体文件和（一个或多个）播放列表文件，维持的时间为包含媒体文件的最长的（一个或多个）播放列表文件的持续时间，以允许当前的客户端设备完成对呈现的访问。因此，播放列表文件中的每个媒体文件URI可前缀有EXT-X-STREAM-INF标签以指示该播放列表文件指示的媒体文件的大致累积持续时间。在替代实施例中，可立即去除媒体文件和（一个或多个）播放列表文件。

随后来自客户端设备的对播放列表的请求导致服务器在操作275中提供经更新的播放列表。在一个实施例中，播放列表被定期地更新，例如与目标持续时间有关的时间周期。播放列表文件的周期性更新允许了服务器提供对动态变化的呈现的访问。

图2C是一个或多个服务器设备利用多个比特率向客户端设备提供媒体内容的技术的一个实施例的流程图，这是使用替换流的一种形式。图2C的示例是按照HTTP来提供的；然而，可以按类似的方式利用其他非流传输协议。图2C的示例是按照服务器执行某些任务来提供的。然而，可以利用任何数目的服务器。例如，向客户端设备提供媒体文件的服务器与将内容分段成多个媒体文件的服务器可以是不同的设备。

在一个实施例中，服务器可提供多个播放列表文件或者在单个播放列表文件中具有多个媒体文件列表的单个播放列表文件，以提供同一呈现的不同编码。如果提供不同的编码，则（一个或多个）播放列表文件可包括提供不同比特率的各个变体流以允许客户端设备在编码之间动态地切换（这将联系图9A-9D来进一步描述）。具有变体流的播放列表文件对于每个变体流可包括EXT-X-STREAM-INF标签。同一呈现的每个EXT-X-STREAM-INF标签可具有相同的PROGRAM-ID属性值。每个呈现的PROGRAM-ID值在变体流内是唯一的。

在一个实施例中，服务器在产生变体流时满足以下约束。每个变体流可由相同内容构成，其中包括不是主呈现的一部分的可选内容。在流的最小目标持续时间的精度内，服务器可使得相同时段的内容可用于所有变体流。变体流的媒体文件在一个实施例中是具有样本时间戳的MPEG-2传输流或MPEG-2节目流，样本时间戳对于所有变体流中的相应内容是匹配的。另外，所有变体流在一个实施例中应当包含相同的音频编码。这允许了客户端设备在变体流之间切换而不丢失内容。

参考图2C，服务器设备在操作202中接收要提供的内容。服务器随后在操作212中可至少临时存储内容。在操作222中，要提供的内容被分段成多个媒体文件。在操作232中，针对所选的比特率（或者其他编码参数的所选值）对每个媒体文件进行编码并将其存储在服务器上。例如，媒体文件可针对高带宽、中带宽和低带宽连接。媒体文件可在存储之前被加密。针对各种类型的连接对媒体文件进行编码可被选择来在目标带宽水平上提供流传输体验。

在一个实施例中，在操作242中生成具有如这里所述的指示各种编码水平的标签的变体播放列表。标签例如对于每个编码水平可包括EXT-X-STREAM-INF标签，其中带有去到相应媒体播放列表文件的URI。

此变体播放列表可包括去到各种编码水平的媒体播放列表文件的URI。从而，客户端设备可以从指示编码水平的变体播放列表中提供的替换物之中选择目标比特率并且取回相应的播放列表文件。在一个实施例中，客户端设备可在回放期间在比特率之间改变（例如，如联系图9A-9D所述）。指示各种编码水平的变体播放列表在操作252中被存储在服务器上。在操作242中，在变体播放列表中涉及的每个播放列表也可被生成，然后在操作252中被存储。

响应于来自客户端设备的请求，服务器在操作272中可发送指示各种编码水平的变体播放列表。服务器在操作282中可接收对变体播放列表指定的媒体播放列表中与所选比特率相对应的媒体播放列表的请求。响应于该请求，服务器在操作292中发送与来自客户端设备的请求相对应的媒体播放列表文件。客户端设备随后可使用该媒体播放列表来向服务器请求媒体文件。服务器在操作297中响应于请求将媒体文件提供给客户端设备。

图3A是客户端设备利用非流传输协议支持内容的流传输的技术的一个实施例的流程图。图3A的示例是按照HTTP来提供的；然而，可以按类似的方式利用其他非流传输协议。图3A-3B中所示的方法可由一个客户端设备或若干个分开的客户端设备执行。例如，在这些方法中的任何一种的情况下，单个客户端设备可执行所有操作（例如，请求播放列表文件、利用播放列表文件中的URI请求媒体文件、组装媒体文件以生成并提供呈现/输出）或者若干个不同的客户端设备可执行一些但并非所有操作（例如，第一客户端设备可请求播放列表文件并利用播放列表文件中的URI请求媒体文件并且可将这些媒体文件存储来供第二客户端设备使用，第二客户端设备可处理媒体文件以生成并提供呈现/输出）。

客户端设备在操作300中可向服务器请求播放列表文件。在一个实施例中，该请求是根据遵从HTTP的协议作出的。该请求利用去到存储在服务器上的初始播放列表文件的URI。在替代实施例中，可支持其他非流传输协议。响应于该请求，服务器将通过网络把相应的播放列表文件发送到客户端。如上所述，网络可以是有线的或无线的并且可以是有线或无线网络的任何组合。另外，网络可以是数据网络（例如IEEE 802.11、IEEE 802.16）或蜂窝电话网络（例如3G）。

客户端设备在操作310中可接收播放列表文件。在操作320中播放列表文件可被存储在客户端设备的存储器中。存储器例如可以是硬盘、闪存、随机存取存储器。在一个实施例中，每次从播放列表URI加载或重加载播放列表文件时，客户端就进行检查以确定该播放列表文件开始于#EXTM3U标签，如果该标签不存在则不继续。如上所述，播放列表文件包括一个或多个标签以及去到媒体文件的一个或多个URI。

客户端设备可包括组装器代理，组装器代理通过在操作330中请求播放列表文件中的URI所指示的媒体文件来使用播放列表文件来重组装原始内容。在一个实施例中，组装器代理是作为标准Web浏览器应用的一部分的插件模块。在另一实施例中，组装器代理可以是独立的应用，其与Web浏览器交互以利用（一个或多个）播放列表文件接收并组装媒体文件。作为又一示例，组装器代理可以是嵌入在客户端设备中的专用硬件或固件组件。

组装器使得来自播放列表文件的媒体文件被从URI所指示的服务器下载。如果播放列表文件包含EXT-X-ENDLIST标签，则播放列表文件所指示的任何媒体文件可被首先播放。如果EXT-X-ENDLIST标签不存在，则除了最后一个和倒数第二个媒体文件以外的任何媒体文件可被首先播放。一旦选择了要播放的第一媒体文件，播放列表文件中的后续媒体文件在一个实施例中就按照它们出现在播放列表文件中的顺序被加载（否则内容被乱序呈现）。在一个实施例中，客户端设备在需要媒体文件之前就尝试加载媒体文件（并将它们存储在缓冲器中）以提供不间断的回放并且对网络延迟和吞吐量的临时变化进行补偿。

在操作340中，下载的（一个或多个）媒体文件可被存储在客户端设备上的存储器中。可存储内容的存储器可以是客户端设备上的任何类型的存储器，例如随机存取存储器、硬盘或视频缓冲器。存储可以是临时的以允许回放，或者可以是永久的。如果播放列表文件包含EXT-X-ALLOW-CACHE标签并且其值为NO，则客户端在下载的媒体文件被播放之后不存储这些媒体文件。如果播放列表包含EXT-X-ALLOW-CACHE标签并且其值为YES，则客户端设备可无限期地存储媒体文件以便以后重放。客户端设备可使用EXT-X-PROGRAM-DATE-TIME标签的值来向用户显示节目起始时间。在一个实施例中，客户端可缓冲多个媒体文件，以使得其不那么容易受网络卡顿（jitter）的影响，以便提供更好的用户体验。

在一个实施例中，如果解密方法是AES-128，则AES-128 CBC解密被应用到各个媒体文件。整个文件被解密。在一个实施例中，不跨媒体文件应用密码块链接。媒体文件的序列号如上所述可用作初始化向量。

在操作350中，可从存储器中将内容从客户端设备输出。输出或呈现例如可以是经由内置的扬声器或头戴式耳机的音频输出。输出可包括经由屏幕输出或从客户端设备投影的视频。可以利用本领域已知的任何类型的输出。在操作351中，客户端设备确定在存储的当前播放列表中是否有任何更多的尚未被播放或以其他方式呈现的媒体文件。如果存在这样的媒体文件（并且如果它们尚未被请求），则处理返回到操作330，在该操作中一个或多个媒体文件被请求，并且该过程重复。如果没有这样的媒体文件（即，当前播放列表中的所有媒体文件都已被播放），则处理前进到操作352，该操作确定播放列表文件是否包括结束标签。

如果在操作352中播放列表包括结束标签（例如，EXT-X-ENDLIST），则当播放列表文件所指示的媒体文件已被播放时，回放停止。如果在播放列表中没有结束标签，则客户端再次向服务器请求播放列表并且返回到操作300以获得该节目的另一个或经更新的播放列表。

如联系图2B更详细论述的那样，服务器可更新播放列表文件以引入补充内容（例如，与实况广播中的额外媒体内容相对应的额外媒体文件标识符）或额外内容（例如，流中接下来的内容）。为了访问补充内容或额外内容，客户端可从服务器重加载经更新的播放列表。这可提供一种机制，通过该机制，即使在与播放列表文件相关联的媒体内容的回放期间也可动态更新播放列表文件。客户端可基于多种触发器来请求播放列表文件的重加载。结束标签的缺乏是一个这种触发器。

在一个实施例中，客户端设备周期性地重加载（一个或多个）播放列表文件，除非播放列表文件包含EXT-X-ENDLIST标签。当客户端设备第一次加载播放列表文件或者重加载播放列表文件并发现该播放列表文件从上次被加载起已改变了时，客户端在尝试再次重加载播放列表文件之前可等待一段时间。此时段被称为初始最小重加载延迟。它是从客户端开始加载播放列表文件的时间起测量的。

在一个实施例中，初始最小重加载延迟是播放列表文件中的最后媒体文件的持续时间或三倍的目标持续时间中较小的那个。媒体文件持续时间由EXTINF标签指定。如果客户端重加载播放列表文件并且发现其没有变化，则客户端在重试之前可等待一段时间。一个实施例中的最小延迟是目标持续时间的三倍或初始最小重加载延迟的倍数中较小的那个。在一个实施例中，此倍数对于第一次尝试是0.5，对于第二次尝试是1.5，并且对于后续的尝试是3.0；然而，可以使用其他倍数。

每次播放列表文件被加载或重加载时，客户端设备就检查播放列表文件以确定要加载的下一媒体文件。要加载的第一文件是如上所述被选择为首先播放的媒体文件。如果要播放的第一媒体文件已被加载并且播放列表文件不包含EXT-X-MEDIA-SEQUENCE标签，则客户端可验证当前的播放列表文件在起初找到最后加载的媒体文件的URI的偏移量处包含该URI，如果没有找到该文件则停止回放。要加载的下一媒体文件可以是播放列表文件中跟随在最后加载的URI之后的第一媒体文件URI。

如果要播放的第一文件已被加载并且播放列表文件包含EXT-X-MEDIA-SEQUENCE标签，则要加载的下一媒体文件可以是具有大于加载的最后媒体文件的序列号的最低序列号的那个。如果播放列表文件包含指定密钥文件URI的EXT-X-KEY标签，则客户端设备获得密钥文件并且使用密钥文件内的密钥来对跟随在EXT-X-KEY标签之后的媒体文件进行解密，直到遇到另一EXT-X-KEY标签为止。

在一个实施例中，客户端设备利用与先前使用的相同的URI来下载播放列表文件。从而，如果对播放列表文件作出了改变，则客户端设备可使用经更新的播放列表文件来取回媒体文件并且基于这些媒体文件提供输出。

对播放列表文件的改变例如可包括删除去到媒体文件的URI、添加去到新媒体文件的URI，用去到替代媒体文件的URI来替代。当对播放列表文件作出改变时，可更新一个或多个标签以反映（一个或多个）改变。例如，如果对媒体文件的改变导致对播放列表文件所指示的媒体文件的回放的持续时间的改变，则可更新持续时间标签。

图3B是客户端设备利用多个比特率支持内容的流传输的技术的一个实施例的流程图，这是替换流的一种形式。图3B的示例是按照HTTP来提供的；然而，可以按类似的方式利用其他非流传输协议。

客户端设备在操作370中可请求播放列表文件。如上所述，可利用提供给客户端设备的URI来取回播放列表文件。在一个实施例中，播放列表文件包括媒体文件的变体流的列表来以不同的比特率提供相同的内容；换言之，单个播放列表文件包括关于每个变体流的媒体文件的URI。图3B中所示的示例使用此实施例。在另一实施例中，变体流可由分开提供给客户端的、各自以不同比特率提供相同内容的多个不同的播放列表文件表示，并且变体播放列表可以提供用于不同播放列表文件中的每一个的URI。这允许客户端设备基于客户端条件来选择比特率。

在操作375中客户端设备可取回（一个或多个）播放列表文件。在操作380中（一个或多个）播放列表文件可被存储在客户端设备的存储器中。在操作385中客户端设备可基于当前的网络连接速度来选择要使用的比特率。在操作390中利用与所选比特率相对应的播放列表文件中包括的URI来向服务器请求媒体文件。取回的媒体文件可被存储在客户端设备的存储器中。在操作394中客户端设备利用媒体文件提供输出，并且客户端设备确定是否改变比特率。

在一个实施例中，客户端设备最初选择最低可用比特率。在播放媒体的同时，客户端设备可监视可用带宽（例如当前网络连接比特率）以确定可用带宽是否支持使用更高比特率来回放。如果是，则客户端设备可选择更高比特率并访问由更高比特率媒体播放列表文件所指示的媒体文件。也可支持相反的情况。如果回放消耗了太多带宽，则客户端设备可选择更低比特率并访问由更低比特率媒体播放列表文件所指示的媒体文件。

如果客户端设备在操作394中例如响应于可用带宽的变化或者响应于用户输入而改变了比特率，则客户端设备在操作385中可选择不同的比特率。在一个实施例中，为了选择不同的比特率，客户端设备可利用与新选择的比特率相对应的播放列表文件中包括的URI的不同列表。在一个实施例中，客户端设备可在访问播放列表内的媒体文件期间改变比特率。

如果在操作394中比特率不变化，则客户端设备确定在当前播放列表中是否有任何更多的尚未被取回并呈现的未播放的媒体文件。如果存在这样的媒体文件，则处理返回到操作390，并且一个或多个媒体文件被利用播放列表中关于这些文件的URI来取回。如果没有这样的媒体文件（即，当前播放列表中的所有媒体文件都已被播放），则处理前进到操作396，在该操作中确定播放列表是否包括结束标签。如果包括，则节目的回放已结束并且该过程完成；如果不包括，则处理返回到操作370，并且客户端设备请求重加载关于该节目的播放列表，并且该过程重复进行图3B中所示的方法。

图4是服务器流代理的一个实施例的框图。将理解，服务器流代理400的元件可分布在若干个服务器设备上。例如，第一服务器设备可包括分段器430、索引器440和安保机构450，但不包括文件服务器460，而第二服务器设备可包括文件服务器450，但不包括分段器430、索引器440和安保机构450。在此示例中，第一服务器设备将准备播放列表和媒体文件，但不会将它们发送到客户端设备，而一个或多个第二服务器设备将接收并可选地存储播放列表和媒体文件，并且将把播放列表和媒体文件发送到客户端设备。服务器流代理400包括实现逻辑功能控制以引导服务器流代理400的操作的控制逻辑器410，以及与引导服务器流代理400的操作相关联的硬件。逻辑器可以是硬件逻辑电路或者软件例程或固件。在一个实施例中，服务器流代理400包括一个或多个应用412，这些应用412表示向控制逻辑器410提供指令的代码序列和/或程序。

服务器流代理400包括存储器414，存储器414表示存储器设备或者对存储器资源的访问，用于存储数据或指令。存储器414可包括服务器流代理400本地的存储器，以及/或者替代地包括服务器流代理400所驻留在的主机系统的存储器。服务器流代理400还包括一个或多个接口416，这些接口416表示服务器流代理400外部的实体（电子的或人类的）往来于服务器流代理400的访问接口（输入/输出接口）。

服务器流代理400还可包括服务器流引擎420，服务器流引擎420表示使得服务器流代理400能够提供如这里所述的实时或近实时流传输的一个或多个功能。图4的示例提供了可包括在服务器流引擎420中的若干个组件；然而，也可包括不同的或额外的组件。在提供流传输环境时可涉及的示例组件包括分段器430、索引器440、安保机构450和文件服务器460。这些组件中的每一个还可包括其他组件来提供其他功能。这里使用的组件指的是例程、子系统等等，无论是以硬件、软件、固件还是其某种组合实现的。

分段器430把要提供的内容划分成媒体文件，这些媒体文件可利用Web服务器协议（例如HTTP）作为文件来传送。例如，分段器430可将内容划分成采取预定文件格式的预定的固定大小数据块。

索引器440可提供一个或多个播放列表文件，这些播放列表文件提供去到由分段器430创建的媒体文件的地址或URI。索引器440例如可创建一个或多个文件，这些文件具有与由分段器430创建的每个文件相对应的标识符的有序列表。这些标识符可由分段器430或索引器440来创建或指派。索引器440还可在播放列表文件中包括一个或多个标签以支持对媒体文件的访问和/或利用。

安保机构450可提供安保特征（例如加密），例如上文论述的那些。Web服务器460可提供与将存储在主机系统上的文件提供给远程客户端设备有关的Web服务器功能。Web服务器460可支持例如遵从HTTP的协议。

图5是客户端流代理的一个实施例的框图。将理解，客户端流代理的元件可分布在若干个客户端设备上。例如，第一客户端设备可包括组装器530和安保机构550并且可将经解密的媒体文件流提供给第二客户端设备，第二客户端设备包括输出生成器540（但不包括组装器530和安保机构550）。在另一示例中，主客户端设备可取回播放列表并将它们提供给次客户端设备，次客户端设备取回播放列表中指定的媒体文件并且生成输出以呈现这些媒体文件。客户端流代理500包括实现逻辑功能控制以引导客户端流代理500的操作的控制逻辑器510，以及与引导客户端流代理500的操作相关联的硬件。逻辑器可以是硬件逻辑电路或者软件例程或固件。在一个实施例中，客户端流代理500包括一个或多个应用512，这些应用512表示向控制逻辑器510提供指令的代码序列或程序。

客户端流代理500包括存储器514，存储器514表示存储器设备或者对存储器资源的访问，用于存储数据和/或指令。存储器514可包括客户端流代理500本地的存储器，以及/或者包括客户端流代理500所驻留在的主机系统的存储器。客户端流代理500还包括一个或多个接口516，这些接口516表示客户端流代理500外部的实体（电子的或人类的）往来于客户端流代理500的访问接口（输入/输出接口）。

客户端流代理500还可包括客户端流引擎520，客户端流引擎520表示使得客户端流代理500能够提供如这里所述的实时或近实时流传输的一个或多个功能。图5的示例提供了可包括在客户端流引擎520中的若干个组件；然而，也可包括不同的或额外的组件。在提供流传输环境时可涉及的示例组件包括组装器530、输出生成器540和安保机构550。这些组件中的每一个还可包括其他组件来提供其他功能。这里使用时，组件指的是例程、子系统等等，无论是以硬件、软件、固件还是其某种组合实现的。

组装器530可利用从服务器接收的播放列表文件来经由Web服务器协议（例如HTTP）从服务器访问媒体文件。在一个实施例中，组装器530可使得播放列表文件中的URI所指示的媒体文件被下载。组装器530可对播放列表文件中包括的标签进行响应。

输出生成器540可提供接收到的媒体文件作为主机系统上的音频或视觉输出（或者音频和视觉两者）。输出生成器540例如可使得音频被输出到一个或多个扬声器并且视频被输出到显示设备。安保机构550可提供安保特征，例如上文论述的那些。

图6图示了具有多个标签的播放列表文件的一个实施例。图6的示例播放列表包括特定数目和有序的标签。这只是出于描述目的提供的。一些播放列表文件可包括更多、更少或不同组合的标签，并且标签可按与图6中所示不同的顺序布置。

开始标签610可指示播放列表文件的开始。在一个实施例中，开始标签610是#EXTM3U标签。持续时间标签620可指示回放列表的持续时间。也就是说，回放列表600指示媒体文件的回放的持续时间。在一个实施例中，持续时间标签620是EXT-X-TARGETDURATION标签；然而，也可使用其他标签。

日期/时间标签625可提供与回放列表600所指示的媒体文件所提供的内容的日期和时间有关的信息。在一个实施例中，日期/时间标签625是EXT-X-PROGRAM-DATE-TIME标签；然而，也可使用其他标签。序列标签630可指示播放列表文件600在播放列表的序列中的顺序。在一个实施例中，序列标签630是EXT-X-MEDIA-SEQUENCE标签；然而，也可使用其他标签。

安保标签640可提供与向播放列表文件600所指示的媒体文件应用的安保和/或加密有关的信息。例如，安保标签640可指定用来对媒体文件指示符所指定的文件进行解密的解密密钥。在一个实施例中，安保标签640是EXT-X-KEY标签；然而，也可使用其他标签。变体列表标签645可指示播放列表600是否提供变体流以及与变体流有关的信息（例如，有多少个、比特率）。在一个实施例中，变体列表标签645是EXT-X-STREAM-INF标签。

媒体文件指示符650可提供与要播放的媒体文件有关的信息。在一个实施例中，媒体文件指示符650包括去到要播放的多个媒体文件的URI。在一个实施例中，播放列表600中的URI的顺序对应于应当访问和/或播放媒体文件的顺序。后续播放列表指示符660可提供与在播放列表文件600之后要使用的一个或多个播放列表文件有关的信息。在一个实施例中，后续播放列表指示符660可包括去到在已经播放了播放列表600的媒体文件之后要使用的一个或多个播放列表文件的URI。

存储器标签670可指示在媒体文件内容的回放之后客户端设备是否可存储媒体文件和/或可存储多久。在一个实施例中，存储器标签670是EXT-X-ALLOW-CACHE标签。结束标签680指示播放列表文件600是否是用于呈现的最后一个播放列表文件。在一个实施例中，结束标签680是EXT-X-ENDLIST标签。

以下部分包含根据一个实施例的若干个示例播放列表文件。

简单的播放列表文件

#EXTM3U

#EXT-X-TARGETDURATION:10

#EXTINF:5220,

http://media.example.com/entire.ts

#EXT-X-ENDLIST

----------------------------------------------------

滑动窗口播放列表，使用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

-------------------------------------------------------具有加密的媒体文件的播放列表文件

#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/fileSequence7794.ts

#EXTINF:15,

http://media.example.com/fileSequence7795.ts

#EXTINF:15,

http://media.example.com/fileSequence7796.ts

#EXT-X-KEY:METHOD=AES-128,URI=″

https://priv.example.com/key.php?r=53″

#EXTINF:15,

http://media.example.com/fileSequence7797.ts

-------------------------------------------------------

变体播放列表文件

#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

----------------------------------------------------------------

图7是用于如这里所述的组装流的回放技术的一个实施例的流程图。在一个实施例中，用户可控制接收到的媒体文件的回放开始、停止、倒回等等。在操作700中客户端设备接收播放列表文件。在操作710中取回播放列表文件所指示的媒体文件。在操作720中基于接收到的媒体文件生成输出。接收和基于媒体文件生成输出可如以上所述那样完成。

如果在操作730中检测到控制输入，则客户端设备在操作740中可确定该输入是否指示停止。如果该输入是停止，则该过程结束并且回放停止。如果在操作750中该输入指示倒回或前进请求，则客户端设备在操作760中可基于仍存储在存储器中的先前播放的媒体文件来生成输出。如果这些文件不再在缓存中，则处理回到操作710以取回媒体文件并重复该过程。在替换实施例中，回放可支持暂停特征，暂停特征使回放暂停，但不像停止输入那样结束回放。

参考图9A-9D来进一步描述用于从一个流转变到另一个流的方法。一个客户端设备可执行这些方法中的每一个，或者这些方法中的每一个的操作可如这里所述分布在多个客户端设备上；例如，在分布情况中，一个客户端设备可取回变体播放列表和两个媒体播放列表，并将这些提供给另一客户端设备，该另一客户端设备取回两个媒体播放列表所指定的媒体文件并且在取回的媒体文件所提供的两个流之间切换。还将会理解，在替换实施例中，可以修改所示出的操作的顺序，或者可以有比这些图中所示的更多或更少的操作。这些方法可使用变体播放列表来选择不同的流。在操作901中可取回并处理变体播放列表以确定可用的节目（例如体育事件）流。操作901可由客户端设备完成。在操作903中可从变体播放列表中选择第一流，并且客户端设备随后可取回关于第一流的媒体播放列表。客户端设备可在操作905中处理关于第一流的媒体播放列表并且还在操作907中测量或以其他方式确定用于第一流的网络连接的比特率。将理解，操作的序列可按与图9A中所示不同的顺序执行；例如，操作907可在操作903期间执行，等等。在操作911中，客户端设备基于来自操作907的测量到的比特率从变体播放列表中选择替换媒体播放列表；此替换媒体播放列表可处于比第一流的现有比特率更高的第二比特率。这通常意味着替换流将具有比第一流更高的分辨率。如果基于当前条件（例如在操作907中测量的比特率）替换媒体播放列表与关于第一流的当前播放列表相比是更好的匹配，则可选择替换媒体播放列表。在操作913中，取回并处理关于替换流的替换媒体播放列表。这通常意味着客户端设备可能在接收和处理第一流和替换流两者，因此两者都可用于呈现；一个被呈现，同时另一个准备好被呈现。客户端设备随后在操作915中选择在流的版本之间切换的转变点并且停止呈现第一流并开始呈现替换流。结合图9B-9D来提供如何实现此切换的示例。在一些实施例中，客户端设备可在作出切换之前停止接收第一流。

图9B示出了客户端设备在操作921和923中取回、存储和呈现由第一媒体播放列表指定的内容（例如第一流），并且在第一播放列表指定的内容正被呈现的同时，客户端设备在操作925中还取回并存储由第二媒体播放列表指定的内容（例如第二流）。在呈现从第一媒体播放列表获得的内容的同时对第二媒体播放列表所指定的内容的取回和存储（例如存储在临时缓冲器中）产生了节目内容在时间上的重叠955（在图9D中示出），该重叠允许客户端设备在节目的版本之间切换，而不会有节目的实质性中断。这样，在许多情况下可实现节目版本之间的切换，而用户不会注意到发生了切换（虽然在一些情况下在切换之后用户可注意到更高分辨率的图像）或者节目的呈现不会有实质性的中断。在操作927中，客户端设备确定从第一媒体播放列表指定的内容切换到第二媒体播放列表指定的内容的转变点；转变点的示例（转变点959）在图9D中示出。随后在切换之后在操作931中呈现第二媒体播放列表指定的内容。

图9C和9D中所示的方法表示确定转变点的一个实施例；此实施例依赖于来自两个流951和953的音频样本的模式匹配来确定转变点。将理解，替换实施例可使用视频样本的模式匹配或者可使用两个流中的时间戳等等来确定转变点。该方法可包括在操作941中将第一媒体播放列表所指定的内容（例如流951）存储在缓冲器中；该缓冲器可用于内容的呈现，并且还可用于模式匹配操作。流951包括音频样本951A和视频样本951B两者。视频样本可使用依赖于i帧或关键帧的压缩技术，i帧或关键帧具有显示单个视频帧所需的所有必要内容。流951中的内容可包括指定时间（例如从节目开始起经过的时间）的时间戳，并且这些时间戳可标记每个样本的开始（例如，每个音频样本951A的开始和每个视频样本951B的开始）。在一些情况下，两个流之间的时间戳的比较可能对于确定转变点是没有用的，因为它们可能不足够精确或者因为两个流中的样本的边界上的差异；然而，对时间戳范围的比较可用于验证在两个流之间存在时间上的重叠955。在操作943中，客户端设备在缓冲器中存储由第二媒体播放列表指定的内容；此内容与从第一媒体播放列表获得的内容是关于同一节目的并且其也可包括时间戳。在一个实施例中，时间戳如果在流中不存在则可被添加到关于流的播放列表；例如，在一个实施例中，包括一个或多个时间戳的ID3标签可被添加到诸如变体播放列表或媒体播放列表之类的播放列表中的条目。该条目例如可以在关于音频流的第一样本的URI中。图9D示出了从第二媒体播放列表获得的内容953的示例，并且其包括音频样本953A和视频样本953B。在操作945中，客户端设备可对两个流951和953中的音频样本执行模式匹配以从重叠955中选择转变点959，转变点959在一个实施例中可以是匹配的音频片段（例如片段957）之后的下一个独立视频帧（例如i帧961）。从i帧961（及其关联的音频样本）开始，节目的呈现使用从第二媒体播放列表获得的第二流。前述方法在一个实施例中既可用于从较慢到较快比特率的改变，也可用于从较快到较慢比特率的改变，但在另一实施例中，该方法可仅用于从较慢到较快比特率的改变，而另一方法（例如，不尝试定位转变点，而是尝试尽可能快地存储和呈现来自较慢比特率流的内容）可用于从较快到较慢比特率的改变。

本说明书的以下部分涉及在这里描述的播放列表中使用字节范围请求。另外，本说明书的这个部分描述了提供流传输媒体中从I帧起的快进或倒回（倒退）回放的方法，以及对具有定时信息的播放列表的使用，定时信息允许在提供流传输媒体的快进或倒回回放时选择I帧的节奏。可利用字节范围请求从服务器取回I帧。

在用于1X回放的播放列表中或者在指定用于快进或倒回的I帧的播放列表中，使用字节范围请求允许了提供者在单个大传输流或基本音频流文件内定义多个逻辑片段。这可减少在服务器或其他内容分发网络处必须管理的文件的总数，并且向缓存服务器提供关于片段集合的更多关联性信息。具有多个片段并且具有利用字节范围请求从文件取回数据的能力的媒体文件（例如电影）的示例在图13A中示出。在一个实施例中，密码块链接（cipher block chaining，CBC）和密码填充可以每片段地保持，使得CBC将在片段边界（例如图13A中所示的seg1.ts和seg2.ts之间的片段边界）重新开始。在一个实施例中，图13A中所示的大文件实质上是所有单独片段文件的串接。

一个实施例中使用字节范围请求的播放列表语法示例为如下所示。字节范围标签被添加到每个片段指定符并且具有如下形式：#EXT-X-BYTERANGE:<length>[<offset>]，其中<length>是片段中的字节数目，可选的参数<offset>是从文件开头起的偏移量。如果省略<offset>，则文件偏移量等于先前条目的偏移量加上其长度。对于第一标签，假定<offset>为0。在一个实施例中，指定字节范围片段的播放列表的示例为：

#EXTINF:10,

#EXT-X-BYTERANGE:23902400

entire_movie.ts

#EXTINF:10,

#EXT-X-BYTERANGE:670416

entire_movie.ts

#EXTINF:10,

#EXT-X-BYTERANGE:465120

entire_movie.ts

能够以正常（1X）速率提供回放的传统播放列表可使用字节范围请求来从单个大传输流或基本音频流文件取回内容。另外，可用于提供特技播放模式回放（例如快进或倒回回放（例如8X或16X或32X或者-8X或-16X或-32X））的仅含I帧的播放列表也可使用字节范围请求来从单个大传输流或基本流文件取回内容。

在一个实施例中，变体播放列表可包括关于至少一个1X回放播放列表的URL和关于至少一个I帧播放列表的URL；在典型的实现方式中，变体播放列表可具有多个关于1X播放列表的URL，每个具有不同的带宽或其他变化，例如不同的编解码器等等，并且变体播放列表还可包含多个关于具有不同的带宽或其他变化（例如不同的编解码器等等）的I帧播放列表的URL。图10示出了变体播放列表1001的示例，变体播放列表1001既包含关于传统1X回放播放列表的URL，也包含多个关于I帧播放列表的URL，这些I帧播放列表在此情况下是仅含I帧的播放列表。具体地，URL1003是关于带宽X下的1X回放播放列表的URL，URL1005是关于带宽Y下的1X回放播放列表的URL。URL1007是关于带宽X下的仅含I帧的播放列表的URL，URL1009是关于带宽Y下的仅含I帧的播放列表的URL。这整个播放列表文件1001是响应于来自客户端的观看特定电影或视频点播或其他内容的请求而提供的，并且响应于该请求，服务器提供包含不同的两组URL的播放列表文件1001，从而允许1X回放或者快进或倒退回放。这允许了客户端设备接收变体播放列表并存储该变体播放列表，然后能够通过选择性地选择变体播放列表中的适当播放列表文件来在1X回放或者快进或倒退回放之间切换。通常，I帧播放列表将利用这里论述的字节范围特征。字节范围特征提供关于片段内的I帧位置的信息，这允许客户端设备仅通过取得并显示I帧来在视频点播和实况呈现中迅速地向后或向前扫描，并且其不要求专用的媒体文件来用于不同的回放速度。在一个实施例中，客户端设备在显示I帧时可在I帧播放列表的变体之间适应性地切换以基于当前网络速度提供最佳用户体验；换言之，可以在执行快进或倒退回放的同时动态地确定网络速度，并且客户端系统可响应于动态确定的网络速度在变体播放列表内包含的I帧播放列表的变体之间适应性地切换。包含I帧播放列表的变体播放列表的示例为：

#EXTM3U

#EXT-X-VERSION:4

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=326448

BTBW0.2Mb/prog_index.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1255635

BTBW0.8Mb/prog_index.m3u8

#EXT-X-I-FRAME-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=75915

BTBW0.2Mb/iframes.m3u8

#EXT-X-I-FRAME-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=380752

BTBW0.8Mb/iframes.m3u8

#EXT-X-I-FRAME-STREAM-INF标签具有与#EXT-X-STREAM-INF相同的一组属性（PROGRAM-ID、BANDWIDTH、CODECS）。从这个变体播放列表可以看出，变体播放列表提供用于不同带宽下的1X回放的两个版本，以及也在两个不同带宽下的I帧播放列表的两个版本。在一个实施例中，I帧播放列表包含仅用于媒体文件内的I帧的字节范围请求，因此B帧和P帧不包括在仅含I帧的播放列表中指定的这些字节范围请求内。

仅含I帧的播放列表的示例为（注意EXT-X-I-FRAMES-ONLY标签）：

#EXTM3U

#EXT-X-TARGETDURATION:10

#EXT-X-VERSION:4

#EXT-X-MEDIA-SEQUENCE:0

#EXT-X-I-FRAMES-ONLY

#EXTINF:1.2489,

#EXT-X-BYTERANGE:1505376

segment0.ts

#EXTINF:4.9633,

#EXT-X-BYTERANGE:1505125584

segment0.ts

#EXTINF:5.005,

#EXT-X-BYTERANGE:37413539184

segment0.ts

#EXTINF:5.005,

#EXT-X-BYTERANGE:30645152844

segment1.ts

注意，字节范围只包括I帧；为了读取PAT/PMT，客户端将从第一URL的开头起在非连续域中读到第一I帧的偏移量。在此实施例中，字节范围请求是在与其相应的URL相邻的标签中指定的，但不是该URL的一部分，然而在另一实施例中，字节范围请求可以是该URL的一部分。从这个I帧播放列表可以看出，新的标签已被添加到常规播放列表，指出片段指定符涉及I帧，并且EXTINF持续时间涉及该I帧与下一I帧之间的时间跨度。将联系图14和15中所示的方法来描述对这个时间信息的使用。

图11是示出在一个实施例中用于创建图10中所示的变体播放列表或者包含对I帧播放列表的引用的其他变体播放列表的方法的流程图。在操作1101中，数据处理系统确定视频内容中的I帧。可以采用公知的技术来确定文件或传输流中的I帧。在操作1103中，数据处理系统可创建I帧播放列表，例如仅含I帧的播放列表，此外，随后创建包含用于I帧播放列表以及可选地用于1X播放列表的URL的变体播放列表。除了变体播放列表和I帧播放列表以外，数据处理系统还可创建1X播放列表。I帧播放列表可包括关于多个1X播放列表的多个URL，并且还可包括关于相应的多个I帧播放列表的多个URL。这种变体播放列表的示例在图10中示出。响应于来自客户端设备的对观看节目的请求，该数据处理系统或另外的数据处理系统可发送包含关于一个或多个1X播放列表和关于一个或多个I帧播放列表的URL的变体播放列表。变体播放列表的发送在图11中被示为操作1105。然后，同一服务器系统或另一服务器系统等待对I帧播放列表或1X播放列表的客户端请求。在操作1107中和在操作1109中，发送服务器基于从客户端接收的请求确定客户端是请求了I帧播放列表还是1X播放列表，并且作为响应，发送服务器在操作1113中发送I帧播放列表或者在操作1111中发送1X播放列表。

图12示出了可实现图14和15中所示的任一种方法的客户端设备的体系结构的示例。客户端设备1201中所示的组件可以是软件组件（在数据处理系统（例如图8所示的系统）上运行）或者硬件组件或者软件和硬件组件的组合。在一个实施例中，用户应用1207是被用户运行来显示电影或棒球比赛或听电台节目等等的软件应用。例如，在一个实施例中，用户应用可以是由美国职棒大联盟提供来观看棒球比赛的应用。应用1207可与播放器模块1209交互，播放器模块1209也可以是在数据处理系统（例如图8中所示的系统）上操作的软件程序。用户应用1207在一个实施例中通过这里进一步描述的API来与播放器模块1209交互。类似地，播放器模块1209可通过API与下载和数据速率测量模块1211交互。播放器模块1209在一个实施例中可处理播放列表以便指令下载模块从提供给下载模块的URL下载内容。下载模块1211可通过一个或多个网络接口1213执行下载操作，这些网络接口1213耦合到一个或多个网络，例如网络1203，而网络1203又耦合到一个或多个服务器1205，例如内容服务器或提供播放列表和内容的服务器等等。下载和数据速率测量模块1211还在取回播放列表中指定的内容时执行数据速率测量。数据速率测量可在结合图14和15描述的方法中用于确定要下载的I帧的适当节奏以便提供快进或倒回（倒退）回放，或者也称为特技播放回放模式。

现在将参考图13A和13B描述媒体文件与其关联的I帧播放列表之间的关系。将看出，I帧播放列表包括关于媒体文件的元数据，其允许执行图14和15中所示的方法以便选择I帧的子集或节奏来提供快进或倒回回放（例如8X或16X或32X回放或者-8X或-16X或-32X的倒回回放）。媒体文件1301可以是电影或者视频点播或者实况广播或者根据本领域中已知的HTTP实况流传输协议创建的其他文件。如本领域中已知的，媒体文件1301包括多个I帧。I帧1305包括I帧I₀、I₁、I₂、I₃、I₄、I₅和I₆。如本领域中已知的，每个I帧后面跟随着B帧和P帧，B帧和P帧需要I帧来对B帧和P帧中的内容进行解码。从图13A可以看出，由于视频内的运动本质，I帧在整个文件中在时间上不是均匀分布的，如本领域中已知的那样。媒体文件1301内的元数据可包括片段信息1303，其指定时间上的不同片段，这些片段用于密码块链接和密码填充，如本领域中已知的那样。在一个实施例中，密码块链接将在片段边界上重新开始。媒体文件1301实质上是所有个体片段文件的串接。媒体文件1301可包括时间元数据1307，时间元数据1307表示每个接连的I帧的开头之间的时间跨度。例如，I帧I₁的开头处的时间7.3秒的意思是I帧I₀及其关联的B和P帧在时间上占据7.3秒的持续时间。图13A中的I帧下面示出的时间元数据1307是时间的值；例如，I帧6在电影的正常1X回放时间的第26秒显示。类似地，当以1X回放速率播放电影时，I帧4在电影时间的第16.2秒呈现。在一个实施例中，图13A中的I帧下面示出的时间元数据可被包括在媒体文件1301中，而在其他实施例中其可从媒体文件得出，而不与媒体文件一起存储，但时间元数据如下文说明的那样将被用在I帧播放列表中，例如图13B中所示的I帧播放列表中，并且此时间元数据可用在图14或15的方法中。

图13B中所示的I帧播放列表表示关于图13A中所示的媒体文件1301的I帧播放列表的一部分。此播放列表包括仅含I帧指定符1315，其指示该播放列表是只关于I帧的。标签#EXTINF:7.3是I帧I₀的跨度期间；换言之，跨度期间1317表示I帧I₀的时间上的跨度并且匹配在I帧I₁的开头处示出的7.3。字节范围请求1319包括指定图13A中示出的字节范围A的字节范围参数；换言之，字节范围请求1319中的字节范围参数指定数据的范围来从媒体文件1301仅取回I帧I₀。片段指定符1321和1327指定字节所位于的特定片段。字节范围请求1323也包括跨度期间，其在此情况下是2.5，这与图13A中所示的9.8秒与7.3秒之间的差异匹配。具体地，2.5秒指定I帧I₁的开头与I帧I₂的开头之间的持续时间。字节范围请求1325包括字节范围参数，其指定图13A中所示的字节范围B以便取回I帧I₁的视频内容。将会明白，在一些实施例中，音频数据在相同字节范围内可与视频数据复用，但该音频数据通常不用于快进或倒退回放。跨度期间1317和1323在一个实施例中可以用来确定可用于下载不同节奏的I帧的时间量，这在下文中将结合图14或图15进一步描述。

图14示出了用于从在显示期限之前可用的所有可用I帧中确定I帧集合的方法。图14中所示的方法是在客户端设备（例如客户端设备1201）上执行的，该客户端设备已接收到I帧播放列表，例如I帧播放列表13B，并且正处于处理该I帧播放列表以便通过使用I帧播放列表来提供快进或倒退回放的过程中。在显示期限之前可从所有可用的I帧中以使得I帧在时间上至少一定程度上均匀分布的方式选择集合。在操作1401中，客户端设备确定I帧播放列表中的可用I帧的多个集合；这些集合是基于当前电影时间，所选回放模式（例如8X或16X或者-8X等等）以及显示期限的。在一个实施例中，显示期限可基于当前时间的实时时钟加上固定的时间值，例如从当前实时时钟时间起半秒或一秒或两秒。播放器时间或电影时间可基于回放速率从这个显示期限得出；例如，如果回放速率是16X，则可将当前I帧的时间跨度期间加上16秒以给出该显示期限下的播放器时间。例如，如果回放速率是8X并且当前显示的I帧是图13A中所示的I₀，则可将7.3秒加上8秒（与8X回放速率相对应）以得出该显示期限下的播放器时间（或电影时间）。显示期限下的播放器时间效果上设定了在显示期限前可取回的I帧的最大数目；I帧的该最大数目是当前显示的I帧与显示期限前的最后完整I帧之间的I帧的数目。不同的回放速率将会产生不同的显示期限，如图16中所示。图16示出了具有至少17个I帧的媒体文件的示例，这17个I帧在时间上开始于I帧I₀，并且结束于I帧I₁₇，如图16中所示。当前显示的I帧是I帧I₀并且时间从左向右推进。如果回放速率被设定为16X，则显示期限在I帧I₁₀或者在I帧I₁₀之前，而如果回放速率被设定为32X，则显示期限被设定在I帧I₁₇或者在I帧I₁₇之前。因此，在图16的情况中，如果回放速率为16X，则在显示期限前可取回的I帧的最大数目是9个I帧（I帧I₁–I₉），而当回放速率被设定为32X时可用于下载的帧的最大数目是16个I帧（I帧I₁–I₁₆）。因此，操作14中的操作1401确定在给定显示期限和当前所选回放速率以及当前电影时间的情况下可下载的I帧的最大数目，然后进而确定这些可用I帧的子集。在一个实施例中，这些子集可以是时间上的每隔一个I帧或者时间上的每隔两个I帧等等。

然后，在操作1403中，客户端设备为可用I帧的每个集合确定下载时间。通常，可用I帧的每个集合将具有不同数目的I帧，因此其下载时间将有所不同。例如，客户端设备可确定下载可用的最大数目的I帧中的每隔一个I帧的下载时间，并且确定在显示期限之前可用于下载的最大数目的I帧中的每隔两个I帧的下载时间，等等。然后，在操作1405中，客户端设备选择在显示期限之前可下载的可用I帧的集合之一，然后在操作1407中，客户端设备下载所选的可用I帧集合并显示它们。在一个实施例中，客户端设备将每次一个地下载每个I帧并且基于最后I帧的实际下载时间重复1401、1403和1405的处理操作。将理解，在快进或倒回回放期间，用户可能想要停止回放或者可改变回放的速度，这被表示为操作1409，在该操作中系统确定内容是否结束或者是否被停止或者用户是否改变了回放速度，等等。客户端设备将基于用户输入来作出响应。

在一个实施例中，本发明的方法可以在以快进或倒退模式呈现I帧的同时不断评估下载时间，并且客户端设备可以在没有用户干预的情况下自动确定是否改变分辨率或质量。例如，如果用户选择了8X并且网络速度较快，则I帧被足够快速地下载，使得有空余时间可用于下载更高分辨率的I帧，则系统在操作1411中确定改变分辨率或质量之后可自动切换到不同的I帧播放列表，然后在操作1413中进行切换，在该操作中客户端设备改变到不同的I帧播放列表，该I帧播放列表在此情况下具有更高的分辨率或更好的图像质量。图18示出了包括在I帧播放列表之间进行切换的操作1801、1803和1805的方法的示例。在一个实施例中，客户端设备可向用户呈现用户界面，在进行改变之前要求用户确认分辨率或质量的改变。分辨率或质量的改变在网络带宽较高时可以是分辨率或质量的提高，或者在网络带宽较差或较低时可以是到更低分辨率或质量的改变。图14中所示的方法继续进行操作1415，在该操作中确定下一个当前电影时间，并且确定下一个显示期限，然后该过程通过回到操作1401而重复。

图15示出了与处理I帧播放列表以便提供快进或倒退回放的方法有关的更多细节。将理解，图15的方法可包括用户停止回放或决定改变回放速率或者系统改变分辨率或质量的操作；例如，操作1409和1411也可在图15中所示的方法内的任何时间执行。另外，将理解，操作的顺序在替换实施例中可与图15所示的顺序不同。图15的方法假定客户端设备已下载了I帧播放列表，例如在变体回放（例如，图10中所示的播放列表）中指定的I帧播放列表。还将会明白，图15的方法可利用图12所示的客户端设备实现，该客户端设备包括下载测量模块，该模块测量数据的下载速率，例如与特定I帧（例如所下载的最后I帧）相对应的字节范围的数据。在操作1501中，客户端设备确定当前显示的I帧的开头的当前电影时间，该当前电影时间可被记为T_C。在图10所示的示例中，I帧I₀是正在显示的当前I帧，客户端设备将确定I帧I₀的开头的当前电影时间。然后在操作1503中，客户端设备确定当前回放模式，其可以是多种不同的快进或倒退速度（例如8X或16X或-8X等等）中的任何一种。然后在操作1505中，客户端设备确定当前显示期限。在一个实施例中，这可通过将当前回放速率的倍数（例如1倍或2倍）与当前电影时间相加来执行。例如，如果该倍数是一秒并且当前回放速率是8X，则一秒乘以8秒的乘积产生8秒并且该乘积被与当前电影时间T₀相加以产生当前显示期限。此当前显示期限可以在电影时间中并且可设定边界，该边界确定在当前显示期限之前可用的I帧的最大数目。此操作在图15中示为操作1507。在图16所示的示例中，如果回放速率是16X，则客户端设备将确定在操作1507中的当前显示期限之前可用的所有I帧对应于图16中所示的I帧I₁至I₉。然后在操作1509中，客户端设备确定在操作1507中确定的所有这些I帧的子集。换言之，客户端设备将确定在当前显示期限之前可用的那些I帧的各种子集。在一个实施例中，这些子集中的每个子集可具有不同的节奏，并且每个节奏可具有不同的I帧数目。在一个实施例中，节奏可被设计成使得I帧在时间上均匀分布，或者至少在可用I帧的序列上均匀分布（而不一定在时间上完全均匀地分布）。

图17A、17B、17C和17D示出了四个不同节奏的示例。图17A表示如下节奏：在操作1507中确定的所有I帧的集合中的I帧中的每一个都被考虑用于下载。图17B中所示的节奏表示如下节奏（在此情况下是I帧的子集）：在操作1507中确定可用于下载的I帧中的每隔一个被考虑用于下载。类似地，图17C中所示的节奏是每隔两个I帧，而图17D中所示的节奏是在操作1507中确定的可用的I帧的群组中的每隔三个I帧。在一个实施例中，如操作1511中所示，客户端设备可以可选地将每个子集内的I帧的数目限制到固定的或预定的数目或者限制到可由用户或系统改变的数目。以这种方式对I帧数目的限制在一些实施例中可改善用户体验。然后在操作1513中，客户端设备为I帧的每个子集确定下载时间，在一实施例中每个子集具有不同的节奏，例如图17A至17D所示的不同节奏。节奏集合中的每个节奏的下载时间可从当前正在显示的最后一个I帧的下载时间或者已下载的最后两个或三个或四个或更多个I帧的随时间以指数方式衰减的移动平均或者已下载的最后两个或三个或更多个I帧的平滑平均来得出。对下载时间的测量可由图12中所示的模块1211执行，并且这些下载时间可被提供给播放器模块1209，播放器模块1209在操作1515中可执行对I帧的子集之一的选择。客户端设备在操作1515中将确定每个节奏是否能够在显示期限之前被下载，并且对于那些不能的，作为可能的解决方案，其将丢弃这些节奏，并且将选择具有最高的I帧数目并且能够在当前显示期限之前的时间段内下载的节奏。同样，在一个实施例中，所选节奏在操作1511中可被限制到一段时间中I帧的最大数目，例如每秒不多于10个I帧，这可改善特技播放的视觉体验。在操作1515中选择了特定节奏后，客户端设备可开始下载所选子集中的第一I帧。在一个实施例中，客户端设备可以可选地首先检查是否已太迟以至于不能下载该I帧，如果是，则跳到操作1515中选择的节奏中的下一I帧。在一个实施例中，播放器模块1209执行操作1515中的选择，然后请求下载模块1211在操作1517中下载第一I帧。下载模块随后可测量该I帧的下载速率或下载时间，并且该信息随后可用在图15的方法的下一次重复中，该下一次重复发生在操作1517之后跟随着操作1501时。如果网络条件发生变化（例如，网络带宽下降，使得下载时间变得更长），则在下载所选节奏中的所有I帧之前可再次执行图15的方法，因此在客户端设备完成最后选择的节奏中的I帧的下载之前节奏可变化。如果这继续发生，则客户端设备如图18所示可决定改变I帧的分辨率或质量以便适应于减慢的网络。或者，如果网络速度提高，则图18的方法也可用于改变I帧的分辨率或质量。如上所述，图18的方法可由系统在任何时间自动执行或者在某些情况下响应于用户请求而执行。

图8是电子系统的一个实施例的框图。图8所示的电子系统旨在表示某一范围的电子系统（有线的或无线的），例如包括桌面型计算机系统、膝上型计算机系统、蜂窝电话、个人数字助理（PDA）（包括具备蜂窝能力的PDA）、机顶盒、娱乐系统或其他消费电子设备。替选的电子系统可包括更多的、更少的和/或不同的组件。图8的电子系统可用于提供客户端设备和/或服务器设备。

电子系统800包括总线805或其他通信设备来传输信息，并且包括耦合到总线805的可处理信息的处理器810。虽然电子系统800被示为具有单个处理器，但电子系统800也可包括多个处理器和/或协处理器。电子系统800还可包括随机存取存储器（RAM）或其他动态储存设备820（称为主存储器），其耦合到总线805，并且可存储可被处理器810执行的指令和信息。主存储器820还可用于在处理器810执行指令期间存储临时变量或其他中间信息。

电子系统800还可包括耦合到总线805的只读存储器（ROM）和/或其他静态储存设备830，其可为处理器810存储静态信息和指令。数据储存设备840可耦合到总线805以存储信息和指令。诸如闪存或磁盘或光盘和相应的驱动器之类的数据储存设备840可耦合到电子系统800。

电子系统800还可经由总线805耦合到显示设备850，例如阴极射线管（CRT）或液晶显示器（LCD），以向用户显示信息。电子系统800还可包括字符输入设备860，其包括字母数字键和其他键，可耦合到总线805以向处理器810传输信息和命令选择。另一类用户输入设备是光标控制装置870，例如触摸板、鼠标、轨迹球或者光标方向键，以向处理器810传输方向信息和命令选择并且控制显示器850上的光标移动。

电子系统800还可包括一个或多个网络接口880来提供对网络（例如局域网）的接入。网络接口880例如可包括具有天线885的无线网络接口，天线885可表示一个或多个天线。电子系统800可包括多个无线网络接口，例如WiFi、蓝牙和蜂窝电话接口的组合。网络接口880还可包括例如有线网络接口，以经由网络线缆887与远程设备通信，网络线缆887例如可以是以太网线缆、同轴线缆、光缆、串行线缆或并行线缆。

在一个实施例中，网络接口880可例如通过符合IEEE802.11b和/或IEEE 802.11g标准来提供对局域网的接入，并且/或者无线网络接口可例如通过符合蓝牙标准来提供对个人区域网络的接入。也可支持其他无线网络接口和/或协议。

除了经由无线LAN标准的通信以外，或者作为对其的取代，网络接口880可例如利用时分多址（TDMA）协议、全球移动通信系统（GSM）协议、码分多址（CDMA）协议和/或任何其他类型的无线通信协议来提供无线通信。

在一些实施例中可使用一个或多个应用编程接口（API）。API是由程序代码组件或硬件组件（以下称为“API实现组件”）实现的接口，其允许另一不同的程序代码组件或硬件组件（以下称为“API调用组件”）访问和使用由API实施组件提供的一个或多个功能、方法、过程、数据结构、类和/或其他服务。API可定义在API调用组件和API实施组件之间传递的一个或多个参数。

API允许API调用组件的开发者（其可以是第三方开发者）利用由API实施组件提供的指定特征。可以有一个API调用组件，或者可以有多于一个这样的组件。API可以是源代码接口，计算机系统或程序库提供该源代码接口以便支持来自应用的对服务的请求。操作系统（OS）可具有多个API以允许在OS上运行的应用调用这些API中的一个或多个，并且服务（例如程序库）可具有多个API以允许使用该服务的应用调用这些API中的一个或多个。API可根据在构建应用时可解释或编译的编程语言来指定。

在一些实施例中，API实施组件可提供多于一个API，其中每个API提供由API实施组件实现的功能的不同视图，或者具有访问由API实施组件实现的功能的不同方面的不同方面。例如，API实施组件的一个API可提供第一组功能并且可被暴露给第三方开发者，并且API实施组件的另一API可被隐藏（不被暴露）并且提供第一组功能的子集，并且还提供另一组功能，例如不在第一组功能中的测试或调试功能。在其他实施例中，API实施组件自身可经由下层API调用一个或多个其他组件，从而既是API调用组件也是API实施组件。

API定义API调用组件在访问和使用API实施组件的指定特征时使用的语言和参数。例如，API调用组件通过由API暴露的一个或多个API调用或调取（例如由函数或方法调用实现）来访问API实施组件的指定特征，并且经由这些API调用或调取利用参数来传递数据和控制信息。响应于来自API调用组件的API调用，API实施组件可通过API来返回值。虽然API定义API调用的语法和结果（例如，如何调取API调用以及API调用做什么），但API可不揭露API调用如何完成API调用所指定的功能。经由一个或多个应用编程接口在调用方（API调用组件）和API实施组件之间传送各种API调用。传送API调用可包括发布、发起、调取、调用、接收、返回或响应函数调用或消息；换言之，传送可描述API调用组件或API实施组件进行的动作。函数调用或对API的其他调取可通过参数列表或其他结构来发送或接收一个或多个参数。参数可以是常数、密钥、数据结构、对象、对象类、变量、数据类型、指针、阵列、列表或者指向函数或方法的指针或者引用要经由API传递的数据或其他项目的另一种方式。

另外，数据类型或类可由API提供并且由API实施组件实现。从而，API调用组件可通过使用API中提供的定义来声明这种类型或类的变量，使用指向这种类型或类的指针，使用或实例化这种类型或类的常数值。

一般地，API可用于访问由API实施组件提供的服务或数据或者发起由API实施组件提供的操作或计算的执行。作为示例，API实施组件和API调用组件可各自是操作系统、库、设备驱动器、API、应用程序或其他模块中的任何一个（应理解，API实施组件和API调用组件可以是彼此相同或不同类型的模块）。API实施组件在一些情况下可至少部分以固件、微码或其他硬件逻辑器实现。在一些实施例中，API可允许客户端程序使用由软件开发套件（Software DevelopmentKit，SDK）库提供的服务。在其他实施例中，应用或其他客户端程序可使用由应用框架（Application Framework）提供的API。在这些实施例中，应用或客户端程序可合并对由SDK提供的和由API提供的函数或方法的调用或者使用在SDK中定义并由API提供的数据类型或对象。应用框架在这些实施例中可为程序提供主事件循环，该循环响应于该框架所定义的各种事件。API允许应用利用应用框架来指定事件和对事件的响应。在一些实现方式中，API调用可向应用报告硬件设备的能力或状态，包括与诸如输入能力和状态、输出能力和状态、处理能力、电源状态、存储容量和状态、通信能力等等之类的方面有关的那些，并且API可部分由固件、微码或者一部分在硬件组件上执行的其他低级别逻辑器来实现。

API调用组件可以是本地组件（即，与API实施组件在同一数据处理系统上）或者经由网络通过API与API实施组件通信的远程组件（即，与API实施组件在不同的数据处理系统上）。应理解，API实施组件也可充当API调用组件（即，其可对由另一不同API实施组件暴露的API作出API调用），并且API调用组件也可通过实施被暴露给另一不同API调用组件的API来充当API实施组件。

API可允许以不同的编程语言编写的多个API调用组件与API实施组件进行通信（从而API可包括用于在API实施组件和API调用组件之间转化调用和返回的特征）；然而API可按照特定的编程语言实现。API调用组件在一个实施例中可调用来自不同提供者的API，例如来自OS提供者的一组API和来自插件提供者的另一组API以及来自另一组API的另一提供者（例如软件库的提供者）或创建者的另一组API。

图19是示出在本发明的一些实施例中可使用的示范性API体系结构的框图。如图19所示，API体系结构1800包括实施API1820的API实施组件1810（例如，操作系统、库、设备驱动器、API、应用程序、软件或其他模块）。API1820指定API实施组件的可被API调用组件1830使用的一个或多个功能、方法、类、对象、协议、数据结构、格式和/或其他特征。API1820可指定至少一个调用约定，该调用约定指定API实施组件中的函数如何从API调用组件接收参数并且该函数如何向API调用组件返回结果。API调用组件1830（例如，操作系统、库、设备驱动器、API、应用程序、软件或其他模块）通过API1820作出API调用以访问和使用API实施组件1810的由API1820指定的特征。API实施组件1810响应于API调用可通过API1820向API调用组件1830返回值。

将理解，API实施组件1810可包括未通过API1820指定并且对API调用组件1830不可用的额外函数、方法、类、数据结构和/或其他特征。应理解，API调用组件1830可与API实施组件1810在同一系统上，或者可位于远程并通过网络利用API1820访问API实施组件1810。虽然图19示出了单个API调用组件1830与API1820交互，但应理解，以与API调用组件1830不同的语言（或相同的语言）编写的其他API调用组件可使用API1820。

API实施组件1810、API1820和API调用组件1830可被存储在机器可读非暂态存储介质中，该介质包括用于以机器（例如，计算机或其他数据处理系统）可读的形式存储信息的任何机构。例如，机器可读介质包括磁盘、光盘、随机存取存储器；只读存储器、闪存设备等。

在图20（“软件栈”）中，在示范性实施例中，应用可利用若干个服务API对服务1或2作出调用，并且利用若干个OS API对操作系统（OS）作出调用。服务1和2可利用若干个OS API对OS作出调用。

注意，服务2具有两个API，其中一个（服务2API1）接收来自应用1的调用并向应用1返回值，另一个（服务2API2）接收来自应用2的调用并向应用2返回值。服务1（其例如可以是软件库）对OSAPI1作出调用并且从OS API1接收返回值，服务2（其例如可以是软件库）对OS API1和OS API2两者作出调用并且从OS API1和OS API2两者接收返回值。应用2对OS API2作出调用并且从OSAPI2接收返回值。

本说明书中提及“一个实施例”或“实施例”的意思是联系该实施例描述的特定特征、结构或特性被包括在本发明的至少一个实施例中。在本说明书中各种地方出现短语“在一个实施例中”不一定都指的是同一实施例。

在前述说明书中，已经参考本发明的具体实施例描述了本发明。然而，很明显，在不脱离本发明的更宽精神和范围的情况下，可对其进行各种修改和改变。说明书和附图因此应被认为是例示性的，而不是限制性的。

附录

以下附录是根据本发明的特定实施例的协议的草拟规范。将理解，在本附录中对某些关键字（例如，必须、不得、应、不应等）的使用适用于此特定实施例，而不应用于本公开中描述的其他实施例。

HTTP实况流传输

draft-pantos-http-live-streaming-06

摘要

本文档描述了用于传送无限的多媒体数据流的协议。其规定了文件的数据格式和流的服务器（发送者）和客户端（接收者）要采取的动作。其描述了此协议的第3版本。

目录

1.简介

2.概要

3.播放列表文件

3.1.简介

3.2.属性列表

3.3.新标签

3.3.1.EXT-X-TARGETDURATION

3.3.2.EXT-X-MEDIA-SEQUENCE

3.3.3.EXT-X-KEY

3.3.4.EXT-X-PROGRAM-DATE-TIME

3.3.5.EXT-X-ALLOW-CACHE

3.3.6.EXT-X-PLAYLIST-TYPE

3.3.7.EXT-X-ENDLIST

3.3.8.EXT-X-STREAM-INF

3.3.9.EXT-X-DISCONTINUITY

3.3.10.EXT-X-VERSION

4.媒体文件

5.密钥文件

5.1.简介

5.2.用于AES-128的IV

6.客户端/服务器动作

6.1.简介

6.2.服务器过程

6.2.1.简介

6.2.2.滑动窗口播放列表

6.2.3.加密媒体文件

6.2.4.提供变体流

6.3.客户端过程

6.3.1.简介

6.3.2.加载播放列表文件

6.3.3.播放播放列表文件

6.3.4.重加载播放列表文件

6.3.5.确定要加载的下一文件

6.3.6.对经加密的媒体文件进行解密

7.协议版本兼容性

8.示例

8.1.简介

8.2.简单播放列表文件

8.3.滑动窗口播放列表，使用HTTPS

8.4.具有经加密的媒体文件的播放列表文件

8.5.变体播放列表文件

9.安保考虑

10.参考文献

10.1.规范性参考文献

10.2.信息性参考文献

1.简介

本文档描述了用于传送无限的多媒体数据流的协议。该协议支持媒体数据的加密和流的替换版本（例如比特率）的提供。媒体数据可在其被创建之后很快被传送，从而使得它可以被近实时地播放。数据通常是通过HTTP[RFC2616]运送的。

描述诸如HTTP之类的相关标准的外部参考文献在第11节中列出。

2.概要

多媒体呈现由去到播放列表文件的URI[RFC3986]指定，播放列表文件是媒体URI和信息标签的有序列表。每个媒体URI引用作为单个连续流的片段的媒体文件。

为了播放流，客户端首先获得播放列表文件，然后获得并播放播放列表中的每个媒体文件。其如本文档中所述的那样重加载播放列表文件以发现额外片段。

本文档中的关键字“必须”、“不得”、“要求”、“应”、“不应”、“应当”、“不应当”、“推荐”、“可”和“可选”应如RFC2119[RFC 2119]中所述的那样解释。

3.播放列表文件

3.1.简介

播放列表必须是扩展M3U播放列表文件[M3U]。本文档通过定义额外的标签来扩展M3U文件格式。

M3U播放列表是由各个行组成的文本文件。行可终止于单个LF字符或者后面跟随有LF字符的CR字符。每一行是URI、空白或者以注释字符“#”开始。空白行被忽略。不得存在空格符，除了其中明确指定的元素以外。

URI行标识媒体文件或变体播放列表文件（参见第3.3.8节）。

URI可以是相对的。相对URI必须对照包含它的播放列表文件的URI来解析。

以注释字符“#”开始的行是注释或标签。标签开始于#EXT。所有其他以“#”开始的行都是注释并且应当被忽略。

播放列表文件的持续时间是其内的媒体文件的持续时间的总和。

名称以.m3u8结尾的和/或具有HTTP内容类型“application/vnd.apple.mpegurl”的M3U播放列表文件是以UTF-8[RFC3629]编码的。名称以.m3u结尾的和/或具有HTTP内容类型[RFC2616]“audio/mpegurl”的文件是以US-ASCII[US_ASCII]编码的。

播放列表文件必须具有以.m3u8结尾的名称和/或具有内容类型“application/vnd.apple.mpegurl”（如果通过HTTP传送），或者具有以.m3u结尾的名称和/或具有HTTP内容类型“audio/mpegurl”（为了兼容性）。

扩展M3U文件格式定义两个标签：EXTM3U和EXTINF。扩展M3U文件通过其第一行与基本M3U文件相区分，其第一行必须是#EXTM3U。

EXTINF是描述跟随其后的URI所标识的媒体文件的记录标记。每个媒体文件URI之前必须是EXTINF标签。其格式如下。

#EXTINF:<duration>,<title>

“duration”是以秒为单位指定媒体文件的持续时间的整数或浮点数。整数持续时间应当被舍入到最近的整数。如果播放列表文件的协议版本小于3，则持续时间必须是整数。逗号之后该行的剩余部分是媒体文件的标题，其是可选的媒体片段的人类可读信息性标题。

本文档定义以下新标签：EXT-X-TARGETDURATION、EXT-X-MEDIA-SEQUENCE、EXT-X-KEY、EXT-X-PROGRAM-DATE-TIME、EXT-X-ALLOW-CACHE、EXT-X-PLAYLIST-TYPE、EXT-X-STREAM-INF、EXT-X-ENDLIST、EXT-X-DISCONTINUITY和EXT-X-VERSION。3.2.属性列表

某些扩展M3U标签具有是属性列表的值。属性列表是没有空格符的属性/值对的逗号分隔列表。

属性/值对具有以下语法。

AttributeName=AttributeValue

AttributeName是包含来自集合[A-Z]的字符的不带引号的字符串。

AttributeValue是以下之一。

○十进制整数：来自集合[0-9]的字符的不带引号的字符串，在以10为基数的算术中表达整数。

○十六进制整数：来自集合[0-9]和[A-F]的字符的不带引号的字符串，其前缀为0x或0X并且其在以16为基数的算术中表达整数。

○十进制浮点：来自集合[0-9]和“.”的字符的不带引号的字符串，在以10为基数的算术中表达浮点数。

○带引号的字符串：一对双引号（″）内的字符串。字符串中允许的字符的集合和用于转义特殊字符的任何规则由属性定义来指定，但任何双引号(″)字符和任何回车或换行都始终被转义序列所替代。

○枚举型字符串：来自由属性明确定义的集合的不带引号的字符串。枚举型字符串永远不会包含双引号（″）、逗号（,）或空格符。

○十进制分辨率：由“x”字符分隔开的两个十进制整数，指示水平和垂直像素尺寸。

给定的AttributeName的AttributeValue的类型由属性定义来指定。

给定的AttributeName在给定的属性列表中不得出现多于一次。

具有无法识别的AttributeName的属性/值对必须被客户端忽略。

包含无法识别的值的枚举型字符串类型的属性/值对应当被客户端忽略。

3.3.新标签

3.3.1.EXT-X-TARGETDURATION

EXT-X-TARGETDURATION标签指定最大媒体文件持续时间。播放列表文件中的每个媒体文件的EXTINF持续时间必须小于或等于目标持续时间。此标签在播放列表文件中必须出现一次。其格式为：

#EXT-X-TARGETDURATION:<s>

其中s是以秒为单位指示目标持续时间的整数。

3.3.2.EXT-X-MEDIA-SEQUENCE

播放列表中的每个媒体文件URI具有唯一的整数序列号。URI的序列号等于其前的URI的序列号加一。EXT-X-MEDIA-SEQUENCE标签指示播放列表文件中出现的第一URI的序列号。其格式为：

#EXT-X-MEDIA-SEQUENCE:<number>

播放列表文件不得包含多于一个EXT-X-MEDIA-SEQUENCE标签。如果播放列表文件不包含EXT-X-MEDIA-SEQUENCE标签，则播放列表中的第一URI的序列号将被认为是0。

不要求媒体文件的序列号出现在其URI中。

关于处理EXT-X-MEDIA-SEQUENCE标签的信息，参见第6.3.2节和第6.3.5节。

3.3.3.EXT-X-KEY

媒体文件可以被加密。EXT-X-KEY标签提供对跟随其后的媒体文件进行解密所需的信息。其格式为：

#EXT-X-KEY:<attribute-list>

定义了以下属性：

METHOD属性指定加密方法。其是枚举型字符串类型的。定义了两种方法：NONE和AES-128。

加密方法NONE指的是媒体文件不被加密。如果加密方法是NONE，则URI和IV属性不得存在。

加密方法AES-128指的是利用具有128比特密钥和PKCS7填充[RFC5652]的高级加密标准[AES_128]对媒体文件进行加密。如果加密方法是AES-128，则URI属性必须存在。IV属性可以存在；参见第5.2节。

URI属性指定如何获得密钥。其值是包含关于该密钥的URI[RFC3986]的带引号的字符串。

IV属性如果存在则指定要与密钥一起使用的初始化向量。其值是十六进制整数。IV属性出现在协议版本2中。

新的EXT-X-KEY取代任何先前的EXT-X-KEY。

如果播放列表文件不包含EXT-X-KEY标签，则媒体文件不被加密。

关于密钥文件的格式，参见第5节，关于媒体文件加密的额外信息，参见第5.2节、第6.2.3节和第6.3.6节。

3.3.4.EXT-X-PROGRAM-DATE-TIME

EXT-X-PROGRAM-DATE-TIME标签将下一媒体文件的开始与绝对日期和/或时间关联起来。日期/时间表示是ISO/IEC8601:2004[ISO_8601]并且应当指示时区。例如：

#EXT-X-PROGRAM-DATE-TIME:<YYYY-MM-DDThh:mm:ssZ>

关于EXT-X-PROGRAM-DATE-TIME标签的更多信息，参见第6.2.1节和第6.3.3节。

3.3.5.EXT-X-ALLOW-CACHE

EXT-X-ALLOW-CACHE标签指示客户端是可以还是不得缓存下载的媒体文件供以后重放。其可以出现在播放列表文件中的任何地方；其不得出现多于一次。EXT-X-ALLOW-CACHE标签适用于播放列表中的所有片段。其格式为：

#EXT-X-ALLOW-CACHE:<YES|NO>

关于EXT-X-ALLOW-CACHE标签的更多信息，参见第6.3.3节。

3.3.6.EXT-X-PLAYLIST-TYPE

EXT-X-PLAYLIST-TYPE标签提供关于播放列表文件的易变性信息。其是可选的。其格式为：

#EXT-X-PLAYLIST-TYPE:<EVENT|VOD>

第6.2.1节定义了EXT-X-PLAYLIST-TYPE标签的含意。

3.3.7.EXT-X-ENDLIST

EXT-X-ENDLIST标签指示出没有更多媒体文件会被添加到播放列表文件。其可以出现在播放列表文件中的任何地方；其不得出现多于一次。其格式为：

#EXT-X-ENDLIST

3.3.8.EXT-X-STREAM-INF

EXT-X-STREAM-INF标签指示播放列表文件中的下一URI标识另一播放列表文件。其格式为：

#EXT-X-STREAM-INF:<attribute-list>

<URI>

定义了以下属性：

BANDWIDTH

该值是表示每秒比特数的十进制整数。其必须是出现或将会出现在播放列表中的每个媒体文件的整体比特率的上限，被计算为包括容器开销。

每个EXT-X-STREAM-INF标签必须包括BANDWIDTH属性。

PROGRAM-ID

该值是唯一地标识播放列表文件的范围内的特定呈现的十进制整数。

播放列表文件可以包含具有相同的PROGRAM-ID的多个EXT-X-STREAM-INF标签以标识同一呈现的不同编码。这些变体播放列表可以包含额外的EXT-X-STREAM-INF标签。

CODECS

该值是包含格式的逗号分隔列表的带引号字符串，其中每个格式指定在播放列表文件中的媒体文件中存在的媒体样本类型。有效格式标识符是由RFC 4281[RFC4281]定义的ISO文件格式名称空间中的那些。

每个EXT-X-STREAM-INF标签应当包括CODECS属性。

RESOLUTION

该值是描述流内的视频的大致的编码后的水平和垂直分辨率的十进制分辨率。

3.3.9.EXT-X-DISCONTINUITY

EXT-X-DISCONTINUITY标签指示跟随其后的媒体文件和在它前面的媒体文件之间的加密不连续性。可以改变的特性集合是：

○文件格式

○轨道的数目和类型

○编码参数

○编码序列

○时间戳序列

其格式为：

#EXT-X-DISCONTINUITY

关于EXT-X-DISCONTINUITY标签的更多信息，参见第4节、第6.2.1节和第6.3.3节。

3.3.10.EXT-X-VERSION

EXT-X-VERSION标签指示播放列表文件的兼容性版本。播放列表文件、其关联的媒体以及其服务器必须遵从描述标签值指示的协议版本的本文档的最新近版本的所有规定。

其格式为：

#EXT-X-VERSION:<n>

其中n是指示协议版本的整数。

播放列表文件不得包含多于一个EXT-X-VERSION标签。不包含EXT-X-VERSION标签的播放列表文件必须遵从此协议的版本1。

4.媒体文件

播放列表文件中的每个媒体文件URI必须标识作为整体呈现的片段的媒体文件。每个媒体文件必须被格式化为MPEG-2传输流或MPEG-2音频基本流[ISO_13818]。

传输流文件必须包含单个MPEG-2节目。在每个文件的开始处应当有节目关联表和节目映射表。包含视频的文件应当具有至少一个关键帧和足够的信息来完全初始化视频解码器。

播放列表中的媒体文件必须是具有前一序列号的媒体文件的末尾处的编码流的延续，除非其是播放列表文件中曾出现过的第一媒体文件或者其前缀有EXT-X-DISCONTINUITY标签。

客户端应当准备好处理特定类型（例如音频或视频）的多个轨道。没有其他偏好的客户端应当选择其能够播放的具有最低数值PID的那个。

客户端必须忽略传输流内的其未识别出的私有流。

媒体文件内部的流内的和跨多个媒体文件的相应流之间的样本的加密参数应当保持一致。然而，客户端在遇到编码变化时应当应对这种变化，例如通过缩放视频内容以适应分辨率变化。

5.密钥文件

5.1.简介

具有URI属性的EXT-X-KEY标签标识密钥文件。密钥文件包含对播放列表中的后续媒体文件解密必须使用的加密密钥。

AES-128加密方法使用16个八字节的密钥。密钥文件的格式就是二进制格式的这16个八字节的压缩阵列。

5.2.用于AES-128的IV

128比特AES要求在加密和解密时提供相同的16个八字节的初始化向量（IV）。改变此IV将增大密码的强度。

如果EXT-X-KEY标签具有IV属性，则实现方式在利用该密钥进行加密或解密时必须使用该属性值作为IV。该值必须被解释为128比特的十六进制数并且必须前缀有0x或0X。

如果EXT-X-KEY标签不具有IV属性，则实现方式在对媒体文件加密或解密时必须使用该媒体文件的序列号作为IV。序列号的大端二进制表示应被放置在16个八字节的缓冲器中并且（在左侧）被填充以零。

6.客户端/服务器动作

6.1.简介

这一节描述服务器如何生成播放列表和媒体文件以及客户端应当如何下载和播放它们。

6.2.服务器过程

6.2.1.简介

MPEG-2流的产生在本文档的范围之外，本文档就简单地假定一包含呈现的连续流的源。

服务器必须将流划分成持续时间小于或等于恒定的目标持续时间的个体媒体文件。服务器应当尝试在支持个体媒体文件的有效解码的点（例如在分组和关键帧边界上）划分流。

服务器必须为每个媒体文件创建URI，该URI将允许其客户端获得该文件。

服务器必须创建播放列表文件。播放列表文件必须符合第3节中描述的格式。关于服务器希望使之可用的每个媒体文件的URI必须以其要被播放的顺序出现在播放列表中。整个媒体文件必须对客户端可用，如果其URI在播放列表文件中的话。

播放列表文件必须包含EXT-X-TARGETDURATION标签。其值必须等于或大于出现或将会出现在播放列表文件中的任何媒体文件的EXTINF值。其值不得变化。典型的目标持续时间是10秒。

播放列表文件应当包含一个EXT-X-VERSION标签，该标签指示流的兼容性版本。其值必须是服务器、播放列表文件和关联的媒体文件全都遵从的最低协议版本。

服务器必须为播放列表文件创建URI，该URI将允许其客户端获得该文件。

如果播放列表文件通过HTTP来分发，则服务器应当支持使用“gzip”内容编码的客户端请求。

对播放列表文件的改变从客户端设备的角度来看必须以原子的方式进行。

服务器不得改变播放列表文件，除了为了：

向其附加行（第6.2.1节）；

从播放列表中以其出现的顺序去除媒体文件URI，以及只适用于这些媒体文件的任何标签（第6.2.2节）；

改变EXT-X-MEDIA-SEQUENCE标签的值（第6.2.2节）；

添加或去除EXT-X-STREAM-INF标签（第6.2.4节），注意，不要求客户端重加载变体播放列表文件，因此改变它们可能不会立即有效果；

向播放列表添加EXT-X-ENDLIST标签（第6.2.1节）。

另外，播放列表文件可以包含值为EVENT或VOD的EXT-X-PLAYLIST-TYPE标签。如果该标签存在并且值为EVENT，则服务器不得改变或删除播放列表文件的任何部分（虽然其可以向它附加行）。如果该标签存在并且值为VOD，则播放列表文件不得变化。

播放列表中的每个媒体文件URI必须前缀有指示该媒体文件的持续时间的EXTINF标签。

服务器可以通过将媒体文件的URI前缀以EXT-X-PROGRAM-DATE-TIME标签来将绝对日期和时间与该媒体文件关联起来。日期和时间的值提供了媒体的时间线到适当的壁钟时间的信息性映射，这可以用作搜寻、显示的基准或者用于其他目的。如果服务器提供此映射，则其应当将EXT-X-PROGRAM-DATE-TIME标签放置在播放列表文件中的每个EXT-X-DISCONTINUITY标签之后。

如果播放列表包含呈现的最后一个媒体文件，则播放列表文件必须包含EXT-X-ENDLIST标签。

如果播放列表不包含EXT-X-ENDLIST标签，则服务器必须使得包含至少一个新媒体文件URI的新版本的播放列表文件可用。必须相对于使先前版本的播放列表文件可用的时间使以下可用：不早于该时间之后的目标持续时间的一半，并且不晚于该时间之后目标持续时间的1.5倍。

如果服务器希望去除整个呈现，则其必须使播放列表文件对客户端不可用。其应当确保在去除时播放列表文件中的所有媒体文件对客户端保持可用，保持时间至少为播放列表文件的持续时间。

6.2.2.滑动窗口播放列表

服务器可以将媒体文件的可用性限制于最近添加到播放列表的那些。为此，播放列表文件必须始终包含正好一个EXT-X-MEDIA-SEQUENCE标签。对于被从播放列表文件中去除的每个媒体文件URI，其值必须被递增1。

媒体文件URI必须按其被添加的顺序被从播放列表文件中去除。

如果播放列表文件的持续时间减去媒体文件的持续时间小于目标持续时间的三倍，则服务器不得从播放列表文件中去除媒体文件URI。

当服务器从播放列表中去除媒体文件URI时，媒体文件应当在一段时间中对客户端保持可用，该段时间的量等于媒体文件的持续时间加上媒体文件在其中出现的最长播放列表文件的持续时间。

如果服务器计划在媒体文件被通过HTTP递送到客户端之后去除该媒体文件，则其应当确保HTTP响应包含反映计划的生存时间的期满头部。

6.2.3.对媒体文件加密

如果媒体文件要被加密，则服务器必须定义一URI，该URI将允许经授权的客户端获得包含解密密钥的密钥文件。密钥文件必须符合第5节中描述的格式。

服务器可以在指示密钥可被缓存的密钥响应中设定HTTP期满头部。

如果加密METHOD是AES-128，则应对个体媒体文件应用AES-128CBC加密。必须对整个文件加密。不得跨媒体文件应用密码块链接。用于加密的IV必须是媒体文件的序列号或者EXT-X-KEY标签的IV属性的值，如第5.2节中所述。

服务器必须利用如下EXT-X-KEY标签所指定的方法和其他属性对播放列表中的每个媒体文件加密：该EXT-X-KEY标签是播放列表文件中紧挨在其URI之前的那个。前面是METHOD为NONE的EXT-X-KEY标签或者前面没有任何EXT-X-KEY标签的媒体文件不得被加密。

服务器不得从播放列表文件中去除EXT-X-KEY标签，如果播放列表文件包含去到以该密钥加密的媒体文件的URI的话。

6.2.4.提供变体流

服务器可以提供多个播放列表文件以提供同一呈现的不同编码。如果它这样做，则它应当提供列出每个变体流的变体播放列表文件以允许客户端在编码之间动态地切换。

变体播放列表对于每个变体流必须包含EXT-X-STREAM-INF标签。关于同一呈现的每个EXT-X-STREAM-INF标签必须具有相同的PROGRAM-ID属性值。关于每个呈现的PROGRAM-ID值在变体播放列表内必须是唯一的。

如果EXT-X-STREAM-INF标签包含CODECS属性，则该属性值必须包括由[RFC4281]定义的存在于任何出现或将会出现在播放列表文件中的媒体文件中的每一个格式。

服务器在产生变体流时必须满足以下约束：

每个变体流必须呈现相同的内容，包括流不连续处；

每个变体播放列表文件必须具有相同的目标持续时间；

出现在一个变体播放列表文件中但没有出现在另一个中的内容必须出现在该播放列表文件的开头或末尾，并且不得长于目标持续时间；

变体流中的匹配内容必须具有匹配的时间戳，这允许了客户端对流进行同步；

基本音频流文件必须通过在ID3 PRIV标签[ID3]前加上拥有者标识符“com.apple.streaming.transportStreamTimestamp”来发信号通知文件中的第一样本的时间戳，二进制数据必须是表达为大端八个八字节数的33比特MPEG-2节目基本流时间戳，高位的31比特被设定为零。

此外，所有变体流应当包含相同的经编码音频比特流。这允许了客户端在流之间切换，而没有可听见的毛刺。

6.3.客户端过程

6.3.1.简介

客户端如何获得去到播放列表文件的URI在本文档的范围之外；假定这已经完成。

客户端必须从URI获得播放列表文件。如果这样获得的播放列表文件是变体播放列表，则客户端必须从变体播放列表获得播放列表文件。

本文档不规定客户端对变体流的处置。

6.3.2.加载播放列表文件

每次从播放列表URI加载或重加载播放列表文件时：

客户端必须确保该播放列表文件开始于EXTM3U标签，并且确保EXT-X-VERSION标签如果存在则指定客户端所支持的协议版本；如果否，则客户端不得尝试使用该播放列表；

客户端应当忽略其未识别出的任何标签和属性；

客户端必须如第6.3.5节中所述确定要加载的下一个媒体文件。

如果播放列表包含EXT-X-MEDIA-SEQUENCE标签，则客户端应当假定在如下时间其中的每个媒体文件将变得不可用：该时间是加载播放列表文件的时间加上播放列表文件的持续时间。播放列表文件的持续时间是其内的媒体文件的持续时间的总和。

6.3.3.播放播放列表文件

客户端应选择在回放开始时从播放列表中首先播放哪个媒体文件。如果EXT-X-ENDLIST标签不存在并且客户端想要以常规方式（即，按照播放列表顺序，以标称的回放速率）播放媒体，则客户端不应当选择在离播放列表文件的末尾小于三个目标持续时间的时间开始的文件。这样做可触发回放停顿。

为了实现常规回放，媒体文件必须被按它们出现在播放列表文件中的顺序播放。客户端可以以其希望的任何方式呈现可用媒体，包括常规回放、随机访问和特技模式。

客户端在播放前面是EXT-X-DISCONTINUITY标签的媒体文件之前必须准备好重设其（一个或多个）解析器和（一个或多个）解码器。

客户端应当在需要媒体文件之前就尝试加载媒体文件以便进行不间断的回放以对延迟和吞吐量的临时变化进行补偿。

如果播放列表文件包含EXT-X-ALLOW-CACHE标签并且其值为NO，则在下载的媒体文件已被播放之后客户端不得缓存下载的媒体文件。否则，客户端可以无限期地缓存下载的媒体文件以供以后重放。

客户端可以使用EXT-X-PROGRAM-DATE-TIME标签的值来向用户显示节目起始时间。如果该值包括时区信息，则客户端应将其考虑在内，但如果不包括，则客户端不得推断发源时区。

客户端不得依赖于EXT-X-PROGRAM-DATE-TIME标签的值的正确性或一致性。

6.3.4.重加载播放列表文件

客户端必须周期性地重加载播放列表文件，除非其包含EXT-X-ENDLIST标签。

然而，客户端不得尝试比本节规定的更频繁地重加载播放列表文件。

当客户端第一次加载播放列表文件或者重加载播放列表文件并发现其从上次被加载起已改变了时，客户端在尝试再次重加载播放列表文件之前必须等待一段时间。此时段被称为初始最小重加载延迟。它是从客户端开始加载播放列表文件的时间起测量的。

初始最小重加载延迟是播放列表中的最后一个媒体文件的持续时间。媒体文件持续时间由EXTINF标签指定。

如果客户端重加载播放列表文件并且发现其没有变化，则客户端在重试之前必须等待一段时间。最小延迟是目标持续时间的倍数。这个倍数对于第一次尝试是0.5，对于第二次是1.5，对于以后的是3.0。

为了减轻服务器负载，客户端不应当重加载当前没在播放的变体流的播放列表文件。如果其决定将回放切换到另一不同变体，则其应当停止重加载旧变体的播放列表并且开始加载新变体的播放列表。它可以使用EXTINF持续时间和第6.2.4节中的约束来确定相应媒体的大致位置。一旦已经加载了来自新变体的媒体，就可以使用媒体文件中的时间戳来精确地同步旧时间线和新时间线。

6.3.5.确定要加载的下一文件

每次播放列表文件被加载或重加载时，客户端必须检查该播放列表文件以确定要加载的下一媒体文件。

要加载的第一文件必须是客户端选择要首先播放的文件，如第6.3.3节中所述。

如果要播放的第一文件已被加载并且播放列表文件不包含EXT-X-MEDIA-SEQUENCE标签，则客户端必须验证当前播放列表文件在起初找到最后加载的媒体文件的URI的偏移量处包含该URI，如果不包含则停止回放。要加载的下一媒体文件必须是播放列表中跟随在最后加载的URI之后的第一媒体文件URI。

如果要播放的第一文件已被加载并且播放列表文件包含EXT-X-MEDIA-SEQUENCE标签，则要加载的下一媒体文件可以是具有大于加载的最后媒体文件的序列号的最低序列号的那个。

6.3.6.对经加密的媒体文件解密

如果播放列表文件包含指定密钥文件URI的EXT-X-KEY标签，则客户端必须获得该密钥文件并且使用其内的密钥来对跟随在EXT-X-KEY标签之后的所有媒体文件解密，直到遇到另一EXT-X-KEY标签为止。

如果加密METHOD是AES-128，则应对个体媒体文件应用AES-128CBC解密。必须对整个文件解密。不得跨媒体文件应用密码块链接。用于解密的IV必须是媒体文件的序列号或者EXT-X-KEY标签的IV属性的值，如第5.2节中所述。

如果加密METHOD是NONE，则客户端必须将跟随在EXT-X-KEY标签之后的所有媒体文件视为明文（未加密），直到遇到另一EXT-X-KEY标签为止。

7.协议版本兼容性

客户端和服务器必须实现协议版本2或更高版本以便使用：

○EXT-X-KEY标签的IV属性。

客户端和服务器必须实现协议版本3或更高版本以便使用：

○浮点EXTINF持续时间值。

8.示例

8.1.简介

这一节包含若干个示例播放列表文件。

8.2.简单播放列表文件

#EXTM3U

#EXT-X-TARGETDURATION:5220

#EXTINF:5220,

http://media.example.com/entire.ts

#EXT-X-ENDLIST

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.具有经加密的媒体文件的播放列表文件

#EXTM3U

#EXT-X-MEDIA-SEQUENCE:7794

#EXT-X-TARGETDURATION:15

#EXT-X-KEY:METHOD=AES-128,URI=″https://priv.example.c om/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.c om/key.php?r=53″

#EXTINF:15,

http://media.example.com/fileSequence53-1.ts

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

9.安保考虑

由于协议一般使用HTTP来传送数据，所以大多数相同的安保考虑都是适用的。参见RFC 2616[RFC2616]的第15节。

媒体文件解析器通常容易遭受“侦查（fuzzing）”攻击。客户端在对从服务器接收的文件进行解析时应当小心，以便拒绝不符合的文件。

播放列表文件包含URI，客户端将使用这些URI来作出任意实体的网络请求。客户端应当对响应进行范围检查以防止缓冲器溢出。另见RFC 3986[RFC3986]的“Security Considerations”这一节。

客户端应当懒惰地加载由URI标识的资源，以避免促成拒绝服务攻击。

HTTP请求经常包括会话状态（“cookie”），该会话状态可包含私密用户数据。实现方式必须遵循RFC 2965[RFC2965]规定的cookie限制和期满规则。另见RFC 2965的“Security Considerations”这一节，以及RFC 2964[RFC2964]。

加密密钥由URI指定。应当通过诸如基于TLS的HTTP[RFC5246]（以前是SSL）之类的机制结合安全领域或会话cookie来保护这些密钥的递送。

10.参考文献

10.1.规范性参考文献

[AES_128]U.S.Department of Commerce/National Institute of Standardsand Technology,″Advanced Encryption Standard(AES),FIPSPUB197″,November 2001,

<http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf

<http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf>>.

[ISO_13818]International Organization for Standardization,″ISO/IECInternational Standard13818;Generic coding of movingpictures and associated audio information″,October 2007,

<http://www.iso.org/iso/catalogue_detail?csnumber=44169>.

[ISO_8601]International Organization for Standardization,″ISO/IECInternational Standard8601:2004;Data elements andinterchange formats--Information interchange--Representation of dates and times″,December2004,

<http://www.iso.org/iso/catalogue_detail?csnumber=40874>.

[RFC2046]Freed,N.and N.Borenstein,″Multipurpose Internet MailExtensions(MIME)Part Two:Media Types″,RFC2046,November1996.

[RFC2119]Bradner,S.,″Key words for use in RFCs to IndicateRequirement 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,June1999.

[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 ManagementMechanism″,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,″UniformResource Identifier(URI):Generic Syntax″,STD66,RFC3986,January 2005.

[RFC4281]Gellens,R.,Singer,D.,and P.Frojdh,″The Codecs Parameterfor″Bucket″Media Types″,RFC 4281,November 2005.

[RFC5246]Dierks,T.and E.Rescorla,″The Transport Layer Security(TLS)Protocol Version1.2″,RFC 5246,August 2008.

[RFC5652]Housley,R.,″Cryptographic Message Syntax(CMS)″,STD70,RFC 5652,September2009.

[US_ASCII]American National Standards Institute,″ANSI X3.4-1986,Information Systems--Coded Character Sets7-Bit AmericanNational Standard Code for Information Interchange(7-BitASCII)″,December1986.

10.2.信息性参考文献

[ID3]ID3.org<http://ID3.org/>,″The ID3audio file data taggingformat″,<http://www.id3.org/Developer_Information>.

[M3U]Nullsoft,Inc.,″The M3U Playlist format,originally invented forthe Winamp media player″,<http://wikipedia.org/wiki/M3U>.

Claims (25)

1.一种机器可读非暂态存储介质，其存储可执行指令，所述指令在执行时使数据处理系统执行一种方法，该方法包括：

接收第一播放列表，该第一播放列表包括关于第二播放列表的URL和关于第三播放列表的URL，所述第二播放列表包括指定文件的包含I帧的部分的多个URL，并且所述第三播放列表包括用于以1X速度显示视频的多个URL；

确定不同于1X的回放速度；

响应于确定所述回放速度而发送关于所述第二播放列表的URL；

接收所述第二播放列表；

利用所述第二播放列表中的URL发送对I帧的请求；

以所述回放速度呈现响应于所述对I帧的请求而接收到的I帧；且

其中，所述第二播放列表中的URL与指定包含I帧的所述文件中每个I帧的数据范围的参数相关联。

2.如权利要求1所述的介质，其中，所述第三播放列表中与URL相关联的标签包括指定所述文件中包含视频的数据范围的参数。

3.如权利要求1所述的介质，其中，所述第一播放列表包括关于相应的多个1X播放列表的、用以在不同的分辨率或不同的质量下以1X速度显示视频的多个URL，并且所述第一播放列表包括关于相应的多个仅含I帧的播放列表的、不同分辨率或不同质量的多个URL。

4.如权利要求3所述的介质，其中，所述第二播放列表具有标签，所述标签与其相应的URL相关联或者与其相应的URL相邻，指定所述文件的只包含I帧的部分。

5.如权利要求3所述的介质，其中，所述第二播放列表中的每个URL具有与该URL相关联的电影时间元数据。

6.如权利要求5所述的介质，其中，每个I帧的数据范围由字节范围指定，每个字节范围包括当以所述回放速度进行回放时未使用的音频数据。

7.一种数据处理系统，包括：

用于接收第一播放列表的装置，该第一播放列表包括关于第二播放列表的URL和关于第三播放列表的URL，所述第二播放列表包括指定文件的包含I帧的部分的多个URL，所述第三播放列表包括用于以1X速度显示视频的多个URL；

用于确定不同于1X的回放速度的装置；

用于响应于确定所述回放速度而发送关于所述第二播放列表的URL的装置；

用于接收所述第二播放列表的装置；

用于利用所述第二播放列表中的URL发送对I帧的请求的装置；

用于以所述回放速度呈现响应于所述对I帧的请求而接收到的I帧的装置；且

其中，所述第二播放列表中的URL与指定包含I帧的文件中每个I帧的数据范围的参数相关联。

8.如权利要求7所述的系统，其中，所述第三播放列表中与URL相关联的标签包括指定所述文件中包含视频的数据范围的参数。

9.如权利要求7所述的系统，其中，所述第一播放列表包括关于相应的多个1X播放列表的、用以在不同的分辨率或不同的质量下以1X速度显示视频的多个URL，并且所述第一播放列表包括关于相应的多个仅含I帧的播放列表的、不同分辨率或不同质量的多个URL。

10.如权利要求9所述的系统，其中，所述第二播放列表具有标签，所述标签与其相应的URL相关联或者与其相应的URL相邻，指定所述文件的只包含I帧的部分。

11.如权利要求9所述的系统，其中，所述第二播放列表中的每个URL具有与该URL相关联的电影时间元数据，每个I帧的数据范围由字节范围指定，每个字节范围包括当以所述回放速度回放时未使用的音频数据。

12.一种机器可读非暂态存储介质，其存储可执行指令，所述指令在执行时使得数据处理系统执行一种方法，该方法包括：

确定一组参数，包括回放速率和可用于下载至少一个I帧的时间段；

确定可用I帧的第一集合，所述第一集合中的I帧是基于所述一组参数确定的；

确定多个I帧子集，所述多个I帧子集中的每个具有所述可用I帧的第一集合中的I帧的子集；

为所述多个I帧子集中的每个确定估计下载时间；

基于所述估计下载时间和所述一组参数选择所述多个I帧子集中的一个；

接收并显示所述多个I帧子集中的所选择的一个中的I帧。

13.如权利要求12所述的介质，其中，对I帧的显示提供对I帧中的视频内容的按照不同于1X的回放速率的特技播放回放模式，并且每个I帧是利用与URL相关联的标签取回的，该标签包括标识文件的包含相应I帧的部分的字节范围。

14.如权利要求13所述的介质，其中，所述一组参数还包括显示期限参数和正显示的当前I帧的当前电影时间，并且所述时间段是根据所述当前电影时间和所述回放速率以及所述显示期限参数得出的。

15.如权利要求14所述的介质，其中，所述显示期限参数设定为约1/2秒到约2秒的范围中的固定持续时间，并且所述显示期限参数被乘以所述回放速率以产生一乘积，该乘积是一时间值，该时间值被与所述当前电影时间相加以得出所述时间段。

16.如权利要求15所述的介质，其中，所述多个I帧子集中的每个具有预定节奏，该节奏在所述多个子集之间是不同的。

17.如权利要求16所述的介质，其中，所述多个子集中的每个子集中的I帧数目受预定最大数目的限制。

18.如权利要求17所述的介质，其中，所述多个I帧子集中的每个子集的所述预定节奏是以下之一：（a）所述第一集合中的可用I帧中的每一个；（b）可用I帧中的每隔一个；以及（c）可用I帧中的每隔两个。

19.一种数据处理系统，包括：

用于确定一组参数的装置，所述一组参数包括回放速率和可用于下载至少一个I帧的时间段；

用于确定可用I帧的第一集合的装置，所述第一集合中的I帧是基于所述一组参数确定的；

用于确定多个I帧子集的装置，所述多个I帧子集中的每个具有所述可用I帧的第一集合中的I帧的子集；

用于为所述多个I帧子集中的每个子集确定估计下载时间的装置；

用于基于所述估计下载时间和所述一组参数选择所述多个I帧子集中的一个子集的装置；

用于接收并显示所述多个I帧子集中的所选择的一个子集中的I帧的装置。

20.如权利要求19所述的系统，其中，对I帧的显示提供对I帧中的视频内容的按照不同于1X的回放速率的特技播放回放模式，并且每个I帧是利用与URL相关联的标签取回的，该标签包括标识文件的包含相应I帧的部分的字节范围。

21.如权利要求20所述的系统，其中，所述一组参数还包括显示期限参数和正显示的当前I帧的当前电影时间，并且所述时间段是根据所述当前电影时间和所述回放速率以及所述显示期限参数得出的。

22.如权利要求21所述的系统，其中，所述显示期限参数设定为约1/2秒到约2秒的范围中的固定持续时间，并且所述显示期限参数被乘以所述回放速率以产生一乘积，该乘积是一时间值，该时间值被与所述当前电影时间相加以得出所述时间段。

23.如权利要求22所述的系统，其中，所述多个I帧子集中的每个子集具有预定节奏，该节奏在所述多个子集之间是不同的。

24.如权利要求23所述的系统，其中，所述多个子集中的每个子集中的I帧的数目受预定最大数目的限制。

25.如权利要求24所述的系统，其中，所述多个I帧子集中的每个子集的所述预定节奏是以下之一：（a）所述第一集合中的可用I帧中的每一个；（b）可用I帧中的每隔一个；以及（c）可用I帧中的每隔两个。

Images