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

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所述的方法，其中，通过所述第一音频播放列表取回的音频内容中的时间戳和所述替换音频内容中的时间戳指定相同时间段。

用于实时或近实时流传输的播放列表\n[0001] 相关申请\n[0002] 本申请根据35U.S.C.§119(e)要求2011年6月3日递交的61/493,324号美国临时申\n请的申请日的权益。本美国专利申请还与以下美国专利申请相关，这里通过引用并入每个以下美国专利申请：\n[0003] （1）2009年6月5日递交的题为“REAL-TIME OR NEAR REAL-TIME STREAMING”的12/\n479,690号申请（案卷号P7437US1）；\n[0004] （2）2009年6月5日递交的题为“VARIANT STREAMS FOR REAL-TIME OR NEAR REAL-TIME STREAMING”的12/479,698号申请（案卷号P7437US2）；\n[0005] （3）2009年6月5日递交的题为“UPDATABLE REAL-TIME OR NEAR REAL-TIME \nSTREAMING”的12/479,732号申请（案卷号P7437US3）；以及\n[0006] （4）2009年6月5日递交的题为“PLAYLISTS FOR REAL-TIME OR NEAR REAL-TIME STREAMING”的12/479,735号申请（案卷号P7437US4）。\n技术领域\n[0007] 本发明的实施例涉及数据传送技术。更具体而言，本发明的实施例涉及允许利用非流传输协议——例如超文本传送协议（HyperText Transfer Protocol，HTTP）——对数据进行流传输（streaming）的技术。\n背景技术\n[0008] 内容的流传输一般指的是被不断地从服务器设备发送并被客户端设备接收的多\n媒体内容。内容通常在其被流传输服务器递送的同时被呈现给最终用户。该名称指的是媒体的递送方法而不是媒体本身。\n[0009] 当前的流传输服务一般要求专门的服务器来向最终用户分发“实况”内容。在任何大规模部署中，这可导致巨大的成本，并且要求专门的技能来设立和运行。这导致了可用于流传输的内容库的量达不到合乎需要的程度。\n发明内容\n[0010] 在一个实施例中，HTTP流传输系统可以使用变体播放列表，该变体播放列表标识关于同一视频节目的不同音频播放列表，例如一个是英语的，另一个是西班牙语的，而另一个是汉语的，该视频节目还具有关于视频内容的播放列表。例如，实况体育事件——例如棒球比赛——可具有从服务器发送到客户端的视频播放列表，并且同一实况体育事件可具有变体音频播放列表，该变体音频播放列表指定不同的音频播放列表，这些不同的音频播放列表对应于不同的语言或不同的覆盖角度（例如广播比赛的本地广播公司与广播该比赛的国家广播公司）。客户端设备可从服务器下载视频播放列表并且还下载变体音频播放列表，然后客户端设备可从变体音频播放列表中选择适当的音频节目并且下载与所选择的适当\n音频节目相对应的适当音频播放列表。在下载了视频播放列表和所选音频播放列表两者\n后，客户端可以开始同时地——并且在一个实施例中独立地——处理两个播放列表，以在客户端设备处创建并呈现视频和音频。\n[0011] 一个实施例中在客户端设备处的一种方法可包括以下操作：接收关于节目的变体音频播放列表，其中该变体音频播放列表包含关于节目的不同音频内容的一组URL，并且该组URL中的每个URL涉及与该节目的不同音频内容之一相对应的音频播放列表；选择该组\nURL中的关于不同音频内容之一的第一URL，该第一URL涉及第一播放列表；发送涉及第一播放列表的第一URL；接收第一播放列表；以及处理第一播放列表以取回该节目的音频内容。\n在一个实施例中，该方法还可包括确定音频偏好，并且此音频偏好可由用户设定，例如用户偏好中的设定，并且此音频偏好可引起该方法中对第一URL的选择。该方法在一个实施例中还可包括接收关于该节目的视频播放列表；该视频播放列表可包含关于该节目的视频内容的URL，并且每个关于视频内容的URL与视频内容的时间上的一部分相关联或者涉及视频内容的时间上的一部分。这个时间部分匹配在视频播放列表被处理的同时被客户端设备同时处理的音频播放列表的时间部分。该方法还可包括通过使用变体音频播放列表选择不同的音频播放列表来在关于音频内容的URL之间切换；在一个实施例中，在变体音频播放列表中的音频播放列表之间的切换可独立于视频播放列表的回放执行。该方法还可包括在一个实施例中同时且独立地处理音频播放列表和视频播放列表；例如，作为用于音频的播放器的第一软件组件可独立于处理视频播放列表的第二软件组件地处理音频播放列表。另外，在一个实施例中，音频下载模块可独立地下载并处理音频内容，同时视频下载模块可单独下载并处理视频内容。在一个实施例中，通过音频播放列表取回的音频内容中的时间戳和通过视频播放列表取回的视频内容中的时间戳指定相同时间段。另外，涉及不同音频内容的该组URL中的每个URL包括指定相同时间段的时间戳。\n[0012] 在本发明的一个实施例中由服务器设备执行的一种方法可包括响应于来自设备\n的请求而发送变体音频播放列表，该变体音频播放列表包含关于被请求的节目的不同音频内容的一组URL，其中该组URL中的每个URL涉及与该节目的不同音频内容之一相对应的音频播放列表。该方法还可包括从该设备接收该组URL中的第一URL并且响应于接收到第一\nURL而向该设备发送第一音频播放列表，其中该第一URL涉及第一音频播放列表。\n[0013] 这里描述了其他方法，并且这里还描述了机器可读非暂态存储介质，并且这里也描述了执行这些方法的系统。\n附图说明\n[0014] 在附图中以示例而非限制方式图示了本发明，附图中相似的标记指示类似的要\n素。\n[0015] 在附图中以示例而非限制方式图示了本发明，附图中相似的标记指示类似的要\n素。\n[0016] 图1是可发送和接收实时或近实时内容的服务器和客户端的一个实施例的框图。\n[0017] 图2A是一个或多个服务器设备利用非流传输协议支持媒体内容的技术的一个实\n施例的流程图。\n[0018] 图2B是一个或多个服务器设备向一个或多个客户端设备提供动态更新的播放列\n表的技术的一个实施例的流程图。\n[0019] 图2C是一个或多个服务器设备利用多个比特率向客户端设备提供媒体内容的技\n术的一个实施例的流程图。\n[0020] 图3A是客户端设备利用非流传输协议支持内容的流传输的技术的一个实施例的\n流程图。\n[0021] 图3B是客户端设备利用多个比特率支持内容的流传输的技术的一个实施例的流\n程图。\n[0022] 图4是服务器流代理的一个实施例的框图。\n[0023] 图5是客户端流代理的一个实施例的框图。\n[0024] 图6图示了具有多个标签的播放列表文件的一个实施例。\n[0025] 图7是用于如这里所述的组装流的回放技术的一个实施例的流程图。\n[0026] 图8是电子系统的一个实施例的框图。\n[0027] 图9A是示出客户端设备如何可在变体播放列表中的替换内容之间切换的示例的\n流程图。\n[0028] 图9B是示出客户端设备如何可在两个播放列表中的内容之间切换的另一流程图。\n[0029] 图9C是示出客户端设备如何可利用音频模式匹配在内容之间切换的示例的另一\n流程图。\n[0030] 图9D概略示出了如何利用音频模式匹配来实现图9C的方法。\n[0031] 图10示出了可包括关于同一节目的不同音频内容的URL的变体播放列表的示例。\n[0032] 图11是示出在一个实施例中用于使用包括关于同一节目的音频内容的变体的URL\n的变体播放列表的方法的流程图。\n[0033] 图12示出了可用于这里描述的一个或多个实施例中的具有各种组件的客户端设\n备的示例。\n[0034] 图13是示出根据一个实施例由一服务器设备或一组服务器设备执行的方法的流\n程图。\n[0035] 图14图示了在本发明的一些实施例中可使用的示范性API体系结构的框图。\n[0036] 图15示出了在本发明的一些实施例中可使用的软件栈的示范性实施例。\n具体实施方式\n[0037] 在以下说明书中，阐述了许多具体细节。然而，没有这些具体细节也可以实施本发明的实施例。在其他情况下，没有详细示出公知的电路、结构和技术，以免模糊对本说明书的理解。\n[0038] 本说明书包括受著作权保护的素材，例如对图形用户界面图像的图示。著作权所有人——包括本发明的受让人——特此保留其对这些素材的权利——包括著作权。著作权所有人不反对任何人对本专利文档或专利公开进行复制再现，因其出现在了专利商标局文件或记录中，但除此以外保留所有一切著作权。Copyright Apple Inc.2009。\n[0039] 在一个实施例中，这里描述的技术和组件可包括利用非流传输协议（例如HTTP）和其他技术（例如运动图片专家组（Motion Picture Expert Group，MPEG）流）来实现流传输体验的机制。例如，可利用HTTP来提供近实时的流传输体验，从而来广播“实况”音乐或体育事件、实况新闻、网络摄像头馈送，等等。在一个实施例中，协议可将传入的媒体数据分段成多个媒体文件并将这些分段的媒体文件存储在服务器上。协议还可构建播放列表文件，该播放列表文件包括将客户端引导至存储在服务器上的分段媒体文件的统一资源标识符\n（Uniform Resource Identifiers，URI）。当根据（一个或多个）播放列表文件来回放分段媒体文件时，客户端可向用户提供“实况”事件的近实时广播。可以以类似的方式提供预记录的内容。\n[0040] 本说明书的一个方面涉及使用为所选节目提供音频的变体的音频播放列表；例\n如，音频播放列表可以为还具有关于视频内容的播放列表的同一视频节目提供采取不同语言的不同播放列表，其中该视频播放列表与采取不同语言的音频播放列表是分开的。在结合图1至9D提供一些背景信息之后将结合图10至15描述这些方面。\n[0041] 在一个实施例中，服务器可将补充或替换的媒体内容（例如，广告、与体育事件有关的统计数据、主呈现的额外媒体内容）动态地引入到广播事件中。例如，在客户端对媒体事件的回放期间，服务器可向播放列表文件添加额外的URI，这些URI可标识客户端可下载补充媒体文件的位置。可以指令客户端周期性地从服务器取回一个或多个经更新的播放列表文件以便访问服务器引入的任何补充的或额外的（或者这两者）媒体内容。\n[0042] 在一个实施例中，服务器可在累积模式或滚动模式中操作。在累积模式中，服务器可创建播放列表文件并将媒体文件标识符附加到该播放列表文件的末尾。当单个播放列表文件被下载时，客户端随后可从该单个播放列表文件访问流的所有部分（例如，用户可从节目的中间开始）。在滚动模式中，服务器可通过以滚动方式从播放列表文件的开头去除媒体文件标识符来限制媒体文件的可用性，从而提供客户端设备可访问的媒体内容的滑动窗\n口。服务器还可向播放列表添加媒体文件标识符，并且在滚动模式中，服务器可将媒体文件的可用性限制于最近添加到播放列表的那些。客户端随后反复地下载播放列表文件的经更新的拷贝以继续观看。播放列表下载的滚动方式在内容可能在时间上是无限的时（例如，来自连续操作的网络摄像头的内容）可能是有用的。客户端可继续以滚动模式反复请求播放列表，直到其在播放列表中发现结束标签为止。\n[0043] 在一个实施例中，该机制通过提供同一呈现的变体流来支持比特率切换。例如，要提供的呈现的若干个版本可被存储在服务器上。每个版本可具有基本上相同的内容，但是以不同的比特率编码的。这可允许客户端设备依据例如对可用带宽的检测来在比特率之间切换，而不会损害回放的连续性。\n[0044] 在一个实施例中，可提供保护特征来保护内容免遭未经授权的使用。例如，可以使用非顺序式媒体文件编号来防止预测。可以使用媒体文件的加密。可使用部分媒体文件列表。也可提供额外的和/或不同的保护特征。\n[0045] 图1是可发送和接收实时或近实时内容的服务器和客户端的一个实施例的框图。\n图1的示例提供简单的服务器-客户端连接，其中两个客户端经由网络与服务器耦合。利用这里描述的技术和机制可支持任何数目的客户端。另外，根据这里描述的技术和机制，多个服务器可提供内容和/或可一起操作来提供内容。例如，一个服务器可创建内容，创建播放列表并且创建多个媒体（例如文件），并且其他服务器存储并发送创建的内容。\n[0046] 网络110可以是任何类型的网络，无论是有线的、无线的（例如，IEEE802.11、\n802.16）还是其任何组合。例如，网络100可以是因特网或内联网。作为另一示例，网络110可以是蜂窝网络（例如，3G、CDMA）。在一个实施例中，客户端设备150和180可能够通过多种网络类型通信（例如，每个设备可通过WiFi无线LAN通信，并且也可通过无线蜂窝电话网络通信）。例如，客户端设备150和180可以是能够通过蜂窝无线电电话网络以及数据网络通信的智能电话或者具备蜂窝能力的个人数字助理。这些设备可能够在任一类型的网络上利用这里描述的流传输机制或者甚至根据需要在网络之间切换。\n[0047] 服务器120可以以本领域中已知的任何方式作为HTTP服务器操作。也就是说，服务器120包括利用HTTP协议提供内容的HTTP服务器代理145。虽然图1的示例是按照HTTP来描述的，但可以以类似的方式利用其他协议。分段器130和索引器135是驻留在服务器120（或多个服务器）上来如这里所述利用播放列表文件在媒体文件中提供内容的代理。可利用\nHTTP协议经由HTTP服务器代理145（或经由其他服务器）通过网络110提供这些媒体文件和播放列表文件。这里论述的代理可实现为硬件、软件、固件或其组合。\n[0048] 分段器130可具有将媒体数据的流划分成可经由HTTP协议传送的多个媒体文件的\n功能。索引器135可具有如下功能：创建与分段媒体文件相对应的播放列表文件，以使得客户端设备可重组装这些媒体文件来提供由服务器120提供的内容的实时或近实时传送。响应于来自客户端设备的一个或多个请求，HTTP服务器代理145（或其他服务器）可发送由索引器135生成的一个或多个播放列表文件和由分段器130生成的内容的媒体文件。服务器\n120还可包括可选的安保代理140，该安保代理140提供一个或多个这里论述的安保功能（例如加密）。服务器120还可包括图1中未示出的额外组件。\n[0049] 客户端设备150和180可通过网络110接收来自服务器120的播放列表文件和媒体\n文件。客户端设备可以是能够接收通过网络传送的数据并且利用经由网络接收的数据来生成输出的任何类型的电子设备，例如无线移动设备、PDA、娱乐设备、消费电子设备，等等。该输出可以是任何媒体类型或媒体类型的组合，例如包括音频、视频或其任何组合。\n[0050] 客户端设备150可包括组装器代理160和输出生成器代理165。类似地，客户端设备\n180可包括组装器代理190和输出生成器代理195。组装器代理160和180从服务器120接收播放列表文件并且使用这些播放列表文件来从服务器120访问和下载媒体文件。输出生成器代理165和195使用下载的媒体文件来分别生成从客户端设备150和160的输出。该输出可由一个或多个扬声器、一个或多个显示屏、扬声器和显示屏的组合或者任何其他输入或输出设备来提供。客户端设备还可包括存储器（例如闪存或DRAM等等）以充当在媒体文件被接收到时存储媒体文件（例如经压缩的媒体文件或者经解压缩的媒体文件）的缓冲器；缓冲器可提供超出当前正在呈现的内容的时间以外的许多秒的可呈现内容，从而使得缓冲的内容随后可在新内容被下载的同时被显示。此缓冲器可在客户端设备正尝试通过间歇性缓慢的网络连接取回内容的同时提供可呈现内容，因此缓冲器可隐藏网络延迟或连接问题。\n[0051] 客户端设备150和180还可分别包括可选的安保代理170和185，这些安保代理提供一个或多个这里论述的安保功能。客户端设备150和180还可包括图1中未示出的额外组件。\n[0052] 在一个实施例中，本申请中描述的技术可用于通过非流传输协议（例如HTTP）传送无限的多媒体数据流。实施例还可包括媒体数据的加密和/或流的替换版本的提供（例如，提供替换比特率）。因为媒体数据可在创建之后很快被发送，所以数据可被近实时地接收。\n提供了文件的示例数据格式以及多媒体数据的流的服务器（发送者）和客户端（接收者）要采取的动作；然而，也可支持其他格式。\n[0053] 可作为仿真的实时流（或近实时流）传送的媒体呈现由指示播放列表文件的统一资源标识符（URI）指定。在一个实施例中，播放列表文件是额外URI的有序列表。播放列表文件中的每个URI涉及作为流的片段的媒体文件，该流可以是特定节目的媒体数据的单个连续流。\n[0054] 为了播放媒体数据的流，客户端设备从服务器获得播放列表文件。客户端还获得并播放由播放列表文件指示的每个媒体数据文件。在一个实施例中，客户端可动态地或反复地重加载播放列表文件以发现额外的和/或不同的媒体片段。\n[0055] 播放列表文件例如可以是扩展M3U播放列表文件。在一个实施例中，使用有效地扩展M3U格式的额外标签。M3U指的是运动图片专家组音频第3层统一资源定位符（Moving \nPicture Experts Group Audio Layer3Uniform Resource Locator，MP3URL），并且是用于存储多媒体播放列表的格式。M3U文件是包含供媒体播放器播放的一个或多个媒体文件的位置的文本文件。\n[0056] 播放列表文件在一个实施例中是由个体行组成的扩展M3U格式的文本文件。这些\n行可终止于单个LF字符或者CR字符后跟LF字符。每一行可以是URI、空白行或者以注释字符（例如“#”）开始。URI标识要播放的媒体文件。空白行可被忽略。\n[0057] 以注释字符开始的行可以是注释或标签。标签可开始于#EXT，而注释行可开始\n于#。注释行通常被服务器和客户端忽略。在一个实施例中，播放列表文件是以UTF-8格式编码的。UTF-8（8比特统一码变换格式）是可变长度字符编码格式。在替换实施例中，可以使用其他字符编码格式。\n[0058] 在接下来的示例中，利用包括如下两个标签的扩展M3U格式：EXTM3U和EXTINF。扩展M3U文件可通过包括“#EXTM3U”的第一行与基本M3U文件相区分。\n[0059] EXTINF是描述由跟随在该标签之后的URI标识的媒体文件的记录标记。在一个实\n施例中，每个媒体文件URI之前是EXTINF标签，例如：\n[0060] #EXTINF:,