CN102611701A

CN102611701A - 通过非流化协议流化多媒体数据的方法

Info

Publication number: CN102611701A
Application number: CN2012100476023A
Authority: CN
Inventors: D·彼得曼; 小W·梅; A·楚恩格; R·潘特斯; J·D·巴特森
Original assignee: Apple Computer Inc
Current assignee: Apple Inc
Priority date: 2008-12-31
Filing date: 2009-12-28
Publication date: 2012-07-25
Anticipated expiration: 2029-12-28
Also published as: EP3300372A2; KR101233582B1; BRPI0923917A2; JP5384664B2; AU2009335146B2; AU2009335146A1; SG172820A1; RU2011132008A; JP2012514276A; CN102308547A; JP5296859B2; KR101215232B1; BRPI0923917B1; CN102308547B; CA2748548C; RU2481720C2; EP3300372A3; EP2392112A2; KR20110102495A; EP3300372B1

Abstract

本发明涉及利用诸如HTTP兼容协议之类的传输协议实时或者接近实时流化内容的方法与设备。在一种实施例中，一种方法包括将代表基于连续时间的节目内容(例如，实况视频广播)的数据流分成多个不同的媒体文件，并生成具有多个标签和指示多个不同的媒体文件的呈现次序的统一资源指示符的播放列表文件。可以使所述多个媒体文件和播放列表文件用于传输到客户端设备，其中客户端设备可以利用播放列表文件检索媒体文件。

Description

通过非流化协议流化多媒体数据的方法

本申请是申请日为2009年12月28日、申请号为200980156253.5、发明名称为“通过非流化协议流化多媒体数据的方法”的发明专利申请的分案申请。

相关申请

本申请要求以下美国临时申请的申请日的权益：

(1)于2008年12月31日提交的申请No.61/142,110(代理人卷号P7437Z)；

(2)于2009年3月16日提交的申请No.61/160,693(代理人卷号P7437Z2)；

(3)于2009年3月17日提交的申请No.61/161,036(代理人卷号P7437Z3)；

(4)于2009年4月7日提交的申请No.61/167,524(代理人卷号P7437Z4)；

(5)于2009年9月8日提交的申请No.61/240,648(代理人卷号P7437Z5)；及

(6)于2009年12月21日提交的申请No.61/288,828(代理人卷号P7437Z6)。就其与本公开内容一致而言，所有这些美国临时申请都通过引用合并在此。

本美国专利申请与以下美国专利申请相关，其中每个申请都通过引用合并在此：

(1)于2009年6月5日提交且标题为“REAL-TIME OR NEARREAL-TIME STREAMING”的申请No.12/479,690(代理人卷号P7437US1)；

(2)于2009年6月5日提交且标题为“VARIANT STREAMS FORREAL-TIME OR NEAR REAL-TIME STREAMING”的申请No.12/479,698(代理人卷号P7437US2)；

(3)于2009年6月5日提交且标题为“UPDATABLEREAL-TIME OR NEAR REAL-TIME STREAMING”的申请No.12/479,732(代理人卷号P7437US3)；及

(4)于2009年6月5日提交且标题为“PLAYLISTS FORREAL-TIME OR NEAR REAL-TIME STREAMING”的申请No.12/479,735(代理人卷号P7437US4)。

技术领域

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

背景技术

内容的流化通常指恒定地从服务器设备发送并由客户端设备接收的多媒体内容。该内容通常在其正在被流化服务器传送的同时被呈现给终端用户。这个名称指媒体的传送方法，而不是媒体本身。

当前的流化服务通常需要专用服务器来向终端用户分发“实况”内容。在任何大规模部署中，这都会导致高成本，并且需要专业技能来设置和运行。这导致比期望的可用于流化的内容库少的内容库。

发明内容

在一个实施例中，服务器设备存储至少一部分要被流化的内容。该内容一般是基于时间的图象或音频(例如，声音或音乐)流或者二者兼有：基于时间的流的一个例子是电影，其中图象的次序和呈现是基于时间的，并且因此可以看作是基于时间的流。服务器包括分段器代理和索引器代理，所述分段器代理将要被流化的内容分解成要按照网络协议通过分组来发送的片段，所述索引器代理生成一个或多个可以方便客户端呈现分段的用户数据的播放列表文件的。客户端设备经网络与服务器设备(或者存储片段和播放列表并发送它们但不生成它们的另一个服务器)耦合。客户端设备具有组装器代理，所述组装器代理接收所述一个或多个播放列表文件并方便根据该一个或多个播放列表文件将分段的媒体文件恢复成内容。客户端设备还可以具有经该客户端设备的一个或多个输出部件而输出内容的输出生成器代理。

在一个实施例中，服务器设备获得要发送到客户端设备的数据。服务器设备利用分段器代理将要发送的数据分成多个媒体文件。该服务器设备还将所述多个片段作为多个单个媒体文件存储在存储器中。服务器设备还生成具有对所述多个媒体文件的引用的一个或多个播放列表文件。响应来自客户端设备的对数据的请求，该服务器设备(或者另一个服务器设备)经网络向客户端设备发送所述一个或多个播放列表文件和所述多个媒体文件的至少一个子集。多个媒体文件可以响应来自客户端设备的请求而利用非流化传输协议发送；所述协议可以是例如HTTP。

在一个实施例中，客户端设备可以接收并存储所述一个或多个播放列表文件。然后，客户端可以请求在播放列表文件(一个或多个)中所识别的分段媒体文件并下载链接的媒体文件。然后，该客户端设备(或者另一个客户端设备)可以生成代表该内容流的音频和/或视频输出。

在一个实施例中，更新的播放列表可以由服务器动态生成，然后由客户端检索。更新的播放列表除包括原始播放列表中的节目之外，还可以包括所显示的辅助材料(例如，小工具条(sidebar)用户界面中的广告、相关内容、可选版本，等等)，或者更新的播放列表可以包括节目的附加部分(例如，除在原始播放列表中识别的第一半之外的节目的后一半)。在一种实现中，服务器可以使用在此所述的滚动方法，来更新随后作为更新播放列表由客户端检索的播放列表。

在一个实施例中，播放列表可以指定代表相同内容的多个可选的流；这些可选的流可以是以不同的视觉分辨率发送(并由此以不同的位速率发送)或者具有其它不同属性的同一节目。服务器可以生成多个播放列表，每个可选的流一个播放列表，而且可以生成指出或者以别的方式指定可选流的变体播放列表。然后，该服务器(或者另一个服务器)可以将该变体播放列表发送到客户端设备，而且客户端设备可以根据当前的网络条件(例如，用于传输媒体文件的网络的当前吞吐率)决定从变体播放列表中选择哪个播放列表，而且客户端设备可以下载所选的播放列表(并进一步下载由该所选播放列表指定的媒体文件)。

在一个实施例中，客户端设备可以在接收并呈现内容的同时从变体播放列表中的第一播放列表切换到该变体播放列表中的第二播放列表。例如，客户端设备可以利用第一播放列表和第一位速率接收节目，并且可以通过对网络吞吐率的测量确定它可以以更高的第二位速率接收同一节目的内容，其中该内容是由第二播放列表指定的。在这种情况下，客户端设备可以在继续呈现由第一播放列表指定的内容的同时请求第二播放列表，接收该第二播放列表并开始检索在该第二播放列表中指定的媒体文件。客户端设备可以在缓冲器中存储这两个播放列表的媒体文件和所得到的解压内容，而且客户端设备可以执行确定何时和如何在内容的两个版本之间切换或过渡的自动操作。例如，客户端设备可以利用内容的两个版本中音频内容的模式匹配来找出两个版本中的匹配点，然后在识别出来自第二播放列表的新内容中的过渡之后进行切换。

在一个实施例中，一种方法包括利用可选的流提供用于向客户端设备提供媒体内容的多个冗余位置。为了实现故障转移保护，第一服务器设备或者第一内容分发服务产生流或者多个可选的带宽流并生成播放列表文件(一个或多个)。第二服务器设备或者第二内容分发服务产生并行流或者流的集合。客户端尝试利用与第一服务器设备或者第一内容分发服务关联的第一流从第一统一资源定位符(URL)下载播放列表(一个或多个)。如果客户端不能够从第一URL下载播放列表(一个或多个)，则客户端尝试切换到与另一个URL关联的可选流。

在一个实施例中，一种方法包括提供对播放列表的请求并在请求中指定播放列表可以被压缩，并且，如果服务器可以提供压缩形式的播放列表的话，就响应该请求而接收压缩形式的播放列表(否则，播放列表可以由服务器以非压缩格式提供)。播放列表可以利用由现有HTTP标准压缩技术所支持的压缩技术或格式，例如deflate或gzip，来压缩(也称为编码)。压缩格式的播放列表的发送和接收可以显著减少所发送和接收的数据大小，尤其是当播放列表随着时间而增长时(例如，播放列表是用于长时间的棒球比赛)。在一个实施例中，对播放列表使用压缩对于客户端(请求播放列表的系统)和服务器(通过发送播放列表来响应请求的系统)可以都是可选的。作为HTTP标准一部分的压缩技术或格式的使用允许任何兼容的网络服务器都能够支持压缩的播放列表，而且任何兼容的客户端也都将能够解压和使用该播放列表。

附图说明

在附图中，本发明是通过例子但不是作为限制来说明的，其中附图中相似的标号指类似的元件。

图1是可以发送和接收实时或者接近实时的内容的服务器和客户端的一种实施方式的框图。

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

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

图2C是让一个或多个服务器设备利用多个位速率向客户端设备提供媒体内容的技术的一种实施方式的流程图。

图3A是让客户端设备利用非流化协议支持内容的流化的技术的一种实施方式的流程图。

图3B是让客户端设备利用多个位速率支持内容的流化的技术的一种实施方式的流程图。

图4是服务器流代理的一种实施方式的框图。

图5是客户端流代理的一种实施方式的框图。

图6说明了具有多个标签的播放列表文件的一种实施方式。

图7是在此所述的用于组装流的重放技术的一种实施方式的流程图。

图8是电子系统的一种实施方式的流程图。

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

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

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

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

图10是用于提供多个冗余位置的技术的一种实施方式的流程图，其中多个冗余位置用于利用可选的流向客户端设备提供媒体内容。

图11说明了根据一种实施方式的一种网络，其中客户端1102与一个或多个URL双向通信。

具体实施方式

在以下描述中，阐述了各种特定细节。但是，本发明的实施例可以没有这些特定细节来实践。在其它情况下，为了不模糊对本发明描述的理解，众所周知的电路、结构和技术没有被具体示出。

在一个实施例中，在此所述的技术和部件可以包括用于利用非流化协议(例如，HTTP)和其它技术(例如，运动图片专家组(MPEG)流)传送流化体验的机制。例如，接近实时的流化体验可以利用HTTP来提供，以便广播“实况”音乐或体育赛事、实况新闻、网络照相机反馈等等。在一个实施例中，一种协议可以将进入的媒体数据分成多个媒体文件并将那些分段的媒体文件存储在服务器上。该协议还可以构建包括统一资源标识符(URI)的播放列表文件，该URI将客户端指引到存储在服务器上的分段媒体文件。当分段的媒体文件根据播放列表文件(一个或多个)被重放时，客户端可以为用户提供“实况”事件的接近实时的广播。预先记录的内容可以以类似的方式提供。

在一个实施例中，服务器可以动态地将辅助的或者可选的媒体内容(例如，广告、关于体育赛事的统计数据、到主要呈现的附加媒体内容)引入到广播事件。例如，在客户端重放媒体事件时，服务器可以向播放列表文件添加附加的URI，该URI可以识别客户端可以从其下载辅助媒体文件的位置。可以指示客户端周期性地从服务器检索一个或多个更新的播放列表文件(一个或多个)，以便访问该服务器已经引入的任何辅助或附加(或者两者兼有)的媒体内容。

在一种实施例中，服务器可以累积模式或者滚动模式运行。在累积模式，服务器可以创建播放列表文件并将媒体文件标识符附加到该播放列表文件的末端。然后，当下载时，客户端根据单个播放列表文件访问流的所有部分(例如，用户可以在演出的中间开始)。在滚动模式，服务器可以通过根据滚动从播放列表文件的开始去除媒体文件标识符来限制媒体文件的可用性，由此提供客户端设备可访问的媒体内容的滑动窗口。在滚动模式，服务器也可以向播放列表末端添加媒体文件标识符而且服务器可以将媒体文件的可用性限制到那些最近被添加到播放列表的媒体文件。然后，客户端重复地下载播放列表文件的更新拷贝，来继续观看。当内容的时间潜在地不受限制的时候(例如，来自持续运行的网络照相机的内容)，用于播放列表下载的滚动基础可以是有用的。在滚动模式，客户可以持续重复地请求播放列表，直到找到播放列表中的结束标签。

在一种实施例中，通过提供同一呈现的变体流，该机制支持位速率切换。例如，要提供的呈现的几个版本可以存储在服务器上。每个版本都可以具有基本上相同但是以不同的位速率编码的内容。这可以允许客户端设备依赖于例如可用带宽的检测而在位速率之间切换，而不危及重放的持续性。

在一种实施例中，可以提供用于保护内容不被未授权使用的保护特征。例如，非连续的媒体文件编号可以用于防止预测。可以使用媒体文件的加密。可以使用部分媒体文件列表。附加的和/或不同的保护特征也可以被提供。

图1是可以发送和接收实时或者接近实时的内容的服务器和客户端的一种实施方式的框图。图1的例子提供了简单的服务器-客户端连接，两个客户端经网络与服务器耦合。利用在此所述的技术和机制，可以支持任何数量的客户端。此外，根据在此所述的技术和机制，多个服务器可以提供内容和/或可以一起操作来提供内容。例如，一个服务器可以创建内容、创建播放列表并创建多个媒体(例如，文件)，而其它服务器存储并发送所创建的内容。

网络110可以是任何类型的网络，有线的、无线的(例如，IEEE802.11、802.16)或者其任意组合。例如，网络110可以是互联网或者内联网。作为另一个例子，网络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。服务器120还可以包括未在图1中说明的附加部件。

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

客户端设备150可以包括组装器代理160和输出生成器代理165。类似地，客户端设备180可以包括组装器代理190和输出生成器代理195。组装器代理160和190从服务器120接收播放列表文件并使用该播放列表文件来从服务器120访问和下载媒体文件。输出生成器代理165和195使用下载的媒体文件分别从客户端设备150和160生成输出。输出可以由一个或多个扬声器、一个或多个显示器屏幕、扬声器和显示器屏幕的组合或者任何其它输入或输出设备来提供。客户端设备还可以包括存储器(例如，闪存存储器或者DRAM，等等)，其在接收到媒体文件的时候充当存储该媒体文件(例如，压缩的媒体文件或解压的媒体文件)的缓冲器；缓冲器还可以提供超出当前所呈现内容的时间许多秒的可呈现内容，以使得缓冲的内容可以随后在下载新内容的同时被显示。这种缓冲可以在客户端设备正尝试通过断断续续的慢速网络连接来检索内容的同时提供可呈现的内容，由此该缓冲可以隐藏网络等待时间或者连接问题。

客户端设备150和180还可以包括可选的安全代理170和185，其分别提供在此所讨论的安全功能中的一个或多个。客户端设备150和180还可以包括未在图1中说明的附加部件。

在一种实施例中，本申请中所述的技术可以用于经非流化协议(例如，HTTP)发送无限制的多媒体数据流。各实施例还可以包括媒体数据的加密和/或流的可选版本的提供(例如，提供交替的位速率)。因为媒体数据可以在创建之后很快被发送，所以数据可以接近实时地被接收。提供了用于文件及要由多媒体数据流的服务器(发送者)和客户端(接收者)所采取的动作的示例数据格式；但是，也可以支持其它格式。

可以作为模拟的实时流(或者接近实时的流)发送的媒体呈现是由指示播放列表文件的统一资源指示符(URI)指定的。在一种实施例中，播放列表文件是附加URI的有序列表。播放列表文件中的每个URI指作为流的一个片段的媒体文件，其中流可以是用于特定节目的媒体数据的单个连续流。

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

播放列表文件可以是例如扩展M3U播放列表文件。在一种实施例中，可以使用有效地扩展M3U格式的附加标签。M3U指运动图片专家组音频层3统一资源定位符(MP3URL)而且是一种用于存储多媒体播放列表的格式。M3U文件是包含让媒体播放器播放的一个或多个媒体文件的位置的文本文件。

在一种实施例中，播放列表文件是包括多个单行的扩展M3U格式文本文件。这些行可以由单个LF字符或者由CR字符后面跟着LF字符来终止。每一行都可以是URI、空行或者以注释字符(例如，“#”)开始。URI识别要播放的媒体文件。空行可以被忽略。

以注释字符开始的行可以是注释或者是标签。标签可以以#EXT开始，而注释行可以以#开始。注释行通常被服务器和客户端忽略。在一种实施例中，播放列表文件是以UTF-8格式编码的。UTF-8(8位Unicode变换格式)是一种可变长度的字符编码格式。在可选实施例中，可以使用其它字符编码格式。

在以下的例子中，使用包括两个标签EXTM3U和EXTINF的扩展M3U格式。扩展M3U文件可以通过包括“#EXTM3U”的第一行而与基本M3U文件区分开。

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

#EXTINF：<持续时间>、<标题>其中，“持续时间”指示媒体文件的持续时间，而“标题”是目标媒体文件的标题。

在一种实施例中，以下标签可以用于管理媒体文件的传输和重放：

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：<秒>

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

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

#EXT-X-MEDIA-SEQUENCE：<编号>

其中，“编号”是URI的序列号。如果播放列表文件不包括#EXT-X-MEDIA-SEQUENCE标签，则播放列表中第一个URI的序列号可以认为是1。在一种实施例中，序列号可以不是顺序的；例如，诸如1、5、7、17等的非顺序的序列号会使得难以预测序列中的下一个编号，这有助于保护内容不被盗取。帮助保护内容的另一个选项是在任何给定时候都只显示播放列表的部分。

有些媒体文件可以被加密。EXT-X-KEY标签提供了可以用于解密跟在其后面的媒体文件的信息，而且其格式可以是：

#EXT-X-KEY:METHOD＝<方法>[，URI＝″<URI>″]。

METHOD参数指示加密方法，而URI参数，如果存在的话，指示如何获得密钥。

为NONE的加密方法指示没有加密。各种加密方法都可以使用，例如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：[属性＝值][，属性＝值]＊<URI>

其中可以使用以下属性。属性BANDWIDTH＝<n>是表示为每秒位数的流位速率的大致上限。属性PROGRAM-ID＝<i>是唯一地识别播放列表文件范围中的特定呈现的编号。播放列表文件可以包括多个具有相同PROGRAM-ID的EXT-X-STREAM-INF URI，用来描述相同呈现的变体流。变体流和变体播放列表在本公开内容中被进一步描述(例如，见图9A-9D)。

前面所述的标签和属性可以由服务器设备用于组织、发送和处理代表原始媒体内容的媒体文件。客户端设备使用这种信息重新组装并以向客户端设备的用户提供实时或者接近实时的流化体验(例如，观看诸如音乐或体育赛事的实况广播)的方式呈现该媒体文件。

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

图2A是让一个或多个服务器设备利用非流化协议支持媒体内容的技术的一种实施方式的流程图。图2A的例子是关于HTTP提供的；但是，其它非流化协议也可以以类似的方式使用。图2A的例子是关于执行某些任务的单个服务器提供的。但是，都可以使用任何个数的服务器。例如，向客户端设备提供媒体文件的服务器可以是与将内容分成多个媒体文件的服务器不同的设备。

在操作200中，服务器设备接收要提供的内容。该内容可以代表实况音频和/或视频(例如，体育赛事、实况新闻、网络照相机馈送)。内容还可以代表预先录制的内容(例如，已经录制的音乐会、培训会议，等等)。内容可以由服务器根据本领域中已知的任何格式和协议——流化或者未流化——来接收。在一种实施例中，内容是由服务器以MPEG-2流的形式接收的；但是，也可以支持其它格式。

然后，在操作210中，服务器可以临时存储至少部分内容。内容或者内容的至少部分可以临时存储在例如存储设备(例如，存储区域网络中的硬盘，等等)上或者内存中。可选地，内容可以经存储介质(例如，光盘、闪存驱动器)接收，其中内容可以从该存储介质传送到存储设备或者内存。在一种实施例中，服务器具有编码器，如果必要的话，该编码器将内容转换成一个或多个流(例如，MPEG-2)。这种转换可以在不永久性存储所接收内容的情况下发生，而且，在有些实施例中，存储操作210可以被忽略或者在其它实施例中可以是更长期的存储(例如，归档存储)。

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

因为片段是利用固有地传送整个文件的HTTP服务器提供的，所以该服务器应当具有在可以被提供给客户端之前可用的完整的分段媒体文件。因此，客户端可以(在时间上)推后广播至少一个媒体文件的长度。在一种实施例中，媒体文件的大小是基于推后时间和具有太多文件之间的平衡。

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

在操作230中，媒体文件存储在服务器的内存中。在操作230中存储文件之前，媒体文件可以由安全特征(诸如加密)保护。媒体文件被存储为准备好利用由服务器设备上网络服务器应用所支持的(或者由进行传输的另一个设备支持的)网络协议(例如，HTTP或者HTTPS)发送的文件。

在操作240中，生成一个或多个播放列表文件以指示为了重建原始内容应当按其组装媒体文件的次序。播放列表文件(一个或多个)可以利用扩展M3U标签和在此所述的标签来为客户端设备提供访问和重新组装媒体文件以便在客户端设备上提供流化体验的信息。用于每个媒体文件的URI以媒体文件要被播放的次序而被包括在播放列表文件(一个或多个)中。服务器还可以创建用于播放列表(一个或多个)的一个或多个URI，以便允许客户端设备访问播放列表文件(一个或多个)。

在操作250中，播放列表文件(一个或多个)可以被存储在服务器上。尽管在图2A中媒体文件和播放列表文件(一个或多个)的创建与存储是以特定次序给出的，但是也可以使用不同的次序。例如，播放列表文件(一个或多个)可以在媒体文件被创建或存储之前被创建。作为另一个例子，播放列表文件(一个或多个)和媒体文件可以在任何一方被存储之前被创建。

如果媒体文件要加密，则播放列表文件(一个或多个)可以定义允许授权客户端设备获得包含用于解密媒体文件的加密密钥的密钥文件的URI。加密密钥可以利用安全连接(例如，HTTPS)发送。作为另一个例子，播放列表文件(一个或多个)可以利用HTTPS发送。作为再一个例子，媒体文件可以以不可预测的次序排列，以使得客户端在没有播放列表文件(一个或多个)的情况下不能重建流。

如果加密方法是AES-128，则例如AES-128 CBC加密可以应用到单个的媒体文件。在一种实施例中，整个文件都加密了。在一种实施例中，通常不跨媒体文件应用密码块链。如上所述，媒体文件的序列用作IV。在一种实施例中，服务器将具有密钥URI的EXT-X-KEY标签添加到播放列表文件的末端。然后，服务器利用那个密钥加密所有后续的媒体文件，直到对加密配置进行了改变。

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

为了结束加密，服务器可以将具有加密方法NONE的EXT-X-KEY标签添加到播放列表文件的末端。在一种实施例中，该标签(具有“NONE”作为方法)不包括URI参数。所有后续的媒体文件都不加密，直到如上所述对加密配置进行了改变。如果播放列表文件包含到利用那个密钥加密的媒体文件的URI，则服务器不从播放列表文件中去除EXT-X-KEY标签。在操作270中，服务器可以响应客户端请求而在网络上发送播放列表文件(一个或多个)和媒体文件，如参考图3A更具体描述的那样。

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

在一种实施例中，服务器可以将媒体文件的可用性限定到那些最近添加到播放列表文件(一个或多个)的媒体文件。为此，每个播放列表文件都可以只包括一个EXT-X-MEDIA-SEQUENCE标签而且对于从播放列表文件中去除的每个媒体文件URI，值可以递增一。媒体文件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中被再次存储。从客户端设备的角度，应当极小地(atomically)进行播放列表文件(一个或多个)的改变。在一种实施例中，更新后的播放列表代替先前的播放列表。如以下更具体讨论的，客户端设备可以多次请求播放列表。这些请求使客户端设备能够利用最近的播放列表。在一种实施例中，附加数据可以是元数据；在这种情况下，播放列表不需要更新，但是片段可以被更新以包括元数据。例如，元数据可以包含可以与片段中的时间戳匹配的时间戳，而且元数据可以被添加到具有匹配时间戳的片段。

更新后的播放列表还可能导致媒体文件的去除。在一种实施例中，服务器应当以媒体文件被添加到播放列表中的次序从播放列表去除用于媒体文件的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、IEEE 802.16)或者蜂窝电话网络(例如，3G)。

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

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

该组装器使得来自播放列表文件的媒体文件从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-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。

如果要播放的第一个媒体文件已经被加载而且播放列表文件包含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，而第二服务器设备可以包括文件服务器460而没有分段器430、索引器440和安全部件450。在这个例子中，第一服务器设备将准备播放列表和媒体文件但是不将它们发送到客户端设备，而一个或多个第二服务器设备将接收并可选地存储播放列表和媒体文件并将该播放列表和媒体文件发送到客户端设备。服务器流代理400包括控制逻辑410，其实现指示服务器流代理400操作的逻辑功能控制，和与指示服务器流代理400操作关联的硬件。逻辑可以是硬件逻辑电路或者软件例程或者固件。在一种实施例中，服务器流代理400包括一个或多个应用412，这些应用412代表提供指令给控制逻辑410的代码序列和/或程序。

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

服务器流代理400还可以包括服务器流引擎420，该引擎420代表使服务器流代理400能够提供如在此所述的实时或者接近实时的流化的一个或多个功能。图4的例子提供了可以包括在服务器流引擎420中的几个部件；但是，也可以包括不同的或者附加的部件。在提供流化环境中可能涉及到的示例部件包括分段器430、索引器440、安全部件450和文件服务器460。这些部件中的每一个都可以进一步包括提供其它功能的其它部件。如在此所使用的，部件指例程、子系统等，不管其是以硬件、软件、固件还是其某种组合实现的。

分段器430将要提供的内容分成可以作为文件利用网络服务器协议(例如，HTTP)发送的媒体文件。例如，分段器430可以将内容以预定的文件格式分成预定的固定大小的数据块。

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

安全部件450可以提供诸如以上所讨论的那些的安全特征(例如，加密)。网络服务器460可以提供关于向远端客户端设备提供主机系统上所存储的文件的网络服务器功能。网络服务器460可以支持例如HTTP兼容协议。

图5是客户端流代理的一种实施方式的框图。应当理解，客户端流代理的元件可以分布在几个客户端设备上。例如，第一客户端设备可以包括组装器530和安全部件550而且可以向第二客户端设备提供解密的媒体文件流，而第二客户端设备包括输出生成器540(但不包括组装器530和安全部件550)。在另一个例子中，主客户端设备可以检索播放列表并将它们提供给次客户端设备，而次客户端设备可以检索在播放列表中指定的媒体文件并生成呈现这些媒体文件的输出。客户端流代理500包括控制逻辑510，其实现指示客户端流代理500操作的逻辑功能性控制，和与指示客户端流代理500操作关联的硬件。逻辑可以是硬件逻辑电路或者软件例程或者固件。在一种实施例中，客户端流代理500包括一个或多个应用512，这些应用512代表提供指令给控制逻辑510的代码序列或者程序。

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

客户端流代理500还可以包括客户端流引擎520，该引擎代表使客户端流代理500能够提供如在此所述的实时或者接近实时的流化的一个或多个功能。图5的例子提供了可以包括在客户端流引擎520中的几个部件；但是，也可以包括不同的或者附加的部件。在提供流化环境中可能涉及到的示例部件包括组装器530、输出生成器540和安全部件550。这些部件中的每一个都可以进一步包括提供其它功能的其它部件。如在此所使用的，部件指例程、子系统等，不管其是以硬件、软件、固件还是其某种组合实现的。

组装器530可以利用从服务器接收的播放列表文件来经网络服务器协议(例如，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中检索并存储由第二个媒体播放列表指定的内容(例如，第二个流)。在呈现从第一个媒体播放列表所获得的内容的同时由第二个媒体播放列表所指定的内容(例如，在临时缓冲器中的内容)的检索和存储创建了节目内容在时间上的重叠(图9D中所示)，这允许客户端设备在节目的版本之间进行切换，而没有节目的实质性中断。以这种方式，节目版本之间的切换可以在许多情况下实现，而用户不会注意到切换已经发生了(尽管在有些情况下用户可能注意到在切换之后分辨率更高的图象)或者而没有节目的呈现中的实质性中断。在操作927中，客户端设备确定了过渡点，在这个点从由第一个媒体播放列表指定的内容切换到由第二个媒体播放列表指定的内容；过渡点的例子(过渡点959)在图9D中示出。然后，在切换之后，由第二个媒体播放列表指定的内容在操作931中被呈现。

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

图10是用于提供多个冗余位置的技术的一种实施方式的流程图，其中多个冗余位置用于利用可选的流向客户端设备提供播放列表或媒体内容或这二者。如果播放列表包含如上所讨论的可选流，则该可选流可以不仅操作作为带宽或者设备替换物，而且可以操作作为故障降级(failure fallback)。例如，如果客户端不能重新加载用于流的播放列表文件(例如，由于404错误或者网络连接错误)，则客户端可以尝试切换到该可选的流。参考图10，为了实现故障保护，第一服务器设备或者第一内容分发服务被配置成在操作1002中创建流或者多个可选带宽流，如结合图2C的描述所讨论过的。在操作1004，第一服务器设备或者第一内容分发服务根据操作1002中生成的流(一个或多个)，生成播放列表文件(一个或多个)。在操作1006中，第二服务器设备或者第二内容分发服务可以创建并行的流或者流的集合，并且也创建播放列表。这些并行的流(一个或多个)可以看作备份流。接下来，在操作1008中，备份流的列表被加到播放列表文件(一个或多个)，因此，每个带宽的备份流(一个或多个)都在主流之后被列出。例如，如果主流来自服务器ALPHA而备份流在服务器BETA上，则播放列表文件可能如下所示：

#EXTM3U

#EXT-X-STREAM-INF:PROGRAM-ID＝1，BANDWIDTH＝200000

http://ALPHA.mycompany.com/low/prog index.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID＝1，BANDWIDTH＝200000

http://BETA.mycompany.com/low/prog index.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID＝1，BANDWIDTH＝500000

http://ALPHA.mycompany.com/mid/prog index.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID＝1，BANDWIDTH＝500000

http://BETA.mycompany.com/mid/prog index.m3u8

应当指出，备份流在播放列表中与主流混合在一起，每个带宽的备份都在该带宽的主流之后被列出。客户端不限于单个备份流集合。例如，在以上的例子中，ALPHA和BETA后面可以跟着GAMMA。类似地，不一定要提供完整的并行流集合。例如，可以在备份服务器上提供单个低带宽流。

在操作1010中，客户端尝试从第一个URL利用与第一服务器设备或者第一内容分发服务关联的第一个流下载播放列表文件(一个或多个)。图11说明了根据一种实施方式的一种网络，其中客户端1102与一个或多个URL、服务器设备或内容分发服务双向通信。在操作1012中，播放列表文件(一个或多个)可以从第一个URL、服务器设备或者内容分发服务发送到客户端1102。如果客户端不能够从第一个URL、服务器设备或者内容分发服务下载播放列表文件(一个或多个)(例如，由于重新加载用于流的索引文件时的错误)，则客户端尝试切换到可选的流。在一个流发生故障(例如，索引加载故障)(例如，操作1010)的情况下，客户端在操作1014中选择网络连接支持的最高带宽的可选流。如果在相同的带宽上有多个可选流，则客户端以播放列表中所列出的次序在它们中间进行选择。例如，如果客户端1102不能成功地从URL 1下载，则它可以从URL 2或者另一个URL下载，在这种情况下，将播放列表文件(一个或多个)从该可选的URL发送到客户端。这个特征提供了冗余流，这就允许即使在严重本地故障，诸如服务器崩溃或者内容分发节点停机，的情况下媒体也能到达客户端。

故障保护提供了提供多个冗余位置的能力，客户端可以从这些位置检索播放列表和媒体文件。因此，如果客户端不能从第一个位置检索到流，它就可以尝试从次级、第三级等的位置访问流。

在一种实施例中，为了指示客户端可以从其检索播放列表的附加位置，将为相同的变体播放列表标签提供相同的带宽，但提供冗余位置的新URI。客户端最初可以尝试访问与期望带宽关联的第一URL。如果它不能从该第一URL下载播放列表，它就可尝试访问为该带宽给出的下一个URL，等等，直到其耗尽了所有的可能性。

以下例子包括用于2560000带宽的1个冗余位置和用于7680000带宽的2个冗余位置。

#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＝2560000

http://example1.com/mid-redundant2.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID＝1，BANDWIDTH＝7680000

http://example.com/hi.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID＝1，BANDWIDTH＝7680000

http://example2.com/hi-redudant2.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID＝1，BANDWIDTH＝7680000

http://example3.com/hi-redudant3.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID＝1，BANDWIDTH＝65000，CODECS＝″mp4a.40.5″

http://example.com/audio-only.m3u8

应当指出，在这个例子中，文件名(例如，mid-redundant2.m3u8)和实际的URL(例如，http://example2.com<http://example2.com/>，http://example3.com<http://example3.com/>)都可以改变。但是，在一种实施例中，冗余位置可以只对文件名或者只对网址进行改变。

在一种实施例中，播放列表可以由服务器设备压缩并以压缩形式发送到客户端设备。压缩的播放列表比未压缩的播放列表通常需要更少的用来表示播放列表的位，而且因此，当被发送或接收时，压缩的播放列表使用更少的诸如无线蜂窝电话网络之类的网络的可用带宽。在一种实施例中，播放列表可以由网络服务器根据内置的压缩技术或者网络服务器使用的工具来压缩，其中该压缩技术与诸如HTTP 1.1标准协议之类的传输协议兼容或者可以与其兼容；这种压缩技术或者工具的例子是HTTP 1.1的deflate或者gzip压缩工具。基于其它标准的、作为基于标准的传输协议的一部分的压缩工具可以在其它实施例中使用。在一种实施例中，压缩的播放列表的使用可以是服务器设备和客户端设备的可选特征。在一种实施例中，播放列表可以是文本内容(例如，文本文件)，而且可以由基于标准的网络服务器利用deflate或者gzip来有效地压缩，然后由客户端设备自动解压。一个版本的gzip压缩工具的描述可以在www.ietf.org/rfc/rfc1952.txt找到；一个版本的deflate压缩工具可以在www.ietf.org/rfc/rfc1951.txt找到。许多网络服务器和客户端设备上的许多网络浏览器都可以自动地支持deflate或者gzip工具。

在一种实施例中，客户端设备可以周期性地请求更新的播放列表；例如，客户端可以每几秒钟(例如，每10、20或者30秒或者某个其它时段)从服务器请求更新的播放列表。不断增长的播放列表，诸如用于正在实况进行的棒球比赛的播放列表，可能变得足够大而使得当不断增长的播放列表通过网络重复发送时压缩的使用可以限制网络带宽的消耗，其中不断增长的播放列表允许客户在实况比赛期间的任何时刻从实况比赛的开始观看。

在一种实施例中，客户端设备可以可选地在其请求播放列表(诸如更新的播放列表)时指定它可以支持什么压缩技术(诸如deflate或者gzip)；对这些技术的支持意味着客户端设备可以解压或者解码压缩或者编码的内容。带有对压缩技术的可选指定的客户端设备对播放列表的请求由网络服务器接收，在一种实施例中，该网络服务器不需要支持用于播放列表的压缩技术而是可以发送未压缩的播放列表。网络服务器可以通过向客户端设备发送未压缩的播放列表或者利用在客户端设备对播放列表的请求中所指定的压缩技术之一压缩的播放列表来响应客户端设备的请求。客户端设备接收该播放列表并如在此所述的那样使用它；如果该播放列表是压缩的，则在客户端设备上利用解码器(诸如，客户端设备上网络浏览器中的解码器)来解码。

图8是电子系统的一种实施方式的框图。图8中所说明的电子系统是要代表一个范围内的电子系统(有线的或者无线的)，包括例如桌面计算机系统、膝上计算机系统、蜂窝电话、包括蜂窝使能的PDA在内的个人数字助理(PDA)、机顶盒、娱乐系统或者其它消费电子设备。可选的电子系统可以包括更多、更少和/或不同的部件。图8的电子系统可以用于提供客户端设备和/或服务器设备。

电子系统800包括总线805或者用于传送信息的其它通信设备及耦合到总线805的可以处理信息的处理器810。尽管电子系统800被说明为具有单个处理器，但是电子系统800也可以包括多个处理器和/或协处理器。电子系统800还可以包括耦合到总线805并且可以存储信息和可以由处理器810执行的指令的随机存取存储器(RAM)或者其它动态存储设备820(称为主存储器)。主存储器820还可以用于存储临时变量或者处理器810执行指令过程中的其它中间信息。

电子系统800还可以包括耦合到总线805的可以存储静态信息和用于处理器810的指令的只读存储器(ROM)和/或其它静态存储设备830。数据存储设备840可以耦合到总线805，来存储信息和指令。诸如闪存存储器或者磁盘或者光盘的数据存储设备840及对应的驱动器可以耦合到电子系统800。

电子系统800还可以经总线805耦合到显示设备850，诸如阴极射线管(CRT)或者液晶显示器(LCD)，来向用户显示信息。电子系统800还可以包括字母数字输入设备860，其包括字母数字和其它键，该输入设备860可以耦合到总线805，以便向处理器810传送信息和命令选择。另一种类型的用户输入设备是光标控制部件870，诸如触摸板、鼠标、轨迹球或者光标方向键，用来向处理器810传送方向信息和命令选择并控制显示器850上的光标运动。

电子系统800还可以包括一个或多个网络接口880，来提供对诸如局域网之类的网络的访问。网络接口(一个或多个)880可以包括例如具有天线885的无线网络接口，其中天线885可以代表一个或多个天线。电子系统800可以包括多个无线网络接口，诸如WiFi、蓝牙和蜂窝电话接口的组合。网络接口(一个或多个)880还可以包括例如有线网络接口，以便经网络电缆887与远端设备通信，其中网络电缆887可以是例如以太电缆、同轴电缆、光纤电缆、串行电缆或者并行电缆。

在一种实施例中，例如通过遵循IEEE 802.11b和/或IEEE 802.11g标准，网络接口(一个或多个)880可以提供对局域网的访问，和/或例如通过遵循蓝牙标准，无线网络接口可以提供对私域网的访问。也可以支持其它无线网络接口和/或协议。

除经无线LAN标准的通信之外或者代替该通信，网络接口(一个或多个)880可以利用例如时分多址(TDMA)协议、全球移动通信系统(GSM)协议、码分多址(CDMA)协议和/或其它类型的无线通信协议来提供无线通信。

本说明书中对“一种实施例”或者“实施例”的引用意味着结合该实施例所描述的特定特征、结构或者特性包括在本发明的至少一种实施例中。本说明书各个位置出现的术语“在一种实施例中”不一定全指的是同一实施例。

在以上的说明中，已经参考本发明的特定实施例描述本发明。但是，很显然，在不背离本发明更广泛的主旨与范围的情况下，可以对其进行各种修改与变化。说明书与附图相应地应该从说明性的意义而不是约束性的意义上看待。

附录

以下附录是根据本发明的特定实施方式的协议的草稿规范。应当理解，本附录中某些关键词(例如，必须、不准、将、不将，等等)的使用适用于这种特定实施方式而不适用于本公开内容中所描述的其它实施方式。

摘要

本文档描述了用于经由HTTP发送无限制的多媒体数据流的一种协议。它规定了文件的数据格式和流的服务器(发送方)与客户端(接收方)要采取的动作。本文档描述了这种协议的1.0版本。

内容列表

1.介绍

2.概述

3.播放列表文件

3.1新标签

3.1.1 EXT-X-TARGETDURATION

3.1.2 EXT-X-MEDIA-SEQUENCE

3.1.3 EXT-X-KEY

3.1.4 EXT-X-PROGRAM-DATE-TIME

3.1.5 EXT-X-ALLOW-CACHE

3.1.6 EXT-X-ENDLIST

3.1.7 EXT-X-STREAM-INF

3.1.8 EXT-X-DISCONTINUITY

4.媒体文件

5.密钥文件

5.1用于AES-128的IV

6.客户端/服务器动作

6.1服务器处理过程

6.1.1 滑动窗口播放列表

6.1.2 加密媒体文件

6.1.3 提供变体流

6.2客户端处理过程

6.2.1 加载播放列表文件

6.2.2 播放播放列表文件

6.2.3 重新加载播放列表文件

6.2.4 确定要加载的下一个文件

6.2.5 播放加密的媒体文件

7.例子

7.1简单的播放列表文件

7.2滑动窗口播放列表，利用HTTPS

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

7.4变体播放列表文件

8.安全考虑

9.参考

引用标准

引用信息

1.介绍

本文档描述了用于经HTTP发送无限制的多媒体数据流的一种协议[RFC2616]。该协议支持媒体数据的加密，及流的替换版本(例如，位速率)的提供。媒体文件可以在其被创建之后很快发送，以便允许其接近实时地被接收。

描述诸如HTTP之类的相关标准的外部参考在第9部分中列出。

2.概述

多媒体呈现是由到播放列表文件的URL[RFC3986]指定的，该播放列表文件是附加URI的有序列表。播放列表文件中的每个URI都指示作为单个连续流的一个片段的媒体文件。

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

本文档中的关键字“必须”、“不准”、“所请求的”、“将”、“不将”、“应当”、“不应当”、“推荐的”、“可以”和“可选的”要如在RFC2119[RFC2119]中所描述的那样来解释。

3.播放列表文件

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

M3U播放列表是包括多个单行的文本文件。行由单个LF字符或者CR字符后面跟着LF字符来终止。每一行都是URI、空行或者以注释字符“#”开始。URI识别要播放的媒体文件。空行被忽略。

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

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

实现应当产生其名字以.m3u8结尾或者，如果经HTTP发送的话，具有内容类型“application/vnd.apple.mpegurl”的播放列表文件。为了兼容，实现可以产生其名字以.m3u结尾和/或具有HTTP内容类型“audio/mpegurl”的播放列表文件。

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

EXTINF是描述由跟在其后面的URI识别的媒体文件的记录标记。每个媒体文件URI前面必须是EXTINF标签。其格式为：

#EXTINF：<持续时间>，<标题>

“持续时间”是以秒为单位的指定媒体文件的持续时间的整数。持续时间应当近似到最接近的整数。逗号之后行的剩余部分是媒体文件的标题。

3.1新标签

本文档定义了七个新标签：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。

3.1.1 EXT-X-TARGETDURATION

EXT-X-TARGETDURATION标签指示将添加到主呈现的下一个媒体文件的近似持续时间。它必须出现在播放列表文件中。其格式为：

#EXT-X-TARGETDURATION：<秒>

媒体文件的实际持续时间可以与目标持续时间稍有不同。

3.1.2 EXT-X-MEDIA-SEQUENCE

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

#EXT-X-MEDIA-SEQUENCE：<编号>

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

关于处理EXT-X-MEDIA-SEQUENCE标签的信息，见部分6.2.1和部分6.2.4。

3.1.3 EXT-X-KEY

媒体文件可以被加密。EXT-X-KEY标签提供了解密跟在其后面的媒体文件所必需的信息。其格式为：

#EXT-X-KEY:METHOD＝<方法>[，URI＝″<URI>″]

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

本协议的1.0版本定义了两种加密方法：NONE和AES-128。为NONE的加密方法意味着媒体文件不加密。

AES-128的加密方法意味着媒体文件是利用具有128位密钥和PKCS7填充符的高级加密标准[AES_128]加密的[RFC3852]。

新的EXT-X-KEY代替任何之前的EXT-X-KEY。

如果不存在EXT-X-KEY标签，则媒体文件是不加密的。

对于密钥文件的格式，见部分5和部分5.1。

对于关于媒体文件加密的附加信息，见部分6.1.2和部分6.2.5。

3.1.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>

3.1.5 EXT-X-ALLOW-CACHE

EXT-X-ALLOW-CACHE标签指示客户端是否可以高速缓冲下载的媒体文件以供以后重放。其格式为：

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

3.1.6EXT-X-ENDLIST

EXT-X-ENDLIST标签指示不再有媒体文件将添加到播放列表文件。其格式为：

#EXT-X-ENDLIST

3.1.7 EXT-X-STREAM-INF

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

#EXT-X-STREAM-INF：[属性＝值][，属性＝值]＊<URI>

以下属性是为EXT-X-STREAM-INF标签定义的：

BANDWIDTH＝<n>

其中n是流位速率的近似上限，表示为每秒的位数。

PROGRAM-ID＝<i>

其中i是唯一识别播放列表文件范围中的特定呈现的编号。

播放列表文件可以包含具有相同PROGRAM-ID的多个EXT-X-STREAM-INF URI，用来描述相同呈现的变体流。

CODECS＝”[格式][，格式]＊”

其中每种格式指定播放列表文件中媒体文件中所呈现的媒体样本类型。

有效格式标识符是由RFC 4281定义的ISO文件格式命名空间中的那些[RFC4281]。

3.1.8 EXT-X-DISCONTINUITY

EXT-X-DISCONTINUITY标签指示跟在其后面的媒体文件具有与其前面的媒体文件不同的特性。可以改变的特性集合是：

·文件格式

·轨迹的个数与类型

·编码参数

·编码序列

·时间戳序列

其格式为：

#EXT-X-DISCONTINUITY

4.媒体文件

播放列表文件中的每个媒体文件URI都必须识别作为整个呈现的一个片段的媒体文件。每个媒体文件必须被格式化为MPEG-2传输流、MPEG-2程序流或者MPEG-2音频基本流[ISO_13818]。一个呈现中的所有媒体文件都必须具有相同的格式。

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

客户应当准备好通过选择合理的子集来处理特定类型(例如，音频或视频)的多个轨迹。客户端必须忽略传输流中他们不能识别的私有流。

用于媒体文件中的流中的样本和在跨多个媒体文件的对应流之间的样本的编码参数应当保持一致。但是，客户端应当在遇到的时候处理编码变化，例如通过缩放视频内容来适应分辨率的变化。

5.密钥文件

具有URI参数的EXT-X-KEY标签识别密钥文件。密钥文件包含必须用于解密播放列表中的后续媒体文件的密码密钥。

AES-128加密方法使用16-八位字节密钥。密钥文件的格式简单地是这16个八位字节以二进制格式的打包阵列。

5.1用于AES-128的IV

当加密和解密时，128位的AES需要提供相同的16个八位字节初始化向量(IV)。改变这个IV将增加密码的强度。

当使用加密方法AES-128时，在加密或解密媒体文件时，实现将使用媒体文件的序列号作为IV。序列号的大端(Big-Endian)二进制表示将被放到16-八位字节缓冲中并(在左边)用零填充。

6.客户端/服务器动作

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

6.1服务器处理过程

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

服务器必须将流分成持续时间大致相等的各单个媒体文件。服务器应当尝试在支持单个媒体文件的有效解码的点——例如在包和密钥帧边界——划分流。

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

服务器必须创建播放列表文件。播放列表文件必须遵循部分3中所述的格式。用于服务器希望使其可用的每个媒体文件的URI必须以其要被播放的次序出现在该播放列表中。如果其URI在播放列表文件中的话，整个媒体文件必须可被客户获得。

播放列表文件必须包含EXT-X-TARGETDURATION标签。它必须指示下一个要添加到主呈现的媒体文件的大致持续时间。这个值必须对整个呈现保持恒定。典型的目标持续时间是10秒钟。

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

必须使播放列表文件的改变从客户的角度来看是极小的。

播放列表中的每个媒体文件URI必须加前缀EXTINF标签，其指示媒体文件的大致持续时间。

服务器可以通过用EXT-X-PROGRAM-DATE-TIME标签做其URI的前缀而将绝对日期和时间与媒体文件关联。所述日期和时间的值是任意的。

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

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

6.1.1滑动窗口播放列表

服务器可以将媒体文件的可用性限制到最近添加到播放列表的那些。为此，播放列表文件必须总是确切地包含一个EXT-X-MEDIA-SEQUENCE标签。它的值必须对从播放列表文件去除的每个媒体文件URI递增1。

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

当服务器从播放列表中去除媒体文件URI时，媒体文件必须在至少等于媒体文件的持续时间加上该媒体文件在其中出现的最长播放列表文件的持续时间的时段内可被客户获得。播放列表文件的持续时间是其中媒体文件的持续时间之和。

如果服务器计划去除媒体文件，则它应当确保当HTTP过期报头在被传送给客户端时反映了所计划的生存时间。

除非存在EXT-X-ENDLIST标签，否则服务器必须在任何时候都在播放列表中维持至少三个主呈现媒体文件。

6.1.2加密媒体文件

如果媒体文件要被加密，则服务器必须定义将允许授权客户端获得包含解密密钥的密钥文件的URI。该密钥文件必须遵循部分5中所述的格式。

服务器可以在密钥响应中设置过期报头，以便指示该密钥可以被高速缓冲。

如果加密方法是AES-128，则AES-128CBC加密将被应用到各单个媒体文件。整个文件必须被加密。不准跨媒体文件应用密码块链。媒体文件的序列号必须用作IV，如部分5.1中所述。

服务器必须利用由EXT-X-KEY标签指定的方法来加密播放列表中的每个媒体文件，其中EXT-X-KEY标签必须紧跟在播放列表文件中其URI之前。前面有其方法为NONE的EXT-X-KEY标签的或者前面没有任何EXT-X-KEY标签的媒体文件不准加密。

除非其方法为NONE，否则每个EXT-X-KEY标签的URI必须与出现在或者曾经出现在播放列表文件中的每个其它EXT-X-KEY标签的URI区分开。方法为NONE的EXT-X-KEY标签不准包含URI参数。

如果播放列表文件包含到利用那个密钥加密的媒体文件的URI，则服务器不准从播放列表文件中去除EXT-X-KEY标签。

6.1.3提供变体流

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

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

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

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

每个变体流必须包括相同的内容，包括不是主呈现的一部分的内容。

服务器必须使同一时段的内容在流的最小目标持续时间的精度内对所有变体流都可用。

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

基本音频流文件必须通过预先计划具有所有者标识符“com.apple.streaming.transportStreamTimestamp”的ID3 PRIV标签[ID3]来信号通知文件中第一个样本的时间戳。这个二进制数据必须是表示为大端八个八位字节数字的33位的MPEG-2程序基本流时间戳。

此外，所有变体流都应当包含相同的编码音频位流。这允许客户端在流之间切换而没有可以听得见的干扰。

6.2客户端处理过程

客户端如何获得到播放列表文件的URI在本文档的范围之外；本文档假设可以获得。

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

本文档没有指定客户端对变体流的处理。

6.2.1加载播放列表文件

每次从播放列表URI加载或者重新加载播放列表时：

客户端应当检查播放列表文件是以#EXTM3U开始而且如果不是就拒绝继续。客户端应当忽略其不认识的任何标签。

客户端必须确定要加载的下一个媒体文件，如部分6.2.4中所述。

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

6.2.2播放播放列表文件

当重放开始时，客户端将从播放列表中选择要首先播放哪个媒体文件。如果播放列表文件包含EXT-X-ENDLIST标签，则播放列表中的任何文件都可以首先播放。如果不存在EXT-X-ENDLIST标签，则可以首先播放除播放列表中的最后一个文件和倒数第二个文件之外的任何文件。

一旦已经选择了要播放的第一个媒体文件，播放列表中的后续媒体文件就必须以它们出现的次序来加载并以加载它们的次序来播放。

为了不中断的重放，客户端应当尝试在媒体文件被需要之前加载媒体文件，来补偿等待时间和吞吐率中的临时变化。

如果播放列表文件包含EXT-X-ALLOW-CACHE标签而且其值是NO，则客户端不准在播放其之后高速缓冲下载的媒体文件。否则，客户端可以无限地高速缓冲下载的媒体文件以供以后重放。

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

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

6.2.3重新加载播放列表文件

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

但是，客户端不准比由这部分所指定的更频繁地尝试重新加载播放列表文件。

当客户端第一次加载播放列表文件或者重新加载播放列表文件并发现其从上次加载以后已经有变化时，客户端必须在尝试再次重新加载播放列表文件之前等待一段时间。这个时段称为初始最小重新加载延迟。它是根据客户端开始加载播放列表文件的时刻测量的。

该初始最小重新加载延迟是播放列表中最后一个媒体文件的持续时间或者目标持续时间的3倍，取两者中较小的一个。媒体文件持续时间是由EXTINF标签指定的。

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

6.2.4确定要加载的下一个文件

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

要加载的第一个文件必须是客户端已经选择要首先播放的文件，如部分6.2.2中所述。

如果要播放的第一个文件已经被加载而且播放列表文件不包含EXT-X-MEDIA-SEQUENCE标签，则客户端必须验证当前的播放列表文件在其初始被找到的偏移处包含上次加载的媒体文件的URI，如果没有的话就暂停重放。要加载的下一个媒体文件必须是播放列表中跟在上次加载的URI之后的第一个媒体文件URI。

如果要播放的第一个文件已经加载而且播放列表文件包含EXT-X-MEDIA-SEQUENCE标签，则要加载的下一个媒体文件将是大于上次加载的媒体文件的序列号的最小序列号。

6.2.5播放加密的媒体文件

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

如果加密方法是AES-128，则AES-128 CBC解密将应用到各单个媒体文件。整个文件必须被解密。不准跨媒体文件应用密码块链。媒体文件的序列号必须用作IV，如部分5.1中所述。

如果加密方法是NONE，则客户端必须将EXT-X-KEY标签之后的所有媒体文件都作为明文(未加密的)来处理，直到遇到另一个EXT-X-KEY标签。

7.例子

这部分包含了几个示例播放列表文件。

7.1简单播放列表文件

#EXTM3U

#EXT-X-TARGETDURATION：10

#EXTINF：5220，

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

#EXT-X-ENDLIST

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

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

#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

7.4变体播放列表文件

#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

8.安全考虑

由于本协议总体上使用HTTP来发送数据，因此大部分相同的安全考虑都适用。见RFC 2616的部分15[RFC2616]。

媒体文件解析器一般会遭受“模糊”攻击。当解析从服务器接收到的文件时，客户端应当注意，以便拒绝不兼容的文件。

播放列表文件包含URI，客户端将使用这些URI来进行任意实体的网络请求。客户端应当范围检查响应，来防止缓冲溢出。还是见RFC3986的安全考虑部分[RFC3986]。

客户端应当缓慢地加载由URI识别的资源，以避免受到拒绝服务攻击。

HTTP请求常常包括会话状态(“cookies”)，该状态可能包含私有的用户数据。实现必须遵循由RFC 2965[RFC2965]指定的cookie约束和过期规则。还是见RFC 2965的安全考虑部分和RFC2964[RFC2964]。

加密密钥是由URI指定的。这些密钥的传送应当由一种机制来保护，诸如TLS之上的HTTP[RFC5246](先前的SSL)结合安全领域或者会话cookie。

9.参考

引用标准

[AES_128]U.S.Department of Commerce/National Institute ofStandards and Technology，″Advanced Encryption Standard(AES)，FIPS PUB 197″，November 2001，<http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf>.

[ISO_13818]

International Organization for Standardization，″ISO/IECInternational Standard 13818；Generic coding of movingpictures and associated audio information″，November 1994，<http://www.iso.org/iso/catalogue_detail？csnumber＝44169>.

[ISO_8601]

International Organization for Standardization，″ISO/IECInternational Standard 8601：2004；Data elements andinterchange formats--Information interchange--Representation of dates and times″，December 2004，<http://www.iso.org/iso/catalogue_detail？csnumber＝40874>.

[RFC2046]Freed，N.and N.Borenstein，″Multipurpose InternetMail Extensions(MIME)Part Two：Media Types″，RFC 2046，November 1996.

[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，″HypertextTransfer Protocol--HTTP/1.1″，RFC 2616，June 1999.

[RFC3629]Yergeau，F.，″UTF-8，a transformation format ofISO 10646″，STD 63，RFC 3629，November 2003.

[RFC3852]Housley，R.，″Cryptographic Message Syntax(CMS)″，RFC 3852，July 2004.

[RFC3986]Berners-Lee，T.，Fielding，R.，and L.Masinter，″Uniform Resource Identifier(URI)：Generic Syntax″，STD 66，RFC 3986，January 2005.

[RFC4281]Gellens，R.，Singer，D.，and P.Frojdh，″The CodecsParameter for″Bucket″Media Types″，RFC 4281，November 2005.

[US_ASCII]

American National Standards Institute，″ANSI X3.4-1986，Information Systems--Coded Character Sets 7-Bit AmericanNational Standard Code for Information Interchange(7-BitASCII)″，December 1986.

信息参考

[ID3]ID3.org，″The ID3 audio file data tagging format″，<http://www.id3.org/Developer_Information>.

[M3U]Nullsoft，Inc.，″The M3U Playlist format，originallyinvented for the Winamp media player″，<http://wikipedia.org/wiki/M3U>。

Claims

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

在服务器设备处将数据流划分成多个媒体文件，所述多个媒体文件中的每一个都以传输协议兼容格式作为各单个文件存储到存储器中；

生成具有多个标签和多个统一资源指示符(URI)的播放列表文件，所述多个URI指示所述多个媒体文件的用以重建数据流的次序；以及

生成与所述多个媒体文件的改变对应的更新的播放列表文件，该更新的播放列表文件包括多个更新的URI，所述多个更新的URI指示更新的多个媒体文件的用以重建数据流的表示的次序。

2.如权利要求1所述的方法，其中所述多个媒体文件的改变包括添加一个或多个媒体文件，并且更新的播放列表文件包括到所述多个媒体文件和所添加的一个或多个媒体文件的URI。

3.如权利要求1所述的方法，其中所述多个媒体文件的改变包括对一个或多个媒体文件的修改，并且更新的播放列表文件包括到所述多个媒体文件的URI，并且多个标签中的一个或多个标签被更新以反映对一个或多个媒体文件的修改。

4.如权利要求1所述的方法，其中所述多个媒体文件的改变包括从多个媒体文件中去除一个或多个所选的媒体文件以及添加一个或多个其它媒体文件以导致一个或多个剩余媒体文件，并且更新的播放列表文件包括到剩余媒体文件的URI，并且其中数据流是单个节目的基于连续时间的内容流，并且其中所述传输协议是HTTP兼容协议。

5.如权利要求1所述的方法，其中更新的播放列表是在所选时段过期的时候生成的。

6.如权利要求5所述的方法，其中所选时段基于播放列表文件中的标签之一的属性。

7.如权利要求1所述的方法，还包括：

确定要添加到播放列表文件的下一个媒体文件的大致持续时间；以及

使播放列表文件包括指示该大致持续时间的标签。

8.如权利要求7所述的方法，其中所述标签包括EXT-X-TARGETDURATION标签。

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

确定播放列表文件中URI中的一个或多个URI的序列号；以及

使播放列表文件包括指示所述序列号中的一个或多个的一个或多个标签。

10.如权利要求9所述的方法，其中所述一个或多个标签包括一个或多个EXT-X-MEDIA-SEQUENCE标签。

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

确定接收媒体文件的客户端设备是否被授权在重放之后存储媒体文件；以及

使播放列表包括指示客户端设备是否被授权在重放之后存储媒体文件的标签。

12.如权利要求11所述的方法，其中所述标签包括EXT-X-ALLOW-CACHE标签。

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

用于在服务器设备处将数据流划分成多个媒体文件的装置，所述多个媒体文件中的每一个都以传输协议兼容格式作为各单个文件存储到存储器中；

用于生成具有多个标签和多个统一资源指示符(URI)的播放列表文件的装置，所述多个URI指示所述多个媒体文件的用以重建数据流的次序；以及

用于生成与所述多个媒体文件的改变对应的更新的播放列表文件的装置，该更新的播放列表文件包括多个更新的URI，所述多个更新的URI指示更新的多个媒体文件的用以重建数据流的表示的次序。

14.如权利要求13所述的数据处理系统，其中所述多个媒体文件的改变包括添加一个或多个媒体文件，并且更新的播放列表文件包括到所述多个媒体文件和所添加的一个或多个媒体文件的URI。

15.如权利要求13所述的数据处理系统，其中所述多个媒体文件的改变包括对一个或多个媒体文件的修改，并且更新的播放列表文件包括到所述多个媒体文件的URI，并且多个标签中的一个或多个标签被更新以反映对一个或多个媒体文件的修改。

16.如权利要求13所述的数据处理系统，其中所述多个媒体文件的改变包括从多个媒体文件中去除一个或多个所选的媒体文件以及添加一个或多个其它媒体文件以导致一个或多个剩余媒体文件，并且更新的播放列表文件包括到剩余媒体文件的URI，并且其中数据流是单个节目的基于连续时间的内容流，并且其中所述传输协议是HTTP兼容协议。

17.如权利要求13所述的数据处理系统，其中更新的播放列表是在所选时段过期的时候生成的。

18.如权利要求17所述的数据处理系统，其中所选时段基于播放列表文件中的标签之一的属性。

19.如权利要求13所述的数据处理系统，还包括：

用于确定要添加到播放列表文件的下一个媒体文件的大致持续时间的装置；以及

用于使播放列表文件包括指示该大致持续时间的标签的装置。

20.如权利要求19所述的数据处理系统，其中所述标签包括EXT-X-TARGETDURATION标签。

21.如权利要求13所述的数据处理系统，还包括：

用于确定播放列表文件中URI中的一个或多个URI的序列号的装置；以及

用于使播放列表文件包括指示所述序列号中的一个或多个的一个或多个标签的装置。

22.如权利要求21所述的数据处理系统，其中所述一个或多个标签包括一个或多个EXT-X-MEDIA-SEQUENCE标签。

23.如权利要求13所述的数据处理系统，还包括：

用于确定接收媒体文件的客户端设备是否被授权在重放之后存储媒体文件的装置；以及

用于使播放列表包括指示客户端设备是否被授权在重放之后存储媒体文件的标签的装置。

24.如权利要求23所述的数据处理系统，其中所述标签包括EXT-X-ALLOW-CACHE标签。

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

以传输协议兼容格式将多个媒体文件作为各单个文件存储在存储器中，所述多个媒体文件是从基于连续时间的数据流划分成的；

利用所述传输协议将播放列表文件发送到客户端设备，该播放列表文件具有多个标签和多个统一资源指示符(URI)，所述多个URI指示所述多个媒体文件的用以重建数据流的次序；

响应来自客户端设备的利用所述多个URI中的一个或多个的一个或多个请求，利用传输协议将多个媒体文件中的一个或多个传输到客户端设备；以及

将更新的播放列表文件发送到客户端设备，所述更新的播放列表文件对应于多个媒体文件的改变，所述更新的播放列表文件包括多个更新的URI，该多个更新的URI指示更新的多个媒体文件的用以重建数据流的表示的次序。

26.如权利要求25所述的方法，其中多个媒体文件的改变包括以下中的至少一个：(a)一个或多个媒体文件的添加，并且更新的播放列表文件包括到所述多个媒体文件和所添加的一个或多个媒体文件的URI；(b)一个或多个媒体文件的修改，并且更新的播放列表文件包括到所述多个媒体文件的URI，并且多个标签中的一个或多个标签被更新以便反映对所述一个或多个媒体文件的修改；或者(c)一个或多个所选的媒体文件从所述多个媒体文件中的去除及一个或多个其它媒体文件的添加以导致一个或多个剩余的媒体文件，并且更新的播放列表文件包括到剩余媒体文件的URI，并且其中数据流是单个节目的基于连续时间的内容流，并且其中传输协议是HTTP兼容协议。

27.如权利要求25所述的方法，其中更新的播放列表是在所选时段过期的时候生成的，并且其中所选时段基于播放列表文件中的标签之一的属性，并且其中传输协议是HTTP兼容协议。

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

用于以传输协议兼容格式将多个媒体文件作为各单个文件存储在存储器中的装置，所述多个媒体文件是从基于连续时间的数据流划分成的；

用于利用非流化传输协议将播放列表文件发送到客户端设备的装置，该播放列表文件具有多个标签和多个统一资源指示符(URI)，所述多个URI指示所述多个媒体文件的用以重建数据流的次序；

用于响应来自客户端设备的利用所述多个URI中的一个或多个的一个或多个请求，利用传输协议将多个媒体文件中的一个或多个传输到客户端设备的装置；以及

用于将更新的播放列表文件发送到客户端设备的装置，所述更新的播放列表文件对应于多个媒体文件的改变，所述更新的播放列表文件包括多个更新的URI，该多个更新的URI指示更新的多个媒体文件的用以重建数据流的表示的次序。

29.如权利要求28所述的数据处理系统，其中多个媒体文件的改变包括以下中的至少一个：(a)一个或多个媒体文件的添加，并且更新的播放列表文件包括到所述多个媒体文件和所添加的一个或多个媒体文件的URI；(b)一个或多个媒体文件的修改，并且更新的播放列表文件包括到所述多个媒体文件的URI，并且多个标签中的一个或多个标签被更新以便反映对所述一个或多个媒体文件的修改；或者(c)一个或多个所选的媒体文件从所述多个媒体文件中的去除及一个或多个其它媒体文件的添加以导致一个或多个剩余的媒体文件，并且更新的播放列表文件包括到剩余媒体文件的URI，并且其中数据流是单个节目的基于连续时间的内容流，并且其中传输协议是HTTP兼容协议。

30.如权利要求28所述的数据处理系统，其中更新的播放列表是在所选时段过期的时候生成的，并且其中所选时段基于播放列表文件中的标签之一的属性，并且其中传输协议是HTTP兼容协议。

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

通过客户端设备，利用传输协议请求播放列表文件；

响应所述请求，接收具有以下的播放列表文件：(1)指示节目的基于连续时间的数据流的多个媒体文件的统一资源指示符(URI)和(2)具有与多个媒体文件有关的参数的多个标签；

以在播放列表中指示的次序请求并接收所述媒体文件中的一个或多个；以及

接收与所述媒体文件的改变对应的更新的播放列表文件，所述更新的播放列表文件包括指示更新的多个媒体文件的次序的多个更新的URI。

32.如权利要求31所述的方法，还包括：

从更新的多个媒体文件生成节目的呈现。

33.如权利要求32所述的方法，其中所述媒体文件的改变包括以下中的至少一个：(a)一个或多个媒体文件的添加，并且更新的播放列表文件包括到更新的多个媒体文件的URI；(b)所述多个媒体文件中的一个或多个的修改；或者(c)第一组媒体文件从播放列表文件中的去除以及一个或多个其它媒体文件到播放列表文件的添加，并且其中传输协议是HTTP兼容协议。

34.如权利要求33所述的方法，其中更新的播放列表是由客户端设备基于播放列表文件中的标签之一的属性在一时段过期的时候请求的。

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

用于通过客户端设备，利用传输协议请求播放列表文件的装置；

用于响应所述请求，接收具有以下的播放列表文件的装置：指示节目的基于连续时间的数据流的多个媒体文件的统一资源指示符(URI)和具有与多个媒体文件有关的参数的多个标签；

用于以在播放列表中指示的次序请求并接收所述媒体文件中的一个或多个的装置；以及

用于接收与所述媒体文件的改变对应的更新的播放列表文件的装置，所述更新的播放列表文件包括指示更新的多个媒体文件的次序的多个更新的URI。

36.如权利要求35所述的数据处理系统，还包括：

用于从更新的播放列表生成节目的呈现的装置。

37.如权利要求36所述的数据处理系统，其中所述媒体文件的改变包括以下中的至少一个：(a)一个或多个媒体文件的添加，并且更新的播放列表文件包括到更新的多个媒体文件的URI；(b)所述多个媒体文件中的一个或多个的修改；或者(c)第一组媒体文件从播放列表文件中的去除以及一个或多个其它媒体文件到播放列表文件的添加，并且其中传输协议是HTTP兼容协议。

38.如权利要求37所述的数据处理系统，其中更新的播放列表是由客户端设备基于播放列表文件中的标签之一的属性在一时段过期的时候请求的。

39.一种服务器设备，包括：

分段器，被配置成将数据流划分成多个媒体文件，所述多个媒体文件中的每一个都以传输协议兼容格式作为各单个文件存储到存储器中；以及

索引器，被配置成生成具有多个标签和多个统一资源指示符(URI)的播放列表文件和生成与所述多个媒体文件的改变对应的更新的播放列表文件，其中所述多个URI指示所述多个媒体文件的用以重建数据流的次序，并且该更新的播放列表文件包括多个更新的URI，所述多个更新的URI指示更新的多个媒体文件的用以重建数据流的表示的次序。

40.如权利要求39所述的服务器设备，其中所述多个媒体文件的改变包括添加一个或多个媒体文件，并且更新的播放列表文件包括到所述多个媒体文件和所添加的一个或多个媒体文件的URI。

41.如权利要求39所述的服务器设备，其中所述多个媒体文件的改变包括对一个或多个媒体文件的修改，并且更新的播放列表文件包括到所述多个媒体文件的URI，并且多个标签中的一个或多个标签被更新以反映对一个或多个媒体文件的修改。

42.如权利要求39所述的服务器设备，其中所述多个媒体文件的改变包括从多个媒体文件中去除一个或多个所选的媒体文件以及添加一个或多个其它媒体文件以导致一个或多个剩余媒体文件，并且更新的播放列表文件包括到剩余媒体文件的URI，并且其中数据流是单个节目的基于连续时间的内容流，并且其中所述传输协议是HTTP兼容协议。

43.一种服务器设备，包括：

存储器，被配置成以传输协议兼容格式存储多个媒体文件作为各单个文件，所述多个媒体文件是从基于连续时间的数据流划分成的；以及

HTTP服务器，被配置成利用所述传输协议将播放列表文件发送到客户端设备，该播放列表文件具有多个标签和多个统一资源指示符(URI)，所述多个URI指示所述多个媒体文件的用以重建数据流的次序，响应来自客户端设备的利用所述多个URI中的一个或多个的一个或多个请求，利用传输协议将多个媒体文件中的一个或多个传输到客户端设备，以及将更新的播放列表文件发送到客户端设备，所述更新的播放列表文件对应于多个媒体文件的改变，所述更新的播放列表文件包括多个更新的URI，该多个更新的URI指示更新的多个媒体文件的用以重建数据流的表示的次序。

44.如权利要求43所述的服务器设备，其中多个媒体文件的改变包括以下中的至少一个：(a)一个或多个媒体文件的添加，并且更新的播放列表文件包括到所述多个媒体文件和所添加的一个或多个媒体文件的URI；(b)一个或多个媒体文件的修改，并且更新的播放列表文件包括到所述多个媒体文件的URI，并且多个标签中的一个或多个标签被更新以便反映对所述一个或多个媒体文件的修改；或者(c)一个或多个所选的媒体文件从所述多个媒体文件中的去除及一个或多个其它媒体文件的添加以导致一个或多个剩余的媒体文件，并且更新的播放列表文件包括到剩余媒体文件的URI，并且其中数据流是单个节目的基于连续时间的内容流，并且其中传输协议是HTTP兼容协议。

45.一种客户端设备，包括：

组装器，被配置成利用传输协议请求播放列表文件，响应所述请求，接收具有以下的播放列表文件：(1)指示节目的基于连续时间的数据流的多个媒体文件的统一资源指示符(URI)和(2)具有与多个媒体文件有关的参数的多个标签，以在播放列表中指示的次序请求并接收所述媒体文件中的一个或多个，以及接收与所述媒体文件的改变对应的更新的播放列表文件，所述更新的播放列表文件包括指示更新的多个媒体文件的次序的多个更新的URI；以及

输出生成器，被配置成基于来自所述组装器的媒体文件，生成输出。

46.如权利要求45所述的客户端设备，其中所述媒体文件的改变包括以下中的至少一个：(a)一个或多个媒体文件的添加，并且更新的播放列表文件包括到更新的多个媒体文件的URI；(b)所述多个媒体文件中的一个或多个的修改；或者(c)第一组媒体文件从播放列表文件中的去除以及一个或多个其它媒体文件到播放列表文件的添加，并且其中传输协议是HTTP兼容协议。