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

Abstract

内容流传输系统——例如HTTP流传输系统——可以使用变体音频播放列表，该变体音频播放列表标识关于同一节目的不同音频播放列表，例如英语的一个播放列表和西班牙语的一个播放列表，该同一节目例如是由可与该变体音频播放列表分开的视频播放列表指定的视频节目。客户端可使用该变体音频播放列表来选择关于同一节目的特定音频内容，并且在该变体音频播放列表中的关于替换音频内容的一组替换URL之中，该音频播放列表中的一个URL可涉及该特定音频内容。

Description

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

相关申请

本申请根据35U.S.C.§119(e)要求2011年6月3日递交的61/493,324号美国临时申请的申请日的权益。本美国专利申请还与以下美国专利申请相关，这里通过引用并入每个以下美国专利申请：

（1）2009年6月5日递交的题为“REAL-TIME OR NEAR REAL-TIME STREAMING”的12/479,690号申请（案卷号P7437US1）；

（2）2009年6月5日递交的题为“VARIANT STREAMS FOR REAL-TIME OR NEAR REAL-TIME STREAMING”的12/479,698号申请（案卷号P7437US2）；

（3）2009年6月5日递交的题为“UPDATABLE REAL-TIME OR NEAR REAL-TIMESTREAMING”的12/479,732号申请（案卷号P7437US3）；以及

（4）2009年6月5日递交的题为“PLAYLISTS FOR REAL-TIME OR NEAR REAL-TIMESTREAMING”的12/479,735号申请（案卷号P7437US4）。

技术领域

本发明的实施例涉及数据传送技术。更具体而言，本发明的实施例涉及允许利用非流传输协议——例如超文本传送协议（HyperText Transfer Protocol，HTTP）——对数据进行流传输（streaming）的技术。

背景技术

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

当前的流传输服务一般要求专门的服务器来向最终用户分发“实况”内容。在任何大规模部署中，这可导致巨大的成本，并且要求专门的技能来设立和运行。这导致了可用于流传输的内容库的量达不到合乎需要的程度。

发明内容

在一个实施例中，HTTP流传输系统可以使用变体播放列表，该变体播放列表标识关于同一视频节目的不同音频播放列表，例如一个是英语的，另一个是西班牙语的，而另一个是汉语的，该视频节目还具有关于视频内容的播放列表。例如，实况体育事件——例如棒球比赛——可具有从服务器发送到客户端的视频播放列表，并且同一实况体育事件可具有变体音频播放列表，该变体音频播放列表指定不同的音频播放列表，这些不同的音频播放列表对应于不同的语言或不同的覆盖角度（例如广播比赛的本地广播公司与广播该比赛的国家广播公司）。客户端设备可从服务器下载视频播放列表并且还下载变体音频播放列表，然后客户端设备可从变体音频播放列表中选择适当的音频节目并且下载与所选择的适当音频节目相对应的适当音频播放列表。在下载了视频播放列表和所选音频播放列表两者后，客户端可以开始同时地——并且在一个实施例中独立地——处理两个播放列表，以在客户端设备处创建并呈现视频和音频。

一个实施例中在客户端设备处的一种方法可包括以下操作：接收关于节目的变体音频播放列表，其中该变体音频播放列表包含关于节目的不同音频内容的一组URL，并且该组URL中的每个URL涉及与该节目的不同音频内容之一相对应的音频播放列表；选择该组URL中的关于不同音频内容之一的第一URL，该第一URL涉及第一播放列表；发送涉及第一播放列表的第一URL；接收第一播放列表；以及处理第一播放列表以取回该节目的音频内容。在一个实施例中，该方法还可包括确定音频偏好，并且此音频偏好可由用户设定，例如用户偏好中的设定，并且此音频偏好可引起该方法中对第一URL的选择。该方法在一个实施例中还可包括接收关于该节目的视频播放列表；该视频播放列表可包含关于该节目的视频内容的URL，并且每个关于视频内容的URL与视频内容的时间上的一部分相关联或者涉及视频内容的时间上的一部分。这个时间部分匹配在视频播放列表被处理的同时被客户端设备同时处理的音频播放列表的时间部分。该方法还可包括通过使用变体音频播放列表选择不同的音频播放列表来在关于音频内容的URL之间切换；在一个实施例中，在变体音频播放列表中的音频播放列表之间的切换可独立于视频播放列表的回放执行。该方法还可包括在一个实施例中同时且独立地处理音频播放列表和视频播放列表；例如，作为用于音频的播放器的第一软件组件可独立于处理视频播放列表的第二软件组件地处理音频播放列表。另外，在一个实施例中，音频下载模块可独立地下载并处理音频内容，同时视频下载模块可单独下载并处理视频内容。在一个实施例中，通过音频播放列表取回的音频内容中的时间戳和通过视频播放列表取回的视频内容中的时间戳指定相同时间段。另外，涉及不同音频内容的该组URL中的每个URL包括指定相同时间段的时间戳。

在本发明的一个实施例中由服务器设备执行的一种方法可包括响应于来自设备的请求而发送变体音频播放列表，该变体音频播放列表包含关于被请求的节目的不同音频内容的一组URL，其中该组URL中的每个URL涉及与该节目的不同音频内容之一相对应的音频播放列表。该方法还可包括从该设备接收该组URL中的第一URL并且响应于接收到第一URL而向该设备发送第一音频播放列表，其中该第一URL涉及第一音频播放列表。

这里描述了其他方法，并且这里还描述了机器可读非暂态存储介质，并且这里也描述了执行这些方法的系统。

附图说明

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

图10示出了可包括关于同一节目的不同音频内容的URL的变体播放列表的示例。

图11是示出在一个实施例中用于使用包括关于同一节目的音频内容的变体的URL的变体播放列表的方法的流程图。

图12示出了可用于这里描述的一个或多个实施例中的具有各种组件的客户端设备的示例。

图13是示出根据一个实施例由一服务器设备或一组服务器设备执行的方法的流程图。

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

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

具体实施方式

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

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

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

本说明书的一个方面涉及使用为所选节目提供音频的变体的音频播放列表；例如，音频播放列表可以为还具有关于视频内容的播放列表的同一视频节目提供采取不同语言的不同播放列表，其中该视频播放列表与采取不同语言的音频播放列表是分开的。在结合图1至9D提供一些背景信息之后将结合图10至15描述这些方面。

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

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

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

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

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

网络110可以是任何类型的网络，无论是有线的、无线的（例如，IEEE802.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等等）以充当在媒体文件被接收到时存储媒体文件（例如经压缩的媒体文件或者经解压缩的媒体文件）的缓冲器；缓冲器可提供超出当前正在呈现的内容的时间以外的许多秒的可呈现内容，从而使得缓冲的内容随后可在新内容被下载的同时被显示。此缓冲器可在客户端设备正尝试通过间歇性缓慢的网络连接取回内容的同时提供可呈现内容，因此缓冲器可隐藏网络延迟或连接问题。

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

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

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

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

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

播放列表文件在一个实施例中是由个体行组成的扩展M3U格式的文本文件。这些行可终止于单个LF字符或者CR字符后跟LF字符。每一行可以是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/IEC8601: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-128CBC加密可被应用到个体媒体文件。在一个实施例中，整个文件被加密。在一个实施例中，通常不跨媒体文件应用密码块链接。媒体文件的序列如上所述被用作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。在替换实施例中，可支持其他非流传输协议。响应于该请求，服务器将通过网络把相应的播放列表文件发送到客户端。如上所述，网络可以是有线的或无线的并且可以是有线或无线网络的任何组合。另外，网络可以是数据网络（例如IEEE802.11、IEEE802.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标签的值来向用户显示节目起始时间。在一个实施例中，客户端可缓冲多个媒体文件，以使得其不那么容易受网络抖动的影响，以便提供更好的用户体验。

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

在操作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标签。

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

图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（及其关联的音频样本）开始，节目的呈现使用从第二媒体播放列表获得的第二流。前述方法在一个实施例中既可用于从较慢到较快比特率的改变也可用于从较快到较慢比特率的改变，但在另一实施例中该方法可仅用于从较慢到较快比特率的改变，而另一方法（例如，不尝试定位转变点，而是尝试尽可能快地存储和呈现来自较慢比特率流的内容）可用于从较快到较慢比特率的改变。

本发明的一个方面涉及变体音频播放列表，并且现在将结合图10至15来描述其结合HTTP实况流传输系统的使用。变体播放列表1001在图10中示出，并且其可包括关于同一节目——例如同一实况体育事件或视频点播或电影等等——的相应的多个不同音频内容的多个URL。另外，变体播放列表1001还可包括关于视频内容的多个URL，其中这些播放列表中的每一个是关于同一节目的，但却是关于不同带宽或质量水平的。关于视频内容的URL也可包括音频内容，并且如果客户端设备从变体音频播放列表中选择替换音频内容，则该所选的替换内容将推翻从视频播放列表取回或可取回的任何音频的呈现。对变体播放列表或变体音频播放列表的使用允许内容提供者给予客户端设备从可以推翻主呈现的多种不同音频内容中进行选择的选项。在一个实施例中，客户端设备可以只播放来自从变体音频播放列表中选择的所选音频播放列表的音频，并且将抑制来自其他播放列表的任何音频，所述其他播放列表例如是视频播放列表，该视频播放列表可用于从包含音频和视频两者的文件中取回音频，所述音频和视频已被一起复用在内容的文件中。这允许该呈现提供音频的多个版本，而不要求内容提供者存储包含替换音频内容的重复视频，并且不要求客户端在其只需要一个音频变体时下载所有音频变体。这还允许随后在不重新录制原始内容的情况下提供额外的音频。

可以看出，图10中的变体播放列表1001既包括关于视频播放列表的URL，例如URL1003和1005，也包括关于由视频播放列表1003和1005提供的节目的音频内容的三个不同音频版本（1007、1009和1011）的三个URL。在图10中所示的示例中，变体播放列表1001包括关于视频内容的URL以及关于替换音频内容的URL；还将会明白，在其他实施例中，可以向客户端设备提供两个单独的变体播放列表，其中一个包含关于视频内容的URL，而另一个单独的变体播放列表包含变体音频播放列表URL，而不是如图10中所示那样有包括两者的单个变体播放列表。在一个实施例中，每个仅含音频的播放列表是满足附录中的规范的第6.2.4节的所有约束的独立播放列表。

在另一实施例中，为变体播放列表定义新标签，该变体播放列表可提供替换音频（例如同一节目的不同语言）或替换视频（例如同一节目的不同相机角度或位置）或替换音频和替换视频两者的组合。在此实施例中，新标签可具有以下语法：

#EXT-X-MEDIA:TYPE=<type>,GROUP-ID=<group-id>,

NAME=<name>[,LANGUAGE=<language-tag>],

[,AUTOSELECT=<yes or no>][,DEFAULT=<yes or no>],

URI=<url>

其中type是AUDIO或VIDEO，GROUP-ID是定义“群组”的字符串，并且其中名称是描述性字符串，language-tag是rfc4646语言标签，AUTOSELECT向客户端指示出流是否要被自动选择，DEFAULT用于选择群组中的初始条目（例如，替换音频群组中的初始条目或替换视频群组中的初始条目），并且URI是播放列表——例如替换音频播放列表或替换视频播放列表——的URI。使用这种类型的新标签的变体播放列表的示例是：

#EXTM3U

#EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="aac",

LANGUAGE="eng",NAME="English",AUTOSELECT=YES,DEFAULT=YES,

URI="OCEANS11_20min_English_Stereo/prog_index.m3u8"

#EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="aac",

LANGUAGE="eng",NAME="Commentary1",AUTOSELECT=NO,DEFAULT=NO,

URI="OCEANS11_20min_Commentary1_Stereo/prog_index.m3u8"#EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="aac",

LANGUAGE="eng",NAME="Commentary2",AUTOSELECT=NO,DEFAULT=NO,

URI="OCEANS11_20min_Commentary2_Stereo/prog_index.m3u8"#EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="aac",

LANGUAGE="fre",NAME="French",AUTOSELECT=YES,DEFAULT=NO,

URI="OCEANS11_20min_French_Stereo/prog_index.m3u8"

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1233110,C ODECS="mp4a.40.2,avc1.4d401e",AUDIO="aac"

OCEANS11_20min_Audio_Video_500Kbs/prog_index.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=2027440,C ODECS="mp4a.40.2,avc1.4d4014",AUDIO="aac"

OCEANS11_20min_Audio_Video_1Mbs/prog_index.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=5334235,C ODECS="mp4a.40.2,avc1.4d401e",AUDIO="aac"

OCEANS11_20min_Audio_Video_3Mbs/prog_index.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=9451601,C ODECS="mp4a.40.2,avc1.4d401e",AUDIO="aac"

OCEANS11_20min_Audio_Video_6Mbs/prog_index.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=16090967,CODECS="mp4a.40.2,avc1.64001e",AUDIO="aac"

OCEANS11_20min_Audio_Video_12Mbs/prog_index.m3u8

EXT-X-STREAMINF的新属性是AUDIO=<group-id>或者VIDEO=<group-id>的<type>值；将会明白，可以指定其他媒体类型（例如字幕）。在此实施例中，类型和名称值形成元组。如果需要，可以有多个群组以允许编解码器或比特率的变化，并且在此实施例中，改变group-id来提供多个群组；具有不同的group-ID（以允许多个群组）的变体播放列表的示例是：

#EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="aac",

LANGUAGE="eng",NAME="English",AUTOSELECT=YES,DEFAULT=YES,

URI="OCEANS11_20min_English_Stereo/prog_index.m3u8"

#EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="aac",

LANGUAGE="eng",NAME="Commentary1",AUTOSELECT=NO,DEFAULT=NO,

URI="OCEANS11_20min_Commentary1_Stereo/prog_index.m3u8"#EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="aac",

LANGUAGE="eng",NAME="Commentary2",AUTOSELECT=NO,DEFAULT=NO,

URI="OCEANS11_20min_Commentary2_Stereo/prog_index.m3u8"#EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="aac",

LANGUAGE="fre",NAME="French",AUTOSELECT=YES,DEFAULT=NO,

URI="OCEANS11_20min_French_Stereo/prog_index.m3u8"

#EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="AC3",

LANGUAGE="eng",NAME="English",AUTOSELECT=YES,DEFAULT=YES,

URI="OCEANS11_20min_English_AC3/prog_index.m3u8"

#EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="AC3",

LANGUAGE="eng",NAME="Commentary1",AUTOSELECT=NO,DEFAULT=NO,

URI="OCEANS11_20min_Commentary1_AC3/prog_index.m3u8"

#EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="AC3",

LANGUAGE="eng",NAME="Commentary2",AUTOSELECT=NO,DEFAULT=NO,

URI="OCEANS11_20min_Commentary2_AC3/prog_index.m3u8"

#EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="AC3",

LANGUAGE="fre",NAME="French",AUTOSELECT=YES,DEFAULT=NO,

URI="OCEANS11_20min_French_AC3/prog_index.m3u8"

这里是变体视频播放列表的示例（具有关于同一节目的不同相机角度，该节目是滚石视频）：

#EXT-X-MEDIA:TYPE=VIDEO,GROUP-ID="4Mbs",

NAME="Angle1-Mick",AUTOSELECT=YES,DEFAULT=NO,URI="Mick-4Mbs/prog_index.m3u8"

#EXT-X-MEDIA:TYPE=VIDEO,GROUP-ID="4Mbs",

NAME="Angle2-Keith",AUTOSELECT=YES,DEFAULT=NO,URI="Keith-4Mbs/prog_index.m3u8"

#EXT-X-MEDIA:TYPE=VIDEO,GROUP-ID="4Mbs",

NAME="Angle3-Ronnie",AUTOSELECT=YES,DEFAULT=NO,URI="Ronnie-4Mbs/prog_index.m3u8"

#EXT-X-MEDIA:TYPE=VIDEO,GROUP-ID="4Mbs",

NAME="Angle4-Charlie",AUTOSELECT=YES,DEFAULT=NO,URI="Charlie-4Mbs/prog_index.m3u8"

#EXT-X-MEDIA:TYPE=VIDEO,GROUP-ID="4Mbs",

NAME="Angle5-All",AUTOSELECT=YES,DEFAULT=YES#EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="aac",

LANGUAGE="eng",NAME="English AAC",AUTOSELECT=YES,DEFAULT=YES,

URI="Stones_Angie_Audio_AAC_140kbs/prog_index.m3u8"

#EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="AC3",

LANGUAGE="eng",NAME="English AC3",AUTOSELECT=YES,DEFAULT=YES,

URI="Stones_Angie_Audio_AC3_640kbs/prog_index.m3u8"

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=4742970,C ODECS="mp4a.40.2,avc1.4d401e",VIDEO="4Mbs",AUDIO="aac"All-4Mbs/prog_index.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=5215970,C ODECS="ac-3,avc1.4d401e",VIDEO="4Mbs",AUDIO="AC3"All-4Mbs/prog_index.m3u8

虽然此变体视频播放列表只有一个比特率，但可向此播放列表添加具有更多比特率的更多变体。

图11示出了可由处理变体音频播放列表的客户端设备执行的一种方法的示例，该变体音频播放列表例如是图10中的变体播放列表1001或者上述的变体播放列表。在一个实施例中，执行图11的方法的客户端设备可以是硬件设备，例如图8中所示的那种，并且可包括软件体系结构，例如图12中所示的那种。在操作1101中，客户端设备可请求节目，例如视频点播节目或实况体育事件，或者记录的体育事件或电影，或者其他具有音频内容的内容。对特定节目的请求可通过用户应用，例如用户应用1203，用户应用1203在一个实施例中可以是来自Netflix的应用或者来自美国职棒大联盟的应用或者被设计为允许用户浏览内容目录并从内容目录中选择节目之一的其他应用。响应于操作1101中的请求，客户端设备可在操作1103中接收变体播放列表，该变体播放列表包括关于音频内容的变体的一个或多个URL并且可选地还包括关于视频内容的变体的一个或多个URL。在操作1103中接收的变体播放列表可以是变体播放列表1205（存储在设备1201中的存储器中），该变体播放列表1205可被用户应用1203处理以便向用户呈现用户界面以允许用户从可用的音频节目的变体中选择特定的音频节目。在另一实施例中，由用户设定的用户偏好可设定默认语言，例如设定英语为默认或者设定汉语为默认或者设定西班牙语为默认，等等，并且当用户应用处理变体播放列表以选择特定的音频播放列表时可以自动地使用该选择。然后在操作1105中，客户端系统可以从变体音频播放列表中选择特定的音频播放列表并且可选地还选择特定的视频播放列表（从同一播放列表或另一变体播放列表中）；这些选择可通过用户与客户端设备的用户界面的交互发生或者在没有用户输入的情况下通过客户端设备的操作通过默认设定或者用户先前设定的用户偏好发生，等等。然后，在操作1107中，客户端设备可发送所选音频播放列表的URL，并且如果在操作1105中选择了视频播放列表则还发送所选视频播放列表的URL。响应于这些发送的URL，客户端设备在操作1109中接收并处理所选的音频播放列表；对音频播放列表的处理可以按与现有HTTP实况流传输协议下对其他音频播放列表的处理类似的方式执行。如果在操作1107中也选择了所选的视频播放列表的URL，则客户端设备将在操作1111中接收并处理所选的视频播放列表。在一个实施例中，对音频播放列表的处理与对视频播放列表的处理是分开且不同的，但它们是同时执行的。在一个实施例中，用于音频播放列表的软件下载模块可与用于视频播放列表的视频下载模块分开，如图12的体系结构中所示。在一个实施例中，视频播放列表将涉及也包括音频的媒体文件，并且该音频可以是节目的默认或主呈现音频，在此情况下客户端设备将抑制该默认音频的回放。对视频播放列表所涉及的该默认音频的回放的抑制在一个实施例中可通过如下方式执行：如果该音频是文件的单独部分，则不下载该音频，或者如果对该音频的下载无法避免，则不处理下载的音频。

图12示出了可实现图11中所示的方法或者结合变体音频播放列表描述的其他方法的客户端设备的体系结构的示例。客户端设备1201中所示的组件可以是软件组件（在数据处理系统——例如图8中所示的系统——上运行）或者硬件组件或者软件和硬件组件的组合。在一个实施例中，用户应用1203是被用户运行来显示电影或棒球比赛或听电台节目等等的软件应用。例如，在一个实施例中，用户应用可以是由Netflix提供来观看电影的应用或者美国职棒大联盟提供来观看实况棒球比赛或记录的棒球比赛的应用。用户应用1203可处理变体播放列表1205以向用户呈现用户界面，以允许用户从由变体音频播放列表指定的各种不同的音频内容中进行选择；或者，用户应用1203可在没有用户交互的情况下基于先前确立的用户偏好通过搜索变体音频播放列表——例如变体播放列表1205——来自动选择特定的音频内容，以选择和定义适当的音频内容。用户应用1203可与音频播放器1207和视频播放器1209交互，以便接收并呈现来自这些播放器中的每一个的内容。音频播放器1207可处理音频播放列表1211，该处理与处理视频播放列表1213的视频播放器1209的处理独立。视频播放列表1213可以是如这里所述的传统视频播放列表，而音频播放列表1211是提供仅含音频的内容的播放列表。如果视频播放列表1213包括包含音频数据的URL，则视频播放器1209应当通过不下载音频数据或者通过丢弃下载的音频数据来抑制来自视频播放列表的音频。音频播放器1207和视频播放器1209在一个实施例中各自具有其自己的数据缓冲器，并且在一个实施例中各自具有其自己的下载模块。具体地，音频播放器1207耦合到音频数据缓冲器1215，而音频数据缓冲器1215进而又耦合到音频下载模块1219。音频下载模块1219可以是软件模块，该软件模块通过API引起在客户端设备中通过一个或多个网络接口1223（例如蜂窝电话调制解调器或WiFi无线电装置，等等）对音频数据的下载。一个或多个网络接口1223进而耦合到一个或多个网络1225，例如因特网，其也耦合到一个或多个存储并提供播放列表和内容的服务器1227。通过网络1225下载的音频数据被存储在音频数据缓冲器1215中，然后通过扬声器或其他换能器作为输出被提供给用户。视频下载模块1221引起通过一个或多个网络1225和通过网络接口1223从一个或多个服务器1227对视频数据的下载。下载的视频数据可被存储在视频数据缓冲器1217中，在该处其可被视频播放器或客户端设备的其他组件解码并处理以供在显示设备上显示。音频播放器1207和视频播放器1209可同时且独立地操作，从而使得可以通过在变体音频播放列表中的不同URL之间切换来在同一节目的不同音频内容之间切换音频内容；在一个实施例中此切换可独立于视频播放列表的回放执行。音频播放器1207和视频播放器1209可处理其各自的每个播放列表并且通过使用内容本身中或播放列表中的时间戳来同步回放。在一个实施例中，音频内容或关于音频内容的播放列表中涉及的时间戳可与视频内容或视频播放列表中的时间戳占据相同的时间段，从而使得音频和视频的回放同步。将会明白，音频播放器1207和视频播放器1209在一个实施例中保持跟踪电影时间或实际时间或者两者以允许在音频和视频的回放期间音频和视频的同步。

现在将结合图13来描述根据本发明的一个实施例的用于操作服务器的方法。将会明白，一个或多个服务器可执行图13中所示的每个操作；例如，一个服务器可执行图13中的所有操作，或者一个服务器可执行一个操作，而另一服务器执行其他操作。例如，一个服务器可提供变体播放列表，而另一服务器可在从变体播放列表中选择特定播放列表之后提供并发送在回放期间使用的音频或视频播放列表。在操作1301中，服务器可响应于对于节目的请求而发送变体播放列表，该变体播放列表可包含关于不同音频播放列表的URL并且可选地还包含关于一个或多个视频播放列表的URL。在操作1303中，同一服务器设备或另一服务器设备接收对所选的音频和视频播放列表的请求，并且在操作1305中发送该音频和/或视频播放列表。另外，同一服务器或不同的（一个或多个）服务器可响应来自在操作1305中发送的那些播放列表的请求以提供实际内容。

图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和/或IEEE802.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 Development Kit，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。

图14是图示在本发明的一些实施例中可使用的示范性API体系结构的框图。如图14中所示，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。虽然图14图示了单个API调用组件1830与API1820交互，但应当理解以与API调用组件1830不同的语言（或相同的语言）编写的其他API调用组件可使用API1820。

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

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

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

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

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

附录

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

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[RFC2119]中所述那样解释。

3.播放列表文件

3.1.简介

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

M3U播放列表是由个体行组成的文本文件。行可终止于单个LF字符或者CR字符后跟LF字符。每一行是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

该值是包含格式的逗号分隔列表的带引号字符串，其中每个格式指定在播放列表文件中的媒体文件中存在的媒体样本类型。有效格式标识符是由RFC4281[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]定义的存在于任何出现或将会出现在播放列表文件中的媒体文件中的每一个格式。

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

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

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

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

变体流中的匹配内容必须具有匹配的时间戳。这允许客户端同步流。

基本音频流文件必须通过在ID3PRIV标签[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.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.变体播放列表文件

#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来传送数据，所以大多数相同的安保考虑都是适用的。参见RFC2616[RFC2616]的第15节。

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

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

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

HTTP请求经常包括会话状态（“cookies”），该会话状态可包含私密用户数据。实现方式必须遵循RFC2965[RFC2965]规定的cookie限制和期满规则。另见RFC2965的“SecurityConsiderations”这一节，以及RFC2964[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),FIPS PUB197",November2001,<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/IEC InternationalStandard13818;Generic coding of moving pictures and associated audioinformation",October2007,<http://www.iso.org/iso/catalogue_detail?csnumber=44169>.

[ISO_8601]

International Organization for Standardization,"ISO/IEC InternationalStandard8601:2004;Data elements and interchange formats--Informationinterchange--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",BCP14,RFC2119,March1997.

[RFC2616]Fielding,R.,Gettys,J.,Mogul,J.,Frystyk,H.,Masinter,L.,Leach,P.,and T.Berners-Lee,"Hypertext Transfer Protocol--HTTP/1.1",RFC2616,June1999.

[RFC2964]Moore,K.and N.Freed,"Use of HTTP State Management",BCP44,RFC2964,October2000.

[RFC2965]Kristol,D.and L.Montulli,"HTTP State Management Mechanism",RFC2965,October2000.

[RFC3629]Yergeau,F.,"UTF-8,a transformation format of ISO10646",STD63,RFC3629,November2003.

[RFC3986]Berners-Lee,T.,Fielding,R.,and L.Masinter,"Uniform ResourceIdentifier(URI):Generic Syntax",STD66,RFC3986,January2005.

[RFC4281]Gellens,R.,Singer,D.,and P.Frojdh,"The Codecs Parameter for"Bucket"Media Types",RFC4281,November2005.

[RFC5246]Dierks,T.and E.Rescorla,"The Transport Layer Security(TLS)Protocol Version1.2",RFC5246,August2008.

[RFC5652]Housley,R.,"Cryptographic Message Syntax(CMS)",STD70,RFC5652,September2009.

[US_ASCII]

American National Standards Institute,"ANSI X3.4-1986,InformationSystems--Coded Character Sets7-Bit American National Standard Code forInformation Interchange(7-Bit ASCII)",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 (22)

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

用于响应于对于节目的请求接收关于所述节目的变体音频播放列表的装置，所述变体音频播放列表是在接收到对于所述节目的请求之前生成的，所述变体音频播放列表包含关于所述节目的不同音频内容的一组URL，所述一组URL中的每个URL涉及与所述节目的不同音频内容之一相对应的音频播放列表，所述一组URL中的URL涉及的每个音频播放列表包括一个或多个标签和多个统一资源标识符URI，所述URI指示多个音频文件从所述节目的不同音频内容的对应的音频内容划分出来的顺序以重建所述节目的音频内容；

用于选择所述一组URL中的关于所述不同音频内容之一的第一URL的装置，所述第一URL涉及第一播放列表；

用于发送涉及所述第一播放列表的所述第一URL的装置；

用于接收所述第一播放列表的装置；以及

用于处理所述第一播放列表以取回所述节目的音频内容的装置。

2.如权利要求1所述的系统，其中，所述系统还包括：

用于确定音频偏好的装置；并且

其中，对所述第一URL的选择是基于由用户偏好所设定的所述音频偏好的。

3.如权利要求2所述的系统，其中，所述系统还包括：

用于接收关于所述节目的视频播放列表的装置，所述视频播放列表包含关于所述节目的视频内容的URL，每个关于视频内容的URL涉及所述视频内容的时间上的一部分。

4.如权利要求3所述的系统，其中，所述系统还包括：

用于在所述变体音频播放列表中的关于音频内容的URL之间切换的装置，其中所述切换是独立于所述视频播放列表的回放执行的。

5.如权利要求4所述的系统，其中，所述第一播放列表和所述视频播放列表分别由第一软件组件和第二软件组件同时处理，其中所述第一软件组件取回所述第一播放列表中的URL所涉及的音频内容，并且所述第二软件组件取回所述视频播放列表中的URL所涉及的视频内容，并且所述第一软件组件和所述第二软件组件独立操作以取回其各自的内容。

6.如权利要求4所述的系统，其中，通过所述第一播放列表取回的音频内容中的时间戳和通过所述视频播放列表取回的视频内容中的时间戳指定相同时间段。

7.如权利要求4所述的系统，其中，所述一组URL中的每个URL涉及不同的音频内容，并且所述不同的音频内容中的每一个包括指定相同时间段的时间戳，并且所述变体音频播放列表和所述视频播放列表是响应于对所述节目的单个请求而接收的。

8.一种由机器实现的方法，包括：

响应于对节目的请求接收关于所述节目的变体音频播放列表，所述变体音频播放列表是在接收到对所述节目的请求之前生成的，所述变体音频播放列表包含关于所述节目的不同音频内容的一组URL，所述一组URL中的每个URL涉及与所述节目的不同音频内容之一相对应的音频播放列表，所述一组URL中的URL涉及的每个音频播放列表包括一个或多个标签和多个统一资源标识符URI，所述URI指示多个音频文件从所述节目的不同音频内容的对应的音频内容划分出来的顺序以重建所述节目的音频内容；

选择所述一组URL中的关于所述不同音频内容之一的第一URL，所述第一URL涉及第一播放列表；

发送涉及所述第一播放列表的所述第一URL；

接收所述第一播放列表；以及

处理所述第一播放列表以取回所述节目的音频内容。

9.如权利要求8所述的方法，其中，所述方法还包括：

确定音频偏好；并且

其中，对所述第一URL的选择是基于由用户偏好所设定的所述音频偏好的。

10.如权利要求9所述的方法，其中，所述方法还包括：

接收关于所述节目的视频播放列表，所述视频播放列表包含关于所述节目的视频内容的URL，每个关于视频内容的URL涉及所述视频内容的时间上的一部分。

11.如权利要求10所述的方法，其中，所述方法还包括：

在所述变体音频播放列表中的关于音频内容的URL之间切换，其中所述切换是独立于所述视频播放列表的回放执行的。

12.如权利要求11所述的方法，其中，所述第一播放列表和所述视频播放列表分别由第一软件组件和第二软件组件同时处理，其中所述第一软件组件取回所述第一播放列表中的URL所涉及的音频内容并且所述第二软件组件取回所述视频播放列表中的URL所涉及的视频内容，并且所述第一软件组件和所述第二软件组件独立操作以取回其各自的内容。

13.如权利要求11所述的方法，其中，通过所述第一播放列表取回的音频内容中的时间戳和通过所述视频播放列表取回的视频内容中的时间戳指定相同时间段。

14.如权利要求11所述的方法，其中，所述一组URL中的每个URL涉及不同的音频内容，并且所述不同的音频内容中的每一个包括指定相同时间段的时间戳，并且所述变体音频播放列表和所述视频播放列表是响应于对所述节目的单个请求而接收的。

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

用于响应于来自设备的对于节目的请求而发送变体音频播放列表的装置，所述变体音频播放列表包含关于所述节目的不同音频内容的一组URL，所述一组URL中的每个URL涉及与所述节目的不同音频内容之一相对应的音频播放列表，所述变体音频播放列表是在接收到对所述节目的请求之前生成的，所述一组URL中的URL涉及的每个音频播放列表包括一个或多个标签和多个统一资源标识符URI，所述URI指示多个音频文件从所述节目的不同音频内容的对应的音频内容划分出来的顺序以重建所述节目的音频内容；

用于从所述设备接收所述一组URL中的第一URL并且响应于接收到所述第一URL而向所述设备发送第一音频播放列表的装置，所述第一URL涉及所述第一音频播放列表。

16.如权利要求15所述的系统，其中，所述系统还包括：

用于响应于来自所述设备的所述请求，发送关于所述节目的视频播放列表的装置，所述视频播放列表包含关于所述节目的视频内容的URL，每个关于视频内容的URL涉及所述视频内容的时间上的一部分。

17.如权利要求16所述的系统，其中，所述系统还包括：

用于从所述设备接收所述一组URL中的关于不同音频内容的第二URL的装置；

用于响应于接收到所述第二URL而发送第二音频播放列表的装置，其中所述第二URL涉及所述第二音频播放列表并且所述第二音频播放列表提供所述节目的替换音频内容。

18.如权利要求17所述的系统，其中，通过所述第一音频播放列表取回的音频内容中的时间戳和所述替换音频内容中的时间戳指定相同时间段。

19.一种由机器实现的方法，包括：

响应于来自设备的对于节目的请求而发送变体音频播放列表，所述变体音频播放列表是在接收到对所述节目的请求之前生成的，所述变体音频播放列表包含关于所述节目的不同音频内容的一组URL，所述一组URL中的每个URL涉及与所述节目的不同音频内容之一相对应的音频播放列表，所述一组URL中的URL涉及的每个音频播放列表包括一个或多个标签和多个统一资源标识符URI，所述URI指示多个音频文件从所述节目的不同音频内容的对应的音频内容划分出来的顺序以重建所述节目的音频内容；

从所述设备接收所述一组URL中的第一URL并且响应于接收到所述第一URL而向所述设备发送第一音频播放列表，所述第一URL涉及所述第一音频播放列表。

20.如权利要求19所述的方法，其中，所述方法还包括：

响应于来自所述设备的所述请求，发送关于所述节目的视频播放列表，所述视频播放列表包含关于所述节目的视频内容的URL，每个关于视频内容的URL涉及所述视频内容的时间上的一部分。

21.如权利要求20所述的方法，其中，所述方法还包括：

从所述设备接收所述一组URL中的关于不同音频内容的第二URL；

响应于接收到所述第二URL而发送第二音频播放列表，其中所述第二URL涉及所述第二音频播放列表并且所述第二音频播放列表提供所述节目的替换音频内容。

22.如权利要求21所述的方法，其中，通过所述第一音频播放列表取回的音频内容中的时间戳和所述替换音频内容中的时间戳指定相同时间段。