用于实时或近实时流传输的播放列表的制作方法

用于实时或近实时流传输的播放列表的制作方法
【专利摘要】内容流传输系统——例如HTTP流传输系统——可以使用变体音频播放列表，该变体音频播放列表标识关于同一节目的不同音频播放列表，例如英语的一个播放列表和西班牙语的一个播放列表，该同一节目例如是由可与该变体音频播放列表分开的视频播放列表指定的视频节目。客户端可使用该变体音频播放列表来选择关于同一节目的特定音频内容，并且在该变体音频播放列表中的关于替换音频内容的一组替换URL之中，该音频播放列表中的一个URL可涉及该特定音频内容。
【专利说明】用于实时或近实时流传输的播放列表
[0001]相关申请
[0002]本申请根据35U.S.C.§ 119(e)要求2011年6月3日递交的61/493，324号美国临时申请的申请日的权益。本美国专利申请还与以下美国专利申请相关，这里通过引用并入每个以下美国专利申请:
[0003](I) 2009 年 6 月 5 日递交的题为 “REAL-TIME OR NEAR REAL-TIME STREAMING” 的12/479，690 号申请(案卷号 P7437US1)；
[0004](2) 2009 年 6 月 5 日递交的题为 “VARIANT STREAMS FOR REAL-TIME OR NEARREAL-TIME STREAMING” 的 12/479，698 号申请(案卷号 P7437US2)；
[0005](3) 2009 年 6 月 5 日递交的题为 “UPDATABLE REAL-TIME OR NEAR REAL-TIMESTREAMING” 的 12/479，732 号申请(案卷号 P7437US3);以及
[0006](4)2009 年 6 月 5 日递交的题为“PLAYLISTS FOR REAL-TIME OR NEAR REAL-TIMESTREAMING” 的 12/479，735 号申请(案卷号 P7437US4)。
【技术领域】
[0007]本发明的实施例涉及数据传送技术。更具体而言，本发明的实施例涉及允许利用
非流传输协议-例如超文本传送协议(HyperText Transfer Protocol, HTTP)-对数
据进行流传输(streaming)的技术。
【背景技术】
[0008]内容的流传输一般指的是被不断地从服务器设备发送并被客户端设备接收的多媒体内容。内容通常在其被流传输服务器递送的同时被呈现给最终用户。该名称指的是媒体的递送方法而不是媒体本身。
[0009]当前的流传输服务一般要求专门的服务器来向最终用户分发“实况”内容。在任何大规模部署中，这可导致巨大的成本，并且要求专门的技能来设立和运行。这导致了可用于流传输的内容库的量达不到合乎需要的程度。

【发明内容】

[0010]在一个实施例中，HTTP流传输系统可以使用变体播放列表,该变体播放列表标识关于同一视频节目的不同音频播放列表，例如一个是英语的，另一个是西班牙语的，而另一个是汉语的，该视频节目还具有关于视频内容的播放列表。例如，实况体育事件——例如棒球比赛——可具有从服务器发送到客户端的视频播放列表，并且同一实况体育事件可具有变体音频播放列表，该变体音频播放列表指定不同的音频播放列表，这些不同的音频播放列表对应于不同的语言或不同的覆盖角度(例如广播比赛的本地广播公司与广播该比赛的国家广播公司)。客户端设备可从服务器下载视频播放列表并且还下载变体音频播放列表，然后客户端设备可从变体音频播放列表中选择适当的音频节目并且下载与所选择的适当音频节目相对应的适当音频播放列表。在下载了视频播放列表和所选音频播放列表两者后，客户端可以开始同时地一并且在一个实施例中独立地一一处理两个播放列表，以在客户端设备处创建并呈现视频和音频。
[0011]一个实施例中在客户端设备处的一种方法可包括以下操作:接收关于节目的变体音频播放列表，其中该变体音频播放列表包含关于节目的不同音频内容的一组URL，并且该组URL中的每个URL涉及与该节目的不同音频内容之一相对应的音频播放列表；选择该组URL中的关于不同音频内容之一的第一 URL，该第一 URL涉及第一播放列表；发送涉及第一播放列表的第一 URL ;接收第一播放列表；以及处理第一播放列表以取回该节目的音频内容。在一个实施例中，该方法还可包括确定音频偏好，并且此音频偏好可由用户设定，例如用户偏好中的设定，并且此音频偏好可引起该方法中对第一 URL的选择。该方法在一个实施例中还可包括接收关于该节目的视频播放列表；该视频播放列表可包含关于该节目的视频内容的URL，并且每个关于视频内容的URL与视频内容的时间上的一部分相关联或者涉及视频内容的时间上的一部分。这个时间部分匹配在视频播放列表被处理的同时被客户端设备同时处理的音频播放列表的时间部分。该方法还可包括通过使用变体音频播放列表选择不同的音频播放列表来在关于音频内容的URL之间切换；在一个实施例中，在变体音频播放列表中的音频播放列表之间的切换可独立于视频播放列表的回放执行。该方法还可包括在一个实施例中同时且独立地处理音频播放列表和视频播放列表；例如，作为用于音频的播放器的第一软件组件可独立于处理视频播放列表的第二软件组件地处理音频播放列表。另外，在一个实施例中，音频下载模块可独立地下载并处理音频内容，同时视频下载模块可单独下载并处理视频内容。在一个实施例中，通过音频播放列表取回的音频内容中的时间戳和通过视频播放列表取回的视频内容中的时间戳指定相同时间段。另外，涉及不同音频内容的该组URL中的每个URL包括指定相同时间段的时间戳。
[0012]在本发明的一个实施例中由服务器设备执行的一种方法可包括响应于来自设备的请求而发送变体音频播放列表，该变体音频播放列表包含关于被请求的节目的不同音频内容的一组URL，其中该组URL中的每个URL涉及与该节目的不同音频内容之一相对应的音频播放列表。该方法还可包括从该设备接收该组URL中的第一 URL并且响应于接收到第一URL而向该设备发送第一音频播放列表，其中该第一 URL涉及第一音频播放列表。
[0013]这里描述了其他方法，并且这里还描述了机器可读非暂态存储介质，并且这里也描述了执行这些方法的系统。
【专利附图】

【附图说明】
[0014]在附图中以示例而非限制方式图示了本发明，附图中相似的标记指示类似的要素。
[0015]在附图中以示例而非限制方式图示了本发明，附图中相似的标记指示类似的要素。
[0016]图1是可发送和接收实时或近实时内容的服务器和客户端的一个实施例的框图。
[0017]图2A是一个或多个服务器设备利用非流传输协议支持媒体内容的技术的一个实施例的流程图。
[0018]图2B是一个或多个服务器设备向一个或多个客户端设备提供动态更新的播放列表的技术的一个实施例的流程图。[0019]图2C是一个或多个服务器设备利用多个比特率向客户端设备提供媒体内容的技术的一个实施例的流程图。
[0020]图3A是客户端设备利用非流传输协议支持内容的流传输的技术的一个实施例的流程图。
[0021]图3B是客户端设备利用多个比特率支持内容的流传输的技术的一个实施例的流程图。
[0022]图4是服务器流代理的一个实施例的框图。
[0023]图5是客户端流代理的一个实施例的框图。
[0024]图6图不了具有多个标签的播放列表文件的一个实施例。
[0025]图7是用于如这里所述的组装流的回放技术的一个实施例的流程图。
[0026]图8是电子系统的一个实施例的框图。
[0027]图9A是示出客户端设备如何可在变体播放列表中的替换内容之间切换的示例的流程图。
[0028]图9B是示出客户端设备如何可在两个播放列表中的内容之间切换的另一流程图。
[0029]图9C是示出客户端设备如何可利用音频模式匹配在内容之间切换的示例的另一流程图。
[0030]图9D概略示出了如何利用音频模式匹配来实现图9C的方法。
[0031]图10示出了可包括关于同一节目的不同音频内容的URL的变体播放列表的示例。
[0032]图11是示出在一个实施例中用于使用包括关于同一节目的音频内容的变体的URL的变体播放列表的方法的流程图。
[0033]图12示出了可用于这里描述的一个或多个实施例中的具有各种组件的客户端设备的示例。
[0034]图13是示出根据一个实施例由一服务器设备或一组服务器设备执行的方法的流程图。
[0035]图14图示了在本发明的一些实施例中可使用的示范性API体系结构的框图。
[0036]图15示出了在本发明的一些实施例中可使用的软件栈的示范性实施例。
【具体实施方式】
[0037]在以下说明书中，阐述了许多具体细节。然而，没有这些具体细节也可以实施本发明的实施例。在其他情况下，没有详细示出公知的电路、结构和技术，以免模糊对本说明书的理解。
[0038]本说明书包括受著作权保护的素材，例如对图形用户界面图像的图示。著作权所有人——包括本发明的受让人——特此保留其对这些素材的权利——包括著作权。著作权所有人不反对任何人对本专利文档或专利公开进行复制再现，因其出现在了专利商标局文件或记录中，但除此以外保留所有一切著作权。Copyright Apple Inc.2009。
[0039]在一个实施例中，这里描述的技术和组件可包括利用非流传输协议(例如HTTP)和其他技术(例如运动图片专家组(Motion Picture Expert Group, MPEG)流)来实现流传输体验的机制。例如，可利用HTTP来提供近实时的流传输体验，从而来广播“实况”音乐或体育事件、实况新闻、网络摄像头馈送，等等。在一个实施例中，协议可将传入的媒体数据分段成多个媒体文件并将这些分段的媒体文件存储在服务器上。协议还可构建播放列表文件，该播放列表文件包括将客户端引导至存储在服务器上的分段媒体文件的统一资源标识符(Uniform Resource Identifiers,.〗)。当根据(一个或多个)播放列表文件来回放分段媒体文件时，客户端可向用户提供“实况”事件的近实时广播。可以以类似的方式提供预记录的内容。
[0040] 本说明书的一个方面涉及使用为所选节目提供音频的变体的音频播放列表；例如，音频播放列表可以为还具有关于视频内容的播放列表的同一视频节目提供采取不同语言的不同播放列表，其中该视频播放列表与采取不同语言的音频播放列表是分开的。在结合图1至9D提供一些背景信息之后将结合图10至15描述这些方面。
[0041]在一个实施例中，服务器可将补充或替换的媒体内容(例如，广告、与体育事件有关的统计数据、主呈现的额外媒体内容)动态地引入到广播事件中。例如，在客户端对媒体事件的回放期间，服务器可向播放列表文件添加额外的URI，这些URI可标识客户端可下载补充媒体文件的位置。可以指令客户端周期性地从服务器取回一个或多个经更新的播放列表文件以便访问服务器引入的任何补充的或额外的(或者这两者)媒体内容。
[0042]在一个实施例中，服务器可在累积模式或滚动模式中操作。在累积模式中，服务器可创建播放列表文件并将媒体文件标识符附加到该播放列表文件的末尾。当单个播放列表文件被下载时，客户端随后可从该单个播放列表文件访问流的所有部分(例如，用户可从节目的中间开始)。在滚动模式中，服务器可通过以滚动方式从播放列表文件的开头去除媒体文件标识符来限制媒体文件的可用性，从而提供客户端设备可访问的媒体内容的滑动窗口。服务器还可向播放列表添加媒体文件标识符，并且在滚动模式中，服务器可将媒体文件的可用性限制于最近添加到播放列表的那些。客户端随后反复地下载播放列表文件的经更新的拷贝以继续观看。播放列表下载的滚动方式在内容可能在时间上是无限的时(例如，来自连续操作的网络摄像头的内容)可能是有用的。客户端可继续以滚动模式反复请求播放列表，直到其在播放列表中发现结束标签为止。
[0043]在一个实施例中，该机制通过提供同一呈现的变体流来支持比特率切换。例如，要提供的呈现的若干个版本可被存储在服务器上。每个版本可具有基本上相同的内容，但是以不同的比特率编码的。这可允许客户端设备依据例如对可用带宽的检测来在比特率之间切换，而不会损害回放的连续性。
[0044]在一个实施例中，可提供保护特征来保护内容免遭未经授权的使用。例如，可以使用非顺序式媒体文件编号来防止预测。可以使用媒体文件的加密。可使用部分媒体文件列表。也可提供额外的和/或不同的保护特征。
[0045]图1是可发送和接收实时或近实时内容的服务器和客户端的一个实施例的框图。图1的示例提供简单的服务器-客户端连接，其中两个客户端经由网络与服务器耦合。利用这里描述的技术和机制可支持任何数目的客户端。另外，根据这里描述的技术和机制，多个服务器可提供内容和/或可一起操作来提供内容。例如，一个服务器可创建内容，创建播放列表并且创建多个媒体(例如文件),并且其他服务器存储并发送创建的内容。
[0046]网络110可以是任何类型的网络，无论是有线的、无线的(例如，IEEE802.11、802.16)还是其任何组合。例如，网络100可以是因特网或内联网。作为另一示例，网络110可以是蜂窝网络(例如，3G、CDMA ) ο在一个实施例中，客户端设备150和180可能够通过多种网络类型通信(例如，每个设备可通过WiFi无线LAN通信，并且也可通过无线蜂窝电话网络通信)。例如，客户端设备150和180可以是能够通过蜂窝无线电电话网络以及数据网络通信的智能电话或者具备蜂窝能力的个人数字助理。这些设备可能够在任一类型的网络上利用这里描述的流传输机制或者甚至根据需要在网络之间切换。
[0047]服务器120可以以本领域中已知的任何方式作为HTTP服务器操作。也就是说，服务器120包括利用HTTP协议提供内容的HTTP服务器代理145。虽然图1的示例是按照HTTP来描述的，但可以以类似的方式利用其他协议。分段器130和索引器135是驻留在服务器120 (或多个服务器)上来如这里所述利用播放列表文件在媒体文件中提供内容的代理。可利用HTTP协议经由HTTP服务器代理145 (或经由其他服务器)通过网络110提供这些媒体文件和播放列表文件。这里论述的代理可实现为硬件、软件、固件或其组合。
[0048]分段器130可具有将媒体数据的流划分成可经由HTTP协议传送的多个媒体文件的功能。索引器135可具有如下功能:创建与分段媒体文件相对应的播放列表文件，以使得客户端设备可重组装这些媒体文件来提供由服务器120提供的内容的实时或近实时传送。响应于来自客户端设备的一个或多个请求，HTTP服务器代理145 (或其他服务器)可发送由索引器135生成的一个或多个播放列表文件和由分段器130生成的内容的媒体文件。服务器120还可包括可选的安保代理140，该安保代理140提供一个或多个这里论述的安保功能(例如加密)。服务器120还可包括图1中未示出的额外组件。
[0049]客户端设备150和180可通过网络110接收来自服务器120的播放列表文件和媒体文件。客户端设备可以是能够接收通过网络传送的数据并且利用经由网络接收的数据来生成输出的任何类型的电子设备，例如无线移动设备、PDA、娱乐设备、消费电子设备，等等。该输出可以是任何媒体类型或媒体类型的组合，例如包括音频、视频或其任何组合。
[0050]客户端设备150可包括组装器代理160和输出生成器代理165。类似地，客户端设备180可包括组装器代理190和输出生成器代理195。组装器代理160和180从服务器120接收播放列表文件并且使用这些播放列表文件来从服务器120访问和下载媒体文件。输出生成器代理165和195使用下载的媒体文件来分别生成从客户端设备150和160的输出。该输出可由一个或多个扬声器、一个或多个显不屏、扬声器和显不屏的组合或者任何其他输入或输出设备来提供。客户端设备还可包括存储器(例如闪存或DRAM等等)以充当在媒体文件被接收到时存储媒体文件(例如经压缩的媒体文件或者经解压缩的媒体文件)的缓冲器；缓冲器可提供超出当前正在呈现的内容的时间以外的许多秒的可呈现内容，从而使得缓冲的内容随后可在新内容被下载的同时被显示。此缓冲器可在客户端设备正尝试通过间歇性缓慢的网络连接取回内容的同时提供可呈现内容，因此缓冲器可隐藏网络延迟或连接问题。
[0051]客户端设备150和180还可分别包括可选的安保代理170和185，这些安保代理提供一个或多个这里论述的安保功能。客户端设备150和180还可包括图1中未示出的额外组件。
[0052]在一个实施例中，本申请中描述的技术可用于通过非流传输协议(例如HTTP)传送无限的多媒体数据流。实施例还可包括媒体数据的加密和/或流的替换版本的提供(例如，提供替换比特率)。因为媒体数据可在创建之后很快被发送，所以数据可被近实时地接收。提供了文件的示例数据格式以及多媒体数据的流的服务器(发送者)和客户端(接收者)要采取的动作；然而，也可支持其他格式。
[0053]可作为仿真的实时流(或近实时流)传送的媒体呈现由指示播放列表文件的统一资源标识符(URI)指定。在一个实施例中，播放列表文件是额外URI的有序列表。播放列表文件中的每个URI涉及作为流的片段的媒体文件，该流可以是特定节目的媒体数据的单个连续流。
[0054]为了播放媒体数据的流，客户端设备从服务器获得播放列表文件。客户端还获得并播放由播放列表文件指示的每个媒体数据文件。在一个实施例中，客户端可动态地或反复地重加载播放列表文件以发现额外的和/或不同的媒体片段。
[0055]播放列表文件例如可以是扩展M3U播放列表文件。在一个实施例中，使用有效地扩展M3U格式的额外标签。M3U指的是运动图片专家组音频第3层统一资源定位符(MovingPicture Experts Group Audio Layer3Uniform Resource Locator, MP3URL),并且是用于存储多媒体播放列表的格式。M3U文件是包含供媒体播放器播放的一个或多个媒体文件的位置的文本文件。
[0056]播放列表文件在一个实施例中是由个体行组成的扩展M3U格式的文本文件。这些行可终止于单个LF字符或者CR字符后跟LF字符。每一行可以是UR1、空白行或者以注释字符(例如“#”)开始。URI标识要播放的媒体文件。空白行可被忽略。
[0057]以注释字符开始的行可以是注释或标签。标签可开始于#EXT，而注释行可开始于#。注释行通常被服务器和客户端忽略。在一个实施例中，播放列表文件是以UTF-8格式编码的。UTF-8 (8比特统一码变换格式)是可变长度字符编码格式。在替换实施例中，可以使用其他字符编码格式。
[0058]在接下来的示例中，利用包括如下两个标签的扩展M3U格式:EXTM3U和EXTINF。扩展M3U文件可通过包括“#EXTM3U”的第一行与基本M3U文件相区分。
[0059]EXTINF是描述由跟随在该标签之后的URI标识的媒体文件的记录标记。在一个实施例中，每个媒体文件URI之前是EXTINF标签，例如:
[0060]#EXTINF:〈duration〉，〈title〉
[0061]其中“duration”指定媒体文件的持续时间，并且“title”是目标媒体文件的标题。
[0062]在一个实施例中，可以使用以下标签来管理媒体文件的传送和回放:
[0063]EXT-X-TARGETDURATION
[0064]EXT-X-MEDIA-SEQUENCE
[0065]EXT-X-KEY
[0066]EXT-X-PR0GRAM-DATE-TIME
[0067]EXT-X-ALLOff-CACHE
[0068]EXT-X-STREAM-1NF
[0069]EXT-X-ENDLIST
[0070]下文中将更详细描述这些标签中的每一个。虽然对于每个新标签描述了特定的格式和属性，但也可利用不同的属性、名称、格式等等来支持替换实施例。
[0071 ] EXT-X-TARGETDURAT ION标签可指示将被添加到呈现的下一媒体文件的大致持续时间。其可被包括在播放列表文件中并且格式可以是:
[0072]#EXT-X_TARGETDURATION:〈seconds〉
[0073]其中“seconds”指示媒体文件的持续时间。在一个实施例中，实际持续时间可与该标签指示的目标持续时间略有不同。在一个实施例中，指示一片段的每个URI将与该片段的大致持续时间相关联；例如，关于一片段的URI可前缀有指示该片段的大致持续时间的标签。
[0074]播放列表文件中的每个媒体文件URI可具有唯一的序列号。在一个实施例中，URI的序列号如果存在则等于它前面的URI的序列号加一。EXT-X-MEDIA-SEQUENCE标签可指示出现在播放列表文件中的第一 URI的序列号，并且格式可以是:
[0075]#EXT-X-MEDIA-SEQUENCE:〈number〉
[0076]其中“number”是URI的序列号。如果播放列表文件不包括#EXT-X-MEDIA-SEQUENCE标签，则可以认为播放列表中的第一 URI的序列号为I。在一个实施例中，序列编号可以是非顺序式的；例如，诸如1、5、7、17等等之类的非顺序式序列编号可以使得难以预测序列中的下一号码，并且这可帮助保护内容免遭盗版。帮助保护内容的另一选项是在任何给定时间只揭露播放列表的一部分。
[0077]—些媒体文件可被加密。EXT-X-KEY标签提供可用于对跟随其后的媒体文件进行解密的信息，并且格式可以是:
[0078]#EXT-X-KEY:METH0D=<method>[，URI="〈URI>"]
[0079]METHOD参数指定加密方法，并且URI参数如果存在则指定如何获得密钥。
[0080]NONE的加密方法指示没有加密。可以使用各种加密方法，例如AES-128，AES-128指示使用具有128比特密钥和PKCS7填充的高级加密标准加密[参见RFC3852]。新的EXT-X-KEY标签取代任何先前的EXT-X-KEY标签。
[0081]具有URI参数的EXT-X-KEY标签标识密钥文件。密钥文件可包含用于对播放列表文件中列出的后续媒体文件进行解密的加密密钥。例如，AES-128加密方法使用16八位字节的密钥。密钥文件的格式可以是二进制格式的16个八位字节的压缩阵列。
[0082]对AES-128的使用通常要求在加密和解密时提供相同的16八位字节的初始化向量(IV)。改变IV可用于增大密码的强度。当使用AES-128加密时，在对媒体文件加密或解密时可使用媒体文件的序列号作为IV。
[0083]EXT-X-PROGRAM-DATE-TIME标签可将下一媒体文件的开头与绝对日期和/或时间关联起来并且可包括或指示时区。在一个实施例中，日期/时间表示是IS0/IEC8601:2004。标签格式可以是:
[0084]EXT-X-PROGRAM-DATE-TIME:<YYYY-MM-DDThh: mm:ssZ>
[0085]EXT-X-ALLOW-CACHE标签可用于指示客户端是否可以将下载的媒体文件高速缓存来供以后回放。标签格式可以是:
[0086]EXT-X-ALLOW-CACHE:〈YES|NO〉
[0087]EXT-X-ENDLIST标签在一个实施例中指示没有更多媒体文件会被添加到播放列表文件。标签格式可以是:
[0088]EXT-X-ENDLIST
[0089]在一个实施例中，如果播放列表包含最终片段或媒体文件，则该播放列表将具有EXT-X-ENDLIST 标签。
[0090]EXT-X-STREAM-1NF标签可用于指示播放列表文件中的下一 URI标识另一播放列表文件。标签格式在一个实施例中可以是:
[0091]EXT-X-STREAM-1NF:[attribute=value][，attribute=value]*〈URI> 其中可以使用以下属性。属性BANDWIDTH=〈n>是表达为每秒比特数的流比特率的大致上限。属性PR0GRAM-1D=<i>是唯一地标识该播放列表文件的范围内的特定呈现的数字。播放列表文件可包括具有相同PR0GRAM-1D的多个EXT-X-STREAM-1NF URI来描述同一呈现的变体流。变体流和变体播放列表在本公开中有进一步描述(例如参见图9A-9D)。
[0092]前述标签和属性可被服务器设备用于组织、发送和处理表示原始媒体内容的媒体文件。客户端设备使用该信息来以向客户端设备的用户提供实时或近实时流传输体验(例如观看诸如音乐或体育事件之类的实况广播)的方式重组装并呈现媒体文件。
[0093]播放列表文件中的每个媒体文件URI标识作为原始呈现(即，原始媒体内容)的一片段的媒体文件。在一个实施例中，每个媒体文件被格式化为MPEG-2传输流、MPEG-2节目流或MPEG-2音频基本流。格式可通过指定编解码器来指定，并且播放列表可通过指定编解码器来指定格式。在一个实施例中，一呈现中的所有媒体文件具有相同的格式；然而，在其他实施例中可支持多个格式。传输流文件在一个实施例中应当包含单个MPEG-2节目，并且在每个文件开始处应当有节目关联表和节目映射表。包含视频的文件应当具有至少一个关键帧和足够的信息来完整地初始化视频解码器。客户端应当通过选择合理的子集来准备好处理特定类型(例如音频或视频)的多条轨道。客户端在一个实施例中应当忽略传输流内的其未识别出的私有流。用于一媒体文件内部的流内的和跨多个媒体文件的相应流之间的样本的编码参数应当保持一致。然而，客户端在遇到编码变化时应当应对编码变化，其方式例如是通过缩放视频内容以适应分辨率变化。
[0094]图2A是一个或多个服务器设备利用非流传输协议支持媒体内容的技术的一个实施例的流程图。图2A的示例是按照HTTP来提供的；然而，以类似的方式可以利用其他非流传输协议。图2A的示例是按照单个服务器执行某些任务来提供的。然而，可以利用任何数目的服务器。例如，向客户端设备提供媒体文件的服务器与将内容分段成多个媒体文件的服务器可以是不同的设备。
[0095]服务器设备在操作200中接收要提供的内容。内容可表示实况音频和/或视频(例如，体育事件、实况新闻、网络摄像头馈送)。内容也可表示预记录的内容(例如，已记录的音乐会、培训班，等等)。内容可被服务器根据本领域已知的任何格式和协议接收，无论是否被流传输。在一个实施例中，内容以MPEG-2流的形式被服务器接收；然而，也可支持其他格式。
[0096]服务器随后在操作210中可临时存储内容的至少一些部分。内容或内容的至少一些部分可被临时存储在例如存储设备(例如存储区域网络中的硬盘等等)上或存储器中。或者，可经由存储介质(例如，致密盘、闪存盘)接收内容，从该存储介质中内容可被传送到存储设备或存储器。在一个实施例中，服务器具有编码器，该编码器根据需要将内容转换成一个或多个流(例如MPEG-2)。此转换可在不永久存储接收到的内容的情况下发生，并且在一些实施例中，存储操作210可被省略或者在其他实施例中其可以是更长期的存储(例如归档存储)。[0097]在操作220中，要提供的内容被分段成多个媒体文件。在一个实施例中，服务器将流转换成分开且不同的媒体文件(即，片段)，这些媒体文件可利用标准的web服务器来分发。在一个实施例中，服务器在支持个体媒体文件的有效解码的点(例如，在分组和关键帧边界上，例如PES分组边界和i帧边界)对媒体流分段。媒体文件可以是原始流的具有大致相等的持续时间的部分。服务器还为每个媒体文件创建URI。这些URI允许客户端设备访问媒体文件。
[0098]因为片段是利用天生递送整个文件的HTTP服务器来提供的，所以在完整的分段媒体文件可被提供给客户端之前，服务器应当使该完整的分段媒体文件可用。从而，客户端可(在时间上)滞后广播，滞后量为至少一个媒体文件的长度。在一个实施例中，媒体文件大小是基于滞后时间和有太多文件之间的平衡的。
[0099]在一个实施例中，支持两种会话类型(实况会话和事件会话)。对于实况会话，只保留流的固定大小部分。在一个实施例中，过时的内容媒体文件被从节目播放列表文件中去除，并且可被从服务器中去除。第二类会话是事件会话，其中客户端可调谐到广播的任何一点(例如，从开头开始，从中间点开始)。这类会话例如可用于重广播。
[0100]在操作230中，媒体文件被存储在服务器存储器中。在操作230中存储文件之前，可通过诸如加密之类的安保特征来保护媒体文件。媒体文件被存储为准备好利用服务器设备上的Web服务器应用所支持的(或者进行发送的另一设备所支持的)网络协议(例如，HTTP或HTTPS)发送的文件。
[0101]在操作240中，生成一个或多个播放列表文件来指示应当以何种顺序组装媒体文件以重建原始内容。(一个或多个)播放列表文件可利用扩展M3U标签和这里描述的标签来提供信息供客户端设备访问和重组装媒体文件以在客户端设备上提供流传输体验。关于每个媒体文件的URI按照要播放媒体文件的顺序被包括在(一个或多个)播放列表文件中。服务器也可以为(一个或多个)播放列表文件创建一个或多个URI以允许客户端设备访问该(一个或多个)播放列表文件。
[0102]在操作250中，(一个或多个)播放列表文件可被存储在服务器上。虽然媒体文件和(一个或多个)播放列表文件的创建和存储在图2A中是按特定顺序呈现的，但也可使用不同的顺序。例如，可以在创建或存储媒体文件之前创建(一个或多个)播放列表文件。作为另一示例，(一个或多个)播放列表文件和媒体文件可在其中任一个被存储之前被创建。
[0103]如果媒体文件要被加密，则(一个或多个)播放列表文件可定义URI，该URI允许经授权的客户端设备获得包含加密密钥的密钥文件来对媒体文件解密。可利用安全连接(例如HTTPS)来传送加密密钥。作为另一示例，可利用HTTPS来传送(一个或多个)播放列表文件。作为又一示例，可按不可预测的顺序布置媒体文件，以使得客户端在没有(一个或多个)播放列表文件的情况下不能重建流。
[0104]如果加密方法是AES-128，则例如AES-128CBC加密可被应用到个体媒体文件。在一个实施例中，整个文件被加密。在一个实施例中，通常不跨媒体文件应用密码块链接。媒体文件的序列如上所述被用作IV。在一个实施例中，服务器向播放列表文件的末尾添加具有密钥URI的EXT-X-KEY标签。服务器随后利用该密钥来对所有后续媒体文件加密，直到加密配置的改变被作出为止。
[0105]为了切换到新的加密密钥，服务器可经由与该呈现中使用的所有先前的密钥URI不同的新URI来使新密钥可用。服务器还向播放列表文件的末尾添加具有新密钥URI的EXT-X-KEY标签，并且利用该新密钥对所有后续的媒体文件加密。
[0106]为了结束加密，服务器可在播放列表文件的末尾处添加具有加密方法NONE的EXT-X-KEY标签。该标签(以“NONE”作为方法)在一个实施例中不包括URI参数。如上所述，所有后续的媒体文件不被加密，直到加密配置的改变被作出为止。服务器不从播放列表文件中去除EXT-X-KEY标签，如果该播放列表文件包含去到利用该密钥加密的媒体文件的URI的话。在操作270中，服务器可响应于客户端请求通过网络发送(一个或多个)播放列表文件和媒体文件，这将联系图3A来更详细描述。
[0107]在一个实施例中，服务器响应于接收到来自客户端设备的对播放列表文件的请求而向客户端设备发送该播放列表文件。客户端设备可利用已提供给该客户端设备的URI来访问/请求播放列表文件。URI指示播放列表文件在服务器上的位置。作为响应，服务器可将播放列表文件提供给客户端设备。客户端设备可利用播放列表文件中的标签和URI (或其他标识符)来访问多个媒体文件。
[0108]在一个实施例中，服务器可将媒体文件的可用性限制于最近添加到(一个或多个)播放列表文件的那些。为此，每个播放列表文件可包括仅一个EXT-X-MEDIA-SEQUENCE标签，并且对于从播放列表文件中去除的每个媒体文件URI，该值可被递增I。媒体文件URI可按其被添加的顺序被从(一个或多个)播放列表文件中去除。在一个实施例中，当服务器从(一个或多个)播放列表文件中去除媒体文件URI时，该媒体文件在一段时间中对客户端保持可用，该段时间的长度等于该媒体文件的持续时间加上该媒体文件出现于其中的最长播放列表文件的持续时间。
[0109]播放列表文件的持续时间是该播放列表文件内的媒体文件的持续时间的总和。也可使用其他持续时间。在一个实施例中，服务器可始终在播放列表中维持至少三个主呈现媒体文件，除非存在EXT-X-ENDLIST标签。
[0110]图2B是一个或多个服务器设备向一个或多个客户端设备提供动态更新的播放列表的技术的一个实施例的流程图。可利用这里描述的累积模式或滚动模式来更新播放列表。图2B的示例是按照HTTP来提供的；然而，以类似的方式可以利用其他非流传输协议(例如，HTTPS等等)。图2B的示例是按照一服务器执行某些任务来提供的。然而，可以利用任何数目的服务器。例如，向客户端设备提供媒体文件的服务器与将内容分段成多个媒体文件的服务器可以是不同的设备。
[0111]服务器设备在操作205中接收要提供的内容。服务器随后在操作215中可临时存储内容的至少一些部分。操作215可与图2A中的操作210类似。在操作225中，要提供的内容被分段成多个媒体文件。在操作235中，媒体文件可被存储在服务器存储器中。在操作235中存储文件之前，可通过诸如加密之类的安保特征来保护媒体文件。
[0112]在操作245中，生成一个或多个播放列表文件来指示应当以何种顺序组装媒体文件以重建原始内容。在操作255中，(一个或多个)播放列表文件可被存储在服务器上。虽然媒体文件和(一个或多个)播放列表文件的创建和存储在图2B中是按特定顺序呈现的，但也可使用不同的顺序。
[0113]在操作275中，服务器(或另一服务器)可响应于客户端请求而通过网络发送(一个或多个)播放列表文件和媒体文件，这将联系图3A-3B来更详细描述。[0114]服务器可出于各种原因更新(一个或多个)播放列表文件。在操作285中，服务器可接收要提供给客户端设备的额外数据。额外数据可以是在操作255中存储(一个或多个)播放列表文件之后接收的。额外数据例如可以是实况呈现的额外部分，或者关于现有呈现的额外信息。额外数据可包括广告或统计数据(例如，与体育事件有关的得分或数据)。额外数据可(通过半透明)被覆盖在呈现上或者在侧边栏用户界面中呈现。额外数据可按与原始接收的数据相同的方式被分段。如果额外数据构成广告，或者要插入到播放列表所表示的节目中的其他内容，则额外数据可在操作215中被(至少临时地)存储，在操作225中被分段并且在操作235中被存储；在存储分段的额外数据之前，额外数据的片段可被加密。然后在操作245中，将生成经更新的播放列表，其包含节目和额外数据。播放列表基于额外数据被更新并且在操作255中再次被存储。对(一个或多个)播放列表文件的改变从客户端设备的角度来看应当以原子的方式进行。经更新的播放列表在一个实施例中替代先前的播放列表。如下文更详细论述的，客户端设备可多次请求播放列表。这些请求使得客户端设备能够利用最近的播放列表。在一个实施例中，额外数据可以是元数据；在此情况下，播放列表不需要被更新，但是片段可被更新来包括元数据。例如，元数据可包含可与片段中的时间戳匹配的时间戳，并且元数据可被添加到具有匹配的时间戳的片段。
[0115]经更新的播放列表也可导致媒体文件的去除。在一个实施例中，服务器应当按照关于媒体文件的URI被添加到播放列表的顺序从播放列表中去除关于媒体文件的URI。在一个实施例中，如果服务器去除整个呈现，则其使得(一个或多个)播放列表文件对于客户端设备不可用。在一个实施例中，服务器维持媒体文件和(一个或多个)播放列表文件，维持的时间为包含要去除的媒体文件的最长的(一个或多个)播放列表文件的持续时间，以允许当前的客户端设备完成对呈现的访问。因此，播放列表文件中的每个媒体文件URI可前缀有EXT-X-STREAM-1NF标签以指示该播放列表文件指示的媒体文件的大致累积持续时间。在替换实施例中，可立即去除媒体文件和(一个或多个)播放列表文件。
[0116]随后来自客户端设备的对播放列表的请求导致服务器在操作275中提供经更新的播放列表。在一个实施例中，播放列表被定期地更新，例如与目标持续时间有关的时间周期。播放列表文件的周期性更新允许服务器提供对服务器的方位以用于动态变化的呈现。
[0117]图2C是一个或多个服务器设备利用多个比特率向客户端设备提供媒体内容的技术的一个实施例的流程图，这是对替换流的使用的一种形式。图2C的示例是按照HTTP来提供的；然而，以类似的方式可以利用其他非流传输协议。图2C的示例是按照一服务器执行某些任务来提供的。然而，可以利用任何数目的服务器。例如，向客户端设备提供媒体文件的服务器与将内容分段成多个媒体文件的服务器可以是不同的设备。
[0118]在一个实施例中，服务器可提供多个播放列表文件或者在单个播放列表文件中具有多个媒体文件列表的单个播放列表文件，以提供同一呈现的不同编码。如果提供不同的编码，则(一个或多个)播放列表文件可包括提供不同比特率的每个变体流以允许客户端设备在编码之间动态地切换(这将联系图9A-9D来进一步描述)。具有变体流的播放列表文件对于每个变体流可包括EXT-X-STREAM-1NF标签。同一呈现的每个EXT-X-STREAM-1NF标签可具有相同的PR0GRAM-1D属性值。每个呈现的PR0GRAM-1D值在变体流内是唯一的。
[0119]在一个实施例中，服务器在产生变体流时满足以下约束。每个变体流可由相同内容构成，其中包括不是主呈现的一部分的可选内容。在流的最小目标持续时间的精度内，月艮务器可使得相同时段的内容对于所有变体流可用。变体流的媒体文件在一个实施例中是具有样本时间戳的MPEG-2传输流或MPEG-2节目流，所述样本时间戳对于所有变体流中的相应内容是匹配的。另外，所有变体流在一个实施例中应当包含相同的音频编码。这允许客户端设备在变体流之间切换，而不丢失内容。
[0120]参考图2C，服务器设备在操作202中接收要提供的内容。服务器随后在操作212中可至少临时存储内容。在操作222中，要提供的内容被分段成多个媒体文件。在操作232中，针对所选的比特率(或者其他编码参数的所选值)对每个媒体文件编码并将其存储在服务器上。例如，媒体文件可针对高带宽、中带宽和低带宽连接。媒体文件可在存储之前被加密。针对各种类型的连接对媒体文件的编码可被选择来在目标带宽水平上提供流传输体验。
[0121]在一个实施例中，在操作242中生成具有如这里所述的指示各种编码水平的标签的变体播放列表。标签例如对于每个编码水平可包括EXT-X-STREAM-1NF标签，其中带有去到相应媒体播放列表文件的URI。
[0122]此变体播放列表对于各种编码水平可包括去到媒体播放列表文件的URI。从而，客户端设备可以从指示编码水平的变体播放列表中提供的替换物之中选择目标比特率并且取回相应的播放列表文件。在一个实施例中，客户端设备可在回放期间在比特率之间改变(例如，如联系图9A-9D所述)。指示各种编码水平的变体播放列表在操作252中被存储在服务器上。在操作242中，在变体播放列表中涉及的每个播放列表也可被生成，然后在操作252中被存储。
[0123]响应于来自客户端设备的请求，服务器在操作272中可发送指示各种编码水平的变体播放列表。服务器在操作282中可接收对变体播放列表中指定的与所选比特率相对应的媒体播放列表之一的请求。响应于该请求，服务器在操作292中发送与来自客户端设备的请求相对应的媒体播放列表文件。客户端设备随后可使用该媒体播放列表来向服务器请求媒体文件。服务器在操作297中响应于请求将媒体文件提供给客户端设备。
[0124]图3A是客户端设备利用非流传输协议支持内容的流传输的技术的一个实施例的流程图。图3A的示例是按照HTTP来提供的；然而，以类似的方式可以利用其他非流传输协议。图3A-3B中所示的方法可由一个客户端设备或若干个分开的客户端设备执行。例如，在这些方法中的任何一种的情况下，单个客户端设备可执行所有操作(例如，请求播放列表文件、利用播放列表文件中的URI请求媒体文件、组装媒体文件以生成并提供呈现/输出)或者若干个不同的客户端设备可执行一些但不是所有操作(例如，第一客户端设备可请求播放列表文件并利用播放列表文件中的URI请求媒体文件并且可将这些媒体文件存储来供第二客户端设备使用，该第二客户端设备可处理媒体文件以生成并提供呈现/输出)。
[0125]客户端设备在操作300中可向服务器请求播放列表文件。在一个实施例中，该请求是根据遵从HTTP的协议来作出的。该请求利用去到存储在服务器上的初始播放列表文件的URI。在替换实施例中，可支持其他非流传输协议。响应于该请求，服务器将通过网络把相应的播放列表文件发送到客户端。如上所述，网络可以是有线的或无线的并且可以是有线或无线网络的任何组合。另外，网络可以是数据网络(例如IEEE802.11、IEEE802.16)或蜂窝电话网络(例如3G)。
[0126]客户端设备在操作310中可接收播放列表文件。在操作320中播放列表文件可被存储在客户端设备的存储器中。存储器例如可以是硬盘、闪存、随机访问存储器。在一个实施例中，每次从播放列表URI加载或重加载播放列表文件时，客户端就进行检查以确定该播放列表文件开始于#EXTM3U标签，并且如果该标签不存在则不继续。如上所述，播放列表文件包括一个或多个标签以及去到媒体文件的一个或多个URI。
[0127]客户端设备可包括组装器代理，该组装器代理通过在操作330中请求播放列表文件中的URI所指示的媒体文件来使用播放列表文件来重组装原始内容。在一个实施例中，组装器代理是作为标准Web浏览器应用的一部分的插件模块。在另一实施例中，组装器代理可以是独立的应用，其与Web浏览器交互以接收并利用(一个或多个)播放列表文件组装媒体文件。作为又一示例，组装器代理可以是嵌入在客户端设备中的专用硬件或固件组件。
[0128]组装器使得来自播放列表文件的媒体文件被从URI所指示的服务器下载。如果播放列表文件包含EXT-X-ENDLIST标签，则播放列表文件所指示的任何媒体文件可被首先播放。如果EXT-X-ENDLIST标签不存在，则除了最后一个和倒数第二个媒体文件以外的任何媒体文件可被首先播放。一旦选择了要播放的第一媒体文件，播放列表文件中的后续媒体文件在一个实施例中就按照它们出现在播放列表文件中的顺序被加载(否则内容被乱序呈现)。在一个实施例中，客户端设备在需要媒体文件之前就尝试加载媒体文件(并将它们存储在缓冲器中)以提供不间断的回放并且对网络延迟和吞吐量的临时变化进行补偿。
[0129]在操作340中，下载的(一个或多个)媒体文件可被存储在客户端设备上的存储器中。可存储内容的存储器可以是客户端设备上的任何类型的存储器，例如随机访问存储器、硬盘或视频缓冲器。存储可以是临时的以允许回放，或者可以是永久的。如果播放列表文件包含EXT-X-ALLOW-CACHE标签并且其值为NO，则客户端在下载的媒体文件被播放之后不存储这些媒体文件。如果播放列表包含EXT-X-ALLOW-CACHE标签并且其值为YES，则客户端设备可无限期地存储媒体文件以便以后重放。客户端设备可使用ext-x-program-date-hme标签的值来向用户显示节目起始时间。在一个实施例中，客户端可缓冲多个媒体文件，以使得其不那么容易受网络抖动的影响，以便提供更好的用户体验。
[0130]在一个实施例中，如果解密方法是AES-128，则AES-128CBC解密被应用到个体媒体文件。整个文件被解密。在一个实施例中，不跨媒体文件应用密码块链接。媒体文件的序列号如上所述可用作初始化向量。
[0131]在操作350中，可从存储器中将内容从客户端设备输出。输出或呈现例如可以是经由内置的扬声器或头戴式耳机的音频输出。输出可包括经由屏幕输出或从客户端设备投影的视频。可以利用本领域已知的任何类型的输出。在操作351中，客户端设备确定在存储的当前播放列表中是否有任何更多的尚未被播放或以其他方式呈现的媒体文件。如果存在这样的媒体文件(并且如果它们尚未被请求)，则处理返回到操作330，在该操作中一个或多个媒体文件被请求，并且该过程重复。如果没有这样的媒体文件(即，当前播放列表中的所有媒体文件都已被播放)，则处理前进到操作352，该操作确定播放列表文件是否包括结束标签。
[0132]如果在操作352中播放列表包括结束标签(例如，EXT-X-ENDLIST),则当播放列表文件所指示的媒体文件已被播放时，回放停止。如果在播放列表中没有结束标签，则客户端再次向服务器请求播放列表并且返回到操作300以获得该节目的另一个或经更新的播放列表。[0133]如联系图2B更详细论述的，服务器可更新播放列表文件以引入补充内容(例如，与实况广播中的额外媒体内容相对应的额外媒体文件标识符)或额外内容(例如，流中接下来的内容)。为了访问补充内容或额外内容，客户端可从服务器重加载经更新的播放列表。这可提供一种机制，通过该机制，即使在与播放列表文件相关联的媒体内容的回放期间也可动态更新播放列表文件。客户端可基于触发物的数目来请求播放列表文件的重加载。结束标签的缺乏是一个这种触发物。
[0134]在一个实施例中，客户端设备周期性地重加载(一个或多个)播放列表文件，除非播放列表文件包含EXT-X-ENDLIST标签。当客户端设备第一次加载播放列表文件或者重加载播放列表文件并发现该播放列表文件从上次被加载起已改变了时，客户端在尝试再次重加载播放列表文件之前可等待一段时间。此时段被称为初始最小重加载延迟。它是从客户端开始加载播放列表文件的时间起测量的。
[0135]在一个实施例中，初始最小重加载延迟是播放列表文件中的最后媒体文件的持续时间或目标持续时间的三倍中较小的那个。媒体文件持续时间由EXTINF标签指定。如果客户端重加载播放列表文件并且发现其没有变化，则客户端在重试之前可等待一段时间。一个实施例中的最小延迟是目标持续时间的三倍或初始最小重加载延迟的倍数中较小的那个。在一个实施例中，此倍数对于第一次尝试是0.5，对于第二次尝试是1.5，并且对于后续的尝试是3.0 ;然而，可以使用其他倍数。
[0136]每次播放列表文件被加载或重加载时，客户端设备就检查播放列表文件以确定要加载的下一媒体文件。要加载的第一文件是如上所述被选择为首先播放的媒体文件。如果要播放的第一媒体文件已被加载并且播放列表文件不包含EXT-X-MEDIA-SEQUENCE标签，则客户端可验证当前播放列表文件在起初找到最后加载的媒体文件的URI的偏移量处包含该URI，如果没有找到该文件则停止回放。要加载的下一媒体文件可以是播放列表文件中跟随在最后加载的URI之后的第一媒体文件URI。
[0137]如果要播放的第一文件已被加载并且播放列表文件包含EXT-X-MEDIA-SEQUENCE标签，则要加载的下一媒体文件可以是具有大于加载的最后媒体文件的序列号的最低序列号的那个。如果播放列表文件包含指定密钥文件URI的EXT-X-KEY标签，则客户端设备获得密钥文件并且使用密钥文件内的密钥来对跟随在EXT-X-KEY标签之后的媒体文件解密，直到遇到另一 EXT-X-KEY标签为止。
[0138]在一个实施例中，客户端设备利用与先前使用的相同的URI来下载播放列表文件。从而，如果对播放列表文件作出了改变，则客户端设备可使用经更新的播放列表文件来取回媒体文件并且基于这些媒体文件提供输出。
[0139]对播放列表文件的改变例如可包括删除去到媒体文件的UR1、添加去到新媒体文件的URI，用去到替代媒体文件的URI来替代。当对播放列表文件作出改变时，可更新一个或多个标签以反映(一个或多个)改变。例如，如果对媒体文件的改变导致对播放列表文件所指示的媒体文件的回放的持续时间的改变，则可更新持续时间标签。
[0140]图3B是客户端设备利用多个比特率支持内容的流传输的技术的一个实施例的流程图，这是替换流的一种形式。图3B的示例是按照HTTP来提供的；然而，以类似的方式可以利用其他非流传输协议。
[0141]客户端设备在操作370中可请求播放列表文件。如上所述，可利用提供给客户端设备的URI来取回播放列表文件。在一个实施例中，播放列表文件包括媒体文件的变体流的列表来以不同的比特率提供相同的内容；换言之，单个播放列表文件包括关于每个变体流的媒体文件的URI。图3B中所示的示例使用此实施例。在另一实施例中，变体流可由分开提供给客户端的、各自以不同比特率提供相同内容的多个不同的播放列表文件表示，并且一变体播放列表对于这些不同的播放列表文件中的每一个可提供一 URI。这允许客户端设备基于客户端条件来选择比特率。
[0142]在操作375中客户端设备可取回(一个或多个)播放列表文件。在操作380中(一个或多个)播放列表文件可被存储在客户端设备存储器中。客户端设备可基于当前的网络连接速度来选择在操作385中要使用的比特率。在操作390中利用播放列表文件中包括的与所选比特率相对应的URI来向服务器请求媒体文件。取回的媒体文件可被存储在客户端设备存储器中。在操作394中客户端设备利用媒体文件提供输出，并且客户端设备确定是否改变比特率。
[0143]在一个实施例中，客户端设备最初选择最低可用比特率。在播放媒体的同时，客户端设备可监视可用带宽(例如当前网络连接比特率)以确定可用带宽是否支持使用更高比特率来回放。如果是，则客户端设备可选择更高比特率并访问由更高比特率媒体播放列表文件所指示的媒体文件。也可支持相反的情况。如果回放消耗了太多带宽，则客户端设备可选择更低比特率并访问由更低比特率媒体播放列表文件所指示的媒体文件。
[0144]如果客户端设备在操作394中例如响应于可用带宽的变化或者响应于用户输入而改变了比特率，则客户端设备在操作385中可选择不同的比特率。在一个实施例中，为了选择不同的比特率，客户端设备可利用播放列表文件中包括的与新选择的比特率相对应的URI的不同列表。在一个实施例中，客户端设备可在访问播放列表内的媒体文件期间改变比特率。
[0145]如果在操作394中比特率不变化，则客户端设备确定在当前播放列表中是否有任何更多的尚未被取回并呈现的未播放的媒体文件。如果存在这样的媒体文件，则处理返回到操作390，并且一个或多个媒体文件被利用播放列表中关于这些文件的URI来取回。如果没有这样的媒体文件(即，当前播放列表中的所有媒体文件都已被播放)，则处理前进到操作396，在该操作中确定播放列表是否包括结束标签。如果包括，则节目的回放已结束并且该过程完成；如果不包括，则处理返回到操作370，并且客户端设备请求重加载关于该节目的播放列表，并且该过程重复进行图3B中所示的方法。
[0146]图4是服务器流代理的一个实施例的框图。将会理解，服务器流代理400的元件可分布在若干个服务器设备上。例如，第一服务器设备可包括分段器430、索引器440和安保机构450，但不包括文件服务器460，而第二服务器设备可包括第一服务器450，但不包括分段器430、索引器440和安保机构450。在此示例中，第一服务器设备将准备播放列表和媒体文件，但不会将它们发送到客户端设备，而一个或多个第二服务器设备将接收并可选地存储播放列表和媒体文件，并且将把播放列表和媒体文件发送到客户端设备。服务器流代理400包括实现逻辑功能控制以引导服务器流代理400的操作的控制逻辑410，以及与引导服务器流代理400的操作相关联的硬件。逻辑可以是硬件逻辑电路或者软件例程或固件。在一个实施例中，服务器流代理400包括一个或多个应用412，这些应用412表示向控制逻辑410提供指令的代码序列和/或程序。[0147]服务器流代理400包括存储器414，该存储器414表示存储器设备或者对存储器资源的访问，用于存储数据或指令。存储器414可包括服务器流代理400本地的存储器，以及/或者包括服务器流代理400所驻留在的主机系统的存储器。服务器流代理400还包括一个或多个接口 416，这些接口 416表示关于服务器流代理400外部的实体(电子的或人类的)的去往/来自服务器流代理400的访问接口(输入/输出接口)。
[0148]服务器流代理400还可包括服务器流弓I擎420，该服务器流弓I擎420表示使得服务器流代理400能够提供如这里所述的实时或近实时流传输的一个或多个功能。图4的示例提供了可包括在服务器流引擎420中的若干个组件；然而，也可包括不同的或额外的组件。在提供流传输环境时可涉及的示例组件包括分段器430、索引器440、安保机构450和文件服务器460。这些组件中的每一个还可包括其他组件来提供其他功能。这里使用的组件指的是例程、子系统等等，无论是以硬件、软件、固件还是其某种组合实现的。
[0149]分段器430把要提供的内容划分成媒体文件，这些媒体文件可利用Web服务器协议(例如HTTP)作为文件来传送。例如，分段器430可将内容划分成采取预定文件格式的预定的固定大小数据块。
[0150]索引器440可提供一个或多个播放列表文件，这些播放列表文件提供去到由分段器430创建的媒体文件的地址或URI。索引器440例如可创建一个或多个文件，这些文件具有与由分段器430创建的每个文件相对应的标识符的有序列表。这些标识符可由分段器430或索引器440来创建或指派。索引器440还可在播放列表文件中包括一个或多个标签以支持对媒体文件的访问和/或利用。
[0151]安保机构450可提供安保特征(例如加密)，例如上文论述的那些。Web服务器460可提供与将存储在主机系统上的文件提供给远程客户端设备有关的Web服务器功能。Web服务器460可支持例如遵从HTTP的协议。
[0152]图5是客户端流代理的一个实施例的框图。将会理解，客户端流代理的元件可分布在若干个客户端设备上。例如，第一客户端设备可包括组装器530和安保机构550并且可将经解密的媒体文件流提供给第二客户端设备，该第二客户端设备包括输出生成器540(但不包括组装器530和安保机构550)。在另一示例中，主客户端设备可取回播放列表并将它们提供给次客户端设备，该次客户端设备取回播放列表中指定的媒体文件并且生成输出以呈现这些媒体文件。客户端流代理500包括实现逻辑功能控制以引导客户端流代理500的操作的控制逻辑510，以及与引导客户端流代理500的操作相关联的硬件。逻辑可以是硬件逻辑电路或者软件例程或固件。在一个实施例中，客户端流代理500包括一个或多个应用512，这些应用512表示向控制逻辑510提供指令的代码序列或程序。
[0153]客户端流代理500包括存储器514，该存储器514表示存储器设备或者对存储器资源的访问，用于存储数据和/或指令。存储器514可包括客户端流代理500本地的存储器，以及/或者包括客户端流代理500所驻留在的主机系统的存储器。客户端流代理500还包括一个或多个接口 516，这些接口 516表示关于客户端流代理500外部的实体(电子的或人类的)的去往/来自客户端流代理500的访问接口(输入/输出接口)。
[0154]客户端流代理500还可包括客户端流引擎520，该客户端流引擎520表示使得客户端流代理500能够提供如这里所述的实时或近实时流传输的一个或多个功能。图5的示例提供了可包括在客户端流引擎520中的若干个组件；然而，也可包括不同的或额外的组件。在提供流传输环境时可涉及的示例组件包括组装器530、输出生成器540和安保机构550。这些组件中的每一个还可包括其他组件来提供其他功能。这里使用的组件指的是例程、子系统等等，无论是以硬件、软件、固件还是其某种组合实现的。
[0155]组装器530可利用从服务器接收的播放列表文件来经由Web服务器协议(例如HTTP)从服务器访问媒体文件。在一个实施例中，组装器530可使得播放列表文件中的URI所指示的媒体文件被下载。组装器530可响应播放列表文件中包括的标签。
[0156]输出生成器540可提供接收到的媒体文件作为主机系统上的音频或视觉输出(或者音频和视觉两者)。输出生成器540例如可使得音频被输出到一个或多个扬声器并且视频被输出到显示设备。安保机构550可提供安保特征，例如上文论述的那些。
[0157]图6图不了具有多个标签的播放列表文件的一个实施例。图6的不例播放列表包括特定数目和排序的标签。这只是出于描述目的提供的。一些播放列表文件可包括更多、更少或不同组合的标签，并且标签可按与图6中所示不同的顺序布置。
[0158]开始标签610可指示播放列表文件的开始。在一个实施例中，开始标签610是#EXTM3U标签。持续时间标签620可指示回放列表的持续时间。也就是说，回放列表600所指示的媒体文件的回放的持续时间。在一个实施例中，持续时间标签620是EXT-X-TARGETDURATION标签；然而，也可使用其他标签。
[0159]日期/时间标签625可提供与回放列表600所指示的媒体文件所提供的内容的日期和时间有关的信息。在一个实施例中，日期/时间标签625是EXT-X-PROGRAM-DATE-HME标签；然而，也可使用其他标签。序列标签630可指示播放列表文件600在播放列表的序列中的顺序。在一个实施例中，序列标签630是EXT-X-MEDIA-SEQUENCE标签；然而，也可使用其他标签。
[0160]安保标签640可提供与向播放列表文件600所指示的媒体文件应用的安保和/或加密有关的信息。例如，安保标签640可指定用来对媒体文件指示符所指定的文件解密的解密密钥。在一个实施例中，安保标签640是EXT-X-KEY标签；然而，也可使用其他标签。变体列表标签645可指示播放列表600是否提供变体流以及与变体流有关的信息(例如，有多少个、比特率)。在一个实施例中，变体列表标签645是EXT-X-STREAM-1NF标签。
[0161]媒体文件指示符650可提供与要播放的媒体文件有关的信息。在一个实施例中，媒体文件指示符650包括去到要播放的多个媒体文件的URI。在一个实施例中，播放列表600中的URI的顺序对应于应当访问和/或播放媒体文件的顺序。后续播放列表指示符660可提供与在播放列表文件600之后要使用的一个或多个播放列表文件有关的信息。在一个实施例中，后续播放列表指示符660可包括去到在播放了播放列表600的媒体文件之后要使用的一个或多个播放列表文件的URI。
[0162]存储器标签670可指示在媒体文件内容的回放之后客户端设备是否可存储媒体文件和/或可存储多久。在一个实施例中，存储器标签670是EXT-X-ALLOW-CACHE标签。结束标签680指不播放列表文件600是否是用于呈现的最后一个播放列表文件。在一个实施例中，结束标签680是EXT-X-ENDLIST标签。
[0163]以下部分包含根据一个实施例的若干个示例播放列表文件。
[0164]简单的播放列表文件#EXTM3U
[016 5]
【权利要求】
1.一种存储可执行程序指令的机器可读非暂态存储介质，所述指令在被数据处理系统执行时使得该数据处理系统执行一种方法，所述方法包括: 接收关于节目的变体音频播放列表，所述变体音频播放列表包含关于所述节目的不同音频内容的一组URL，所述一组URL中的每个URL涉及与所述节目的不同音频内容之一相对应的音频播放列表； 选择所述一组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，所述第一 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的装置，所述第一URL涉及第一播放列表； 用于发送涉及所述第一播放列表的所述第一 URL的装置； 用于接收所述第一播放列表的装置；以及 用于处理所述第一播放列表以取回所述节目的音频内容的装置。
16.一种存储可执行程序指令的机器可读非暂态存储介质，所述指令在被数据处理系统执行时使得所述数据处理系统执行一种方法，所述方法包括: 响应于来自设备的对于节目的请求而发送变体音频播放列表，所述变体音频播放列表包含关于所述节目的不同音频内容的一组URL，所述一组URL中的每个URL涉及与所述节目的不同音频内容之一相对应的音频播放列表； 从所述设备接收所述一组URL中的第一 URL并且响应于接收到所述第一 URL而向所述设备发送第一音频播放列表，所述第一 URL涉及所述第一音频播放列表。
17.如权利要求16所述的介质，其中，所述方法还包括: 响应于来自所述设备的所述请求，发送关于所述节目的视频播放列表，所述视频播放列表包含关于所述节目的视频内容的URL，每个关于视频内容的URL涉及所述视频内容的时间上的一部分。
18.如权利要求17所述的介质，其中，所述方法还包括: 从所述设备接收所述一组URL中的关于不同音频内容的第二 URL ； 响应于接收到所述第二 URL而发送第二音频播放列表，其中所述第二 URL涉及所述第二音频播放列表并且所述第二音频播放列表提供所述节目的替换音频内容。
19.如权利要求18所述的介质，其中，通过所述第一音频播放列表取回的音频内容中的时间戳和所述替换音频内容中的时间戳指定相同时间段。
20.—种由机器实现的方法,包括: 响应于来自设备的对于节目的请求而发送变体音频播放列表，所述变体音频播放列表包含关于所述节目的不同音频内容的一组URL，所述一组URL中的每个URL涉及与所述节目的不同音频内容之一相对应的音频播放列表； 从所述设备接收所述一组URL中的第一 URL并且响应于接收到所述第一 URL而向所述设备发送第一音频播放列表，所述第一 URL涉及所述第一音频播放列表。
21.如权利要求20所述的方法，其中，所述方法还包括: 响应于来自所述设备的所述请求，发送关于所述节目的视频播放列表，所述视频播放列表包含关于所述节目的视频内容的URL，每个关于视频内容的URL涉及所述视频内容的时间上的一部分。
22.如权利要求21所述的方法，其中，所述方法还包括: 从所述设备接收所述一组URL中的关于不同音频内容的第二 URL ； 响应于接收到所述第二 URL而发送第二音频播放列表，其中所述第二 URL涉及所述第二音频播放列表并且所述第二音频播放列表提供所述节目的替换音频内容。
23.如权利要求22所述的方法，其中，通过所述第一音频播放列表取回的音频内容中的时间戳和所述替换音频内容中的时间戳指定相同时间段。
24.—种数据处理系统，包括: 用于响应于来自设备的对于节目的请求而发送变体音频播放列表的装置，所述变体音频播放列表包含关于所述节目的不同音频内容的一组URL，所述一组URL中的每个URL涉及与所述节目的不同音频内容之一相对应的音频播放列表； 用于从所述设备接收所述一组URL中的第一 URL并且响应于接收到所述第一 URL而向所述设备发送第一音频播放列表的装置，所述第一 URL涉及所述第一音频播放列表。
【文档编号】H04N21/485GK103583051SQ201280027150
【公开日】2014年2月12日 申请日期:2012年5月30日 优先权日:2011年6月3日
【发明者】R·潘特斯, D·彼得曼, W·梅, C·弗利克, J·S·布谢尔, J·K·卡尔霍恩 申请人:苹果公司