实时或准实时流传输.pdf

本发明涉及实时或准实时流传输。方法和设备使用传输协议如HTTP兼容协议提供在一个或多个播放列表中指定的内容的实时或准实时流传输。在一实施例中，一种方法可在客户端设备上执行一用户应用以呈现媒体文件并控制所述媒体文件的呈现。所述方法可进一步在所述客户端设备上运行一媒体服务进程以取回指定所述媒体文件的播放列表以及所述媒体文件可用的媒体源，从所述媒体源取回所述媒体文件，并对取回的所述媒体文件进行解码。为了获获取自定义URL所引用的对象，所述媒体服务进程可调用所述用户应用以处理所述自定义URL。

权利要求书一种客户端设备执行的方法，所述方法包括：执行用户应用以呈现媒体文件并控制所述媒体文件的呈现；以及运行媒体服务进程，独立于所述用户应用，以取回指定所述媒体文件的播放列表以及所述媒体文件可用的媒体源，从所述媒体源取回所述媒体文件，并对取回的所述媒体文件进行解码以及将来自所述媒体文件的解码内容提供给所述用户应用。根据权利要求1所述的方法，其中所述媒体服务进程和所述用户应用对存储器控制、存储器空间、存储器分配、文件系统控制和网络控制共享相同的特权。根据权利要求2所述的方法，其中所述用户应用提供用户界面以控制所述呈现并且通过应用编程接口（API）与所述媒体服务进程通信，并且其中所述用户应用和所述媒体服务进程是不同的软件进程。根据权利要求2所述的方法，其中所述媒体服务进程取回媒体文件，所述媒体文件是使用由所述用户应用处理或者由所述用户应用取回并处理的密钥进行解码的。根据权利要求2所述的方法，其中所述用户应用安装客户端证书，所述证书用于在创建连接以下载解密密钥时应答服务器的询问。根据权利要求2所述的方法，其中所述播放列表包含使用自定义URL方案的解密密钥的URL。根据权利要求3所述的方法，其中当所述媒体服务进程加载或解码媒体文件失败时，所述媒体服务进程通过所述API调用所述用户应用以使得所述用户应用取回一个或多个返回到所述媒体服务进程的密钥。根据权利要求3所述的方法，其中所述媒体服务进程取回媒体文件，所述媒体文件是使用由所述用户应用处理或者由所述用户应用取回并处理的密钥进行解码的。根据权利要求8所述的方法，其中所述用户应用安装客户端证书，所述证书用于在创建连接以下载解密密钥时应答服务器的询问。根据权利要求9所述的方法，其中所述播放列表包含使用自定义URL方案的解密密钥的URL。一种由数据处理系统执行的机器实现的方法，所述方法包括：在客户端设备上执行用户应用以呈现媒体文件并控制所述媒体文件的呈现；以及在所述客户端设备上运行媒体服务进程，独立于所述用户应用，以取回指定所述媒体文件的播放列表以及所述媒体文件可用的媒体源，从所述媒体源取回所述媒体文件，并对取回的所述媒体文件进行解码；通过所述媒体服务器接收URL，所述URL涉及所述媒体服务器使用的用于解码或呈现至少一个所述媒体文件的数据；由所述媒体服务器调用所述用户应用以处理所述URL来获得所述媒体服务器要使用的所述数据；响应于所述用户应用处理所述URL而接收所述数据，从而获得所述数据；以及使用所述数据解码至少一个所述媒体文件。根据权利要求11所述的方法，其中所述数据是解密密钥。根据权利要求11所述的方法，其中所述用户应用使用自定义URL，所述自定义URL用于保护通过所述用户应用提供的内容。根据权利要求13所述的方法，其中注册表存储所述自定义URL和所述用户应用之间的关系，并且其中当所述媒体服务器不能解码媒体文件时，所述媒体服务器检查所述注册表以调用所述用户应用。根据权利要求14所述的方法，其中所述自定义URL由EXT‑X‑KEY标签指定，并且其中所述用户应用由所述媒体文件的提供者授权。根据权利要求15所述的方法，其中所述用户应用将自定义URL和所述用户应用之间的关系安装到注册表中，所述自定义URL用于为所述媒体文件取回一个或多个解密密钥，并且其中当所述用户应用第一次被安装或第一次被启动时，所述用户应用将所述关系安装到所述注册表中。根据权利要求13所述的方法，其中所述自定义URL不被所述媒体服务器所支持。根据权利要求13所述的方法，其中所述自定义URL用于取回被提供给所述媒体服务器以对所述播放列表中的所述媒体文件进行解码的所述解密密钥。根据权利要求18所述的方法，其中所述用户应用对所述自定义URL的解析取决于如下条件中的至少一个：（a）所述用户应用的对于所述媒体文件中的内容的特权等级；（b）所述媒体文件中的内容；以及（c）呈现所述媒体文件中的内容的请求的日期或时间或日期和时间。根据权利要求19所述的方法，其中所述解密密钥通过所述用户应用被返回给所述媒体服务器。一种由数据处理系统执行的机器实现的方法，所述方法包括：在客户端设备上执行用户应用，所述用户应用被配置以控制所述媒体文件的呈现；以及在所述客户端设备上运行媒体服务进程，独立于所述用户应用，以取回指定所述媒体文件的播放列表以及所述媒体文件可用的媒体源，从所述媒体源取回所述媒体文件，并对取回的所述媒体文件进行解码；通过所述媒体服务器接收在所述播放列表中或用于所述播放列表的URL，所述URL涉及被用于处理至少一个所述媒体文件的数据；由所述媒体服务器调用所述用户应用以处理所述URL来获取远程媒体服务器要使用的数据；响应于所述用户应用处理所述URL而接收所述数据，从而获得所述数据；以及传输所述数据到所述远程媒体服务器。根据权利要求21所述的方法，其中所述URL是所述播放列表中的一个的自定义URL或者是所述播放列表中的至少一个媒体文件的解密密钥，并且其中所述用户应用使用所述自定义URL来保护通过所述用户应用提供的内容。根据权利要求21所述的方法，其中注册表存储所述自定义URL和所述用户应用之间的关系，并且其中当所述媒体服务器不能处理所述URL时，所述媒体服务器检查所述注册表以调用所述用户应用。根据权利要求23所述的方法，其中所述远程媒体服务器是机顶盒的一部分，并且被配置成取回和处理播放列表，并被配置成产生被传输回所述媒体服务器的消息，以请求对所述自定义URL的解析，并且其中传输数据到所述远程媒体服务器提供了对所述自定义URL的解析。一种客户端设备，所述客户端设备包括：用于执行用户应用以呈现媒体文件并控制所述媒体文件的呈现的装置；以及用于运行媒体服务进程，独立于所述用户应用，以取回指定所述媒体文件的播放列表以及所述媒体文件可用的媒体源，从所述媒体源取回所述媒体文件，并对取回的所述媒体文件进行解码以及将来自所述媒体文件的解码内容提供给所述用户应用的装置。根据权利要求25所述的客户端设备，其中所述媒体服务进程和所述用户应用对存储器控制、存储器空间、存储器分配、文件系统控制和网络控制共享相同的特权。根据权利要求26所述的客户端设备，其中所述用户应用提供用户界面以控制所述呈现并且通过应用编程接口（API）与所述媒体服务进程通信，并且其中所述用户应用和所述媒体服务进程是不同的软件进程。根据权利要求26所述的客户端设备，其中所述媒体服务进程取回媒体文件，所述媒体文件是使用由所述用户应用处理或者由所述用户应用取回并处理的密钥进行解码的。根据权利要求26所述的客户端设备，其中所述用户应用安装客户端证书，所述证书用于在创建连接以下载解密密钥时应答服务器的询问。根据权利要求26所述的客户端设备，其中所述播放列表包含使用自定义URL方案的解密密钥的URL。根据权利要求27所述的客户端设备，其中当所述媒体服务进程加载或解码媒体文件失败时，所述媒体服务进程通过所述API调用所述用户应用以使得所述用户应用取回一个或多个返回到所述媒体服务进程的密钥。根据权利要求27所述的客户端设备，其中所述媒体服务进程取回媒体文件，所述媒体文件是使用由所述用户应用处理或者由所述用户应用取回并处理的密钥进行解码的。根据权利要求32所述的客户端设备，其中所述用户应用安装客户端证书，所述证书用于在创建连接以下载解密密钥时应答服务器的询问。根据权利要求33所述的客户端设备，其中所述播放列表包含使用自定义URL方案的解密密钥的URL。一种数据处理系统，所述数据处理系统包括客户端设备和媒体服务器，其中，所述客户端设备包括：用于执行用户应用以呈现媒体文件并控制所述媒体文件的呈现的装置；以及用于运行媒体服务进程，独立于所述用户应用，以取回指定所述媒体文件的播放列表以及所述媒体文件可用的媒体源，从所述媒体源取回所述媒体文件，并对取回的所述媒体文件进行解码的装置；以及所述媒体服务器包括：用于接收URL的装置，所述URL涉及所述媒体服务器使用的用于解码或呈现至少一个所述媒体文件的数据；用于调用所述用户应用以处理所述URL来获得所述媒体服务器要使用的所述数据的装置；其中，所述客户端设备还包括：用于响应于所述用户应用处理所述URL而接收所述数据，从而获得所述数据的装置；以及用于使用所述数据解码至少一个所述媒体文件的装置。根据权利要求35所述的数据处理系统，其中所述数据是解密密钥。根据权利要求35所述的数据处理系统，其中所述用户应用使用自定义URL，所述自定义URL用于保护通过所述用户应用提供的内容。根据权利要求37所述的数据处理系统，其中注册表存储所述自定义URL和所述用户应用之间的关系，并且其中当所述媒体服务器不能解码媒体文件时，所述媒体服务器检查所述注册表以调用所述用户应用。根据权利要求38所述的数据处理系统，其中所述自定义URL由EXT‑X‑KEY标签指定，并且其中所述用户应用由所述媒体文件的提供者授权。根据权利要求39所述的数据处理系统，其中所述用户应用将自定义URL和所述用户应用之间的关系安装到注册表中，所述自定义URL用于为所述媒体文件取回一个或多个解密密钥，并且其中当所述用户应用第一次被安装或第一次被启动时，所述用户应用将所述关系安装到所述注册表中。根据权利要求37所述的数据处理系统，其中所述自定义URL不被所述媒体服务器所支持。根据权利要求37所述的数据处理系统，其中所述自定义URL用于取回被提供给所述媒体服务器以对所述播放列表中的所述媒体文件进行解码的所述解密密钥。根据权利要求42所述的数据处理系统，其中所述用户应用对所述自定义URL的解析取决于如下条件中的至少一个：（a）所述用户应用的对于所述媒体文件中的内容的特权等级；（b）所述媒体文件中的内容；以及（c）呈现所述媒体文件中的内容的请求的日期或时间或日期和时间。根据权利要求43所述的数据处理系统，其中所述解密密钥通过所述用户应用被返回给所述媒体服务器。一种数据处理系统，所述数据处理系统包括客户端设备和媒体服务器，其中，所述客户端设备包括：用于执行用户应用的装置，所述用户应用被配置以控制所述媒体文件的呈现；以及用于运行媒体服务进程，独立于所述用户应用，以取回指定所述媒体文件的播放列表以及所述媒体文件可用的媒体源，从所述媒体源取回所述媒体文件，并对取回的所述媒体文件进行解码的装置；并且所述媒体服务器包括：用于接收在所述播放列表中或用于所述播放列表的URL的装置，所述URL涉及被用于处理至少一个所述媒体文件的数据；用于调用所述用户应用以处理所述URL来获取远程媒体服务器要使用的数据的装置，其中所述客户端设备还包括：用于响应于所述用户应用处理所述URL而接收所述数据，从而获得所述数据的装置；以及用于传输所述数据到所述远程媒体服务器的装置。根据权利要求45所述的数据处理系统，其中所述URL是所述播放列表中的一个的自定义URL或者是所述播放列表中的至少一个媒体文件的解密密钥，并且其中所述用户应用使用所述自定义URL来保护通过所述用户应用提供的内容。根据权利要求45所述的数据处理系统，其中注册表存储所述自定义URL和所述用户应用之间的关系，并且其中当所述媒体服务器不能处理所述URL时，所述媒体服务器检查所述注册表以调用所述用户应用。根据权利要求47所述的数据处理系统，其中所述远程媒体服务器是机顶盒的一部分，并且被配置成取回和处理播放列表，并被配置成产生被传输回所述媒体服务器的消息，以请求对所述自定义URL的解析，并且其中传输数据到所述远程媒体服务器提供了对所述自定义URL的解析。

说明书实时或准实时流传输
本申请是2011年4月7日提交的发明名称为“实时或准实时流传输”的中国专利申请201110141675.4的分案申请。
相关申请
本申请要求享有如下美国临时申请的申请日：于2010年4月7日申请的美国临时申请61/321,767（档案号为No.P7437Z8）以及于2010年6月4日申请的美国临时申请61/351,824的（档案号为No.P7437Z9），并且，本申请据此通过引用将那些临时申请结合于此。本申请还与如下专利申请相关：
（1）于2008年12月31日申请的申请号为No.61/142,110的申请（档案号为No.P7437Z）；
（2）于2009年3月16日申请的申请号为No.61/160,693的申请（档案号为No.P7437Z2）；
（3）于2009年3月17日申请的申请号为No.61/161,036的申请（档案号为No.P7437Z3）；
（4）于2009年4月7日申请的申请号为No.61/167,524的申请（档案号为No.P7437Z4）；
（5）于2009年9月8日申请的申请号为No.61/240,648的申请（档案号为No.P7437Z5）；
（6）于2009年12月21日申请的申请号为No.61/288,828的申请（档案号为No.P7437Z6）；
（7）于2010年4月1日申请的申请号为No.61/320,213的申请（档案号为No.P7437Z7）。所有这些美国临时申请都以参考的方式结合于此，该结合以符合本公开为限。
本美国专利申请涉及如下美国专利申请，其中每一个都通过引用结合与此，该结合以符合本公开为限：
（1）申请号为No.12/479,690（档案号为No.P7437US1），于2009年6月5日申请，名称为“实时或准实时流”的申请；
（2）申请号为No.12/479,698（档案号为No.P7437US2），于2009年6月5日申请，名称为“用于实时或准实时流的可变流”的申请；
（3）申请号为No.12/479,732（档案号为No.P7437US3），于2009年6月5日申请，名称为“可更新的实时或准实时流”的申请；
（4）申请号为No.12/479,735（档案号为No.P7437US4），于2009年6月5日申请，名称为“用于实时或准实时流的播放列表”的申请；
（5）申请号为No.12/878,002（档案号为No.P7437X），于2010年9月8日申请，名称为“用于实时或准实时流以提供故障切换保护的可变流”的申请；
（6）申请号为No.12/968,202（档案号为No.P7437X2），于2010年12月14日申请，名称为“具有压缩播放列表的实时或准实时流”的申请。
技术领域
本发明的实施例涉及数据传输技术。更特别地，本发明的实施例涉及允许数据流使用非流传输协议的技术，例如超文本传输协议（HTTP）。
背景技术
内容流通常涉及持续从服务器设备传送并由客户端设备接收的多媒体内容。该内容通常呈现给端用户，同时该内容由流服务器传送。该名称涉及介质的传送方法而不是该介质本身。
当前的流服务通常需要专门的服务器分配“实况”内容给端用户。在任何大规模部署中，这会导致大的开销，并需要专门的技术来创建和运行。其结果就是可供流传输的内容库比预期的要少。
发明内容
在一个实施例中，一种系统可基于日期和时间搜索内容。例如，在一个实施例中，创建时间戳标签，每一个所述时间戳标签可以与特定媒体文件相联系。在时间戳标签中的时间戳指示相关媒体文件的开始日期和时间。注意所述媒体文件包括其自己的内部时间戳。可以利用一个或多个时间戳标签创建播放列表文件。可以使用所述时间戳标签中的日期和时间分配所述播放列表文件并使其可用于通过日期和时间的搜索。在一个实施例中，所述时间戳标签可使用一种被称为ID3的格式。
在一个实施例中，一种方法可在客户端设备上执行用户应用以呈现媒体文件并控制所述媒体文件的呈现。所述方法进一步在所述客户端设备上运行媒体服务进程以取回指定所述媒体文件的播放列表以及可获得所述媒体文件的媒体源，从所述媒体源取回所述媒体文件，并对取回的所述媒体文件进行解码。所述用户应用可被配置成通过自定义URL或自定义协议或者这两者与一个或多个服务器通信，即使所述媒体服务进程不被配置来处理所述自定义URL或自定义协议。所述自定义URL或自定义协议可指定或提供解密密钥以用于解密所述媒体文件中的加密内容。
在具有与通过所述一个或多个接口与其他被调用的程序代码交互的调用程序代码的环境中，一些实施例包括一个或多个应用编程接口（API）。进一步可能包括不同类型参数的不同函数调用、消息或其他调用类型可以通过所述调用程序和被调用代码之间的API被传输。另外，API能够为所述调用程序代码提供使用在API中定义并在所述调用程序代码中实现的数据类型或类的能力。
至少某些实施例包括一种具有通过API与被调用软件组件交互的调用软件组件（calling software component）的环境。一种用于在该环境中通过API进行操作的方法包括通过所述API传输一个或多个函数调用、消息、其他调用类型或参数。
本文描述了其他方法，以及用于实现这些方法的系统，本文还描述了存储可执行指令的机器可读的非暂时性存储介质，当这些指令被执行则会促使数据处理系统实现这些方法中的任何一个。
附图说明
本发明通过附图中的示例的方式阐述，而不是以限制的方式，其中相似的参考数字涉及类似组件。
图1是能够发送和接收实时或准实时内容的服务器和客户端的实施例的框图。
图2A是用于一个或多个服务器设备使用非流传输协议支持媒体内容的技术的实施例的流程图。
图2B是用于一个或多个服务器设备为一个或多个客户端设备提供动态更新播放列表的技术的实施例的流程图。
图2C是用于一个或多个服务器设备使用多比特率为客户端设备提供媒体内容的技术的实施例的流程图。
图3A是用于客户端设备使用非流传输协议支持内容的流传输的技术的实施例的流程图。
图3B是用于客户端设备使用多比特率支持内容的流传输的技术的实施例的流程图。
图4是服务器流代理的实施例的框图。
图5是客户端流代理的实施例的框图。
图6是带有多标签的播放列表文件的实施例。
图7是本文描述的用于组合流的重放技术的实施例的流程图。
图8是电子系统的实施例的框图。
图9A是显示客户端设备如何在不同播放列表的供选择的内容之间切换的示例的流程图。
图9B是进一步显示客户端设备如何在两个播放列表的内容之间切换的示例的流程图。
图9C是进一步显示客户端设备如何使用音频模式匹配在内容之间切换的示例的流程图。
图9D以图表法示出如何利用音频模式匹配来实现图9C中的方法。
图10是用于使用可替代流提供用于向客户端设备提供媒体内容的多个冗余位置的技术的实施例的流程图。
图11示出根据一个实施例的客户端1102与一个或多个URL进行双向通信的网络。
图12A是描述根据本发明的实施例的用于控制播放列表的创建和分配的方法的流程图。
图12B示出在一实施例中，播放列表如何能够使用如图12A中的方法被传输或被分配的时间表。
图13是根据本发明的实施例的用于在客户端设备控制重放的方法。
图14A示出描述在一实施例中的用于基于连接速度或连接类型适应性地确定最小重叠量的方法流程图。图14B、14C和14D示出使用重叠以在流之间切换的实施例的其他方面。
图15是描述根据本发明的实施例的另一方法的流程图。
图16A是示出描述实施例的用于使用时间戳标签创建播放列表文件的方法流程图。
图16B示出描述实施例的用于在播放列表中使用时间戳标签搜索媒体文件的方法流程图。
图17A示出用于允许媒体服务后台程序（daemon）与用户应用交互的软件体系结构的示例。图17B示出使用自定义URL技术的软件体系结构的示例，图17C为显示使用自定义URL技术的方法示例流程图。图17D示出提供由使用自定义URL技术的应用实现的方法示例的流程图；图17E示出由播放器服务或操作系统或者两者所实现的方法示例的流程图。
图18示出在本发明的某些实施例中可用的示例性API结构的框图。
图19示出在本发明的某些实施例中可用的软件堆栈的示例性实施例。
图20示出用于允许一个设备控制或启动另一设备上的媒体重放的软件体系结构的示例。
图21示出软件体系结构的示例，其使用图20和图21中显示的两个不同设备上的软件体系结构中的软件的不同组件之间的调用。
图22A和22B示出根据本发明的实施例的可用于允许两个设备，例如图20中显示的那些设备，进行交互并提供在由另一个设备启动的一个设备上的远程重放的方法示例。
具体实施方式
在下面的描述中，阐述了许多特定细节。但是，本发明的实施例可以在没有这些特定细节下被实践。在其他情况下，未详细呈现熟知的电路、结构和技术，以便不模糊对本说明书的理解。
本说明书包括版权保护的材料，例如图形用户界面图像的图示。因此版权所有者，包括本发明的受让人，保留他们在这些材料中的权利，包括版权。版权所有者不反对任何人对于专利文件或专利公开的复制，因为其出现在专利商标局文件或记录中，但除此之外保留所有版权。苹果公司2009年版权所有。
在一实施例中，这里所描述的技术和组件包括使用非流传输协议（例如，HTTP）和其他技术（例如，运动图像专家组（MPEG）流）传递流体验的机制。例如，可以使用HTTP提供准实时流体验以广播“实况”音乐或体育事件、实况新闻、网络摄像机视频源（camera feed）等。在一实施例中，协议可将输入的媒体数据分割成多个媒体文件并将那些分割的媒体文件存储到服务器中。该协议还可创建包括将客户引导到存储在服务器上的分割的媒体文件的统一资源标识符（URI）的播放列表文件。当分割的媒体文件按照（多个）播放列表文件被重放时，客户端可为用户提供“实况”事件的准实时广播。可以以类似方式提供预录内容。
在一实施例中，服务器可将补充的或替代的媒体内容（例如，广告、涉及体育事件的统计资料、对主呈现的附加媒体内容）动态引入到广播事件中。例如，在媒体事件的客户端重放过程中，服务器可将附加URI添加到播放列表文件中，URI标识客户端下载补充媒体文件的位置。可指示客户端周期地从服务器获取一个或多个更新的播放列表文件，以访问服务器已引入的任何补充或附加（或者两者兼有）的媒体内容。
在一实施例中，服务器可在累积模式或滚动模式中操作。在累积模式中，服务器创建播放列表文件并在播放列表文件末尾追加媒体文件标识符。当单一的播放列表文件被下载以后，客户端具有对来自该播放列表文件的流的所有部分的访问权（例如，用户可以从表演秀的中间开始）。在滚动模式中，服务器通过以滚动方式从播放列表文件开始处移除媒体文件标识符来限制媒体文件的可用性，从而提供客户端设备可访问的媒体内容的滑动窗口。服务器还可以将媒体文件标识符添加到播放列表，并且在滚动模式中，服务器将媒体文件的可用性限制到那些最近添加到播放列表中的文件。然后客户端重复下载播放列表文件的更新副本以继续浏览。当内容在时间上是潜在无界的（例如，来自于持续运作的网络摄像机的内容），对于播放列表下载来说滚动方式是有用的。客户端可在滚动模式中继续重复请求播放列表直到其在播放列表中发现结束标记。
在一实施例中，该机制通过提供同一呈现的不同的流来支持比特率切换。例如，可将要被服务的呈现的若干版本存储在服务器中。每一版本可具有本质上相同的内容但以不同比特率被编码。这能够允许客户端设备在不牺牲重放连续性的情况下，例如依赖可用带宽检测而在比特率之间进行切换。
在一实施例中，提供保护特性以保护内容防止未经授权的使用。例如，可使用非顺序性媒体文件编号来防止预测。可使用媒体文件的加密。可使用部分媒体文件列表。还可提供附加的和/或不同的保护特性。
图1示出能够发送和接收实时或准实时内容的服务器和客户端的实施例的框图。图1的例子提供了一种简单的服务器‑客户端连接，其具有两个通过网络耦合到服务器的客户端。使用这里描述的技术和机制可支持任何数量的客户端。此外，根据这里描述的技术和机制，多个服务器可提供内容和/或一起操作以提供内容。例如，一个服务器创建内容，创建播放列表并创建多个媒体（例如，文件），其他服务器存储和传输所创建的内容。
网络110可以是任何类型的网络，不管是有线的、无线的（例如，IEEE 802.11、802.16）还是其任何组合。例如，网络100可以是因特网或内联网。作为另一个例子，网络110可以是蜂窝网络（例如，3G、CDMA）。在一实施例中，客户端设备150和180能够通过多个网络类型通信（例如，每一个设备可通过WiFi无线局域网通信并且也能通过无线蜂窝电话网络通信）。例如，客户端设备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和180接收来自服务器120的播放列表文件，并使用播放列表文件从服务器120访问和下载媒体文件。输出生成器代理165和195分别使用所下载的媒体文件从客户端设备150和160生成输出。输出可由一个或多个扬声器、一个或多个显示屏、扬声器和显示屏的组合或任何其他输入或输出设备提供。客户端设备还包括存储器（例如，闪存或DRAM等）以在接收媒体文件时作为缓存（或缓冲区，buffer）存储媒体文件（例如，压缩的媒体文件或解压缩的媒体文件）；缓存可在当前呈现内容的时间以外提供相当于许多秒的可呈现内容，以便当下载新的内容时稍后显示所缓存的内容。该缓存能够在客户端设备正试图通过间歇性慢速网络连接获取内容时提供可显示内容，因此缓存能够隐藏网络延迟或连接问题。
客户端设备150和180进一步包括可选安全代理170和185，其分别提供一个或多个这里所讨论的安全功能。客户端设备150和180还包括图1中没有显示的附加组件。
在一实施例中，本申请中描述的技术可用于在非流传输协议（例如，HTTP）上传输多媒体数据的无边界流。实施例还包括媒体数据的加密和/或对备选版本数据流的提供（例如，提供备选比特率）。由于媒体数据在创建之后立刻就可被传输，因而可准实时地接收数据。提供用于文件以及用于由多媒体数据流的服务器（发送者）和客户端（接收者）所采取的行动的示例数据格式，但是，其他格式也能得到支持。
可作为模拟实时流（或准实时流）传输的媒体呈现由指示播放列表文件的统一资源指示符（URI）指定。在一实施例中，播放列表文件是附加URI的有序列表。播放列表文件中的每一个URI都引用作为流的一个部分的媒体文件，该流可以是特定节目的单一连续的媒体数据流。
为了播放媒体数据流，客户端设备从服务器获取播放列表文件。客户端还获取和播放由播放列表文件指示的每一个媒体数据文件。在一实施例中，客户端可动态地或重复地重新加载播放列表文件以发现附加的和/或不同的媒体部分。
例如，播放列表文件可以是扩展M3U播放列表文件。在一实施例中，使用可有效扩展M3U格式的附加标签。M3U指的是运动图像专家组音频第3层统一资源定位符（MP3 URL）并且是一种用于存储多媒体播放列表的格式。M3U文件是包含媒体播放器要播放的一个或多个媒体文件的位置的文本文件。
在一实施例中，播放列表文件是由多个独立行组成的扩展M3U格式的文本文件。可通过单独的LF字符或CR字符后面紧跟LF字符来结束行。每一行都可以是一个URI、一个空行、或以一注释字符（例如，‘#’）开始。URI标识要被播放的媒体文件。空行可被忽略。
以注释字符开头的行可以是注释也可以是标签。标签可以以#EXT开头，注释行可以以#开头。注释行通常被服务器和客户端忽略。在一实施例中，以UTF‑8格式对播放列表文件进行编码。UTF‑8（8比特统一码转换格式）是一种可变长度字符编码格式。在替代实施例中，可使用其他字符编码格式。
在如下示例中，使用包括两个标签：EXTM3U和EXTINF的扩展M3U格式。通过包括“#EXTM3U”的首行可以从基本M3U文件中识别出扩展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‑DISCONTINUITY
EXT‑X‑VERSION
下面将对这些标签的每一个进行更为详细地描述。虽然描述了关于每一个新标签的具体格式和属性，但是具有不同属性、名称、格式等的备选实施例也可以得到支持。
在一实施例中，EXT‑X‑TARGETDURATION标签表示将被添加到呈现中的下一个媒体文件的大概持续时间。其可被包含在重放文件中，且格式可以为：
#EXT‑X‑TARGETDURATION:<seconds>
其中“seconds”表示媒体文件的持续时间。在一实施例中，实际持续时间可能与标签所表示的目标持续时间稍微有所不同。在一实施例中，每一个表示一个片段的URI都将与片段的大概持续时间相联系；例如，一个片段的URI被加上一个表示该片段的大概持续时间的标签作为前缀。在另一个实施例中，EXT‑X‑TARGETDURATION标签可以指定最大媒体文件持续时间；播放列表文件中的每一个媒体文件的EXTINF持续时间应当小于或等于目标持续时间，该标签（其指定最大媒体文件持续时间）可以在播放列表文件中仅被指定一次且适用于播放列表文件中的所有媒体文件，它的格式可以为：
#EXT‑X‑TARGETDURATION:<s>
其中“s”为以秒数表示目标持续时间的整数。
播放列表文件中的每一个媒体文件URI都有一个唯一的序号。在一实施例中，一个URI的序号，如果存在的话，等于其之前的那个URI的序号加1。EXT‑X‑MEDIA‑SEQUENCE标签可以表示出现在播放列表文件中的第一个URI的序号，其格式可以为：
#EXT‑X‑MEDIA‑SEQUENCE:<number>
其中“number”为URI的序号。如果播放列表文件不包含#EXT‑X‑MEDIA‑SEQUENCE标签，那么播放列表的第一个URI的序号可被视为1。在一实施例中，媒体文件的序号并不要求出现在它的URI中，并且在一实施例中，播放列表可仅包含一个EXT‑X‑MEDIA‑SEQUENCE标签。在一实施例中，序号可以是非顺序的；例如，非顺序序号如1、5、7、17等使得难以预测序列中的下一个号码，这有助于保护内容不被剽窃。另一个有助于保护内容的选择是在任何给定时间都只显示部分播放列表。
可对一些媒体文件进行加密。EXT‑X‑KEY标签提供可用于对其后的媒体文件进行解密的信息，其格式可以为：
#EXT‑X‑KEY:METHOD=<method>[,URI=”<URI>”][,IV=<IV>]
METHOD参数指定加密方法，URI参数，如果出现的话，指定如何获取密钥，IV（初始化向量），如果出现的话，指定用于加密方法（如利用密钥）中的初始化向量。
加密方法为NONE表示没有加密，在一实施例中，如果指示了NONE，那么URI和IV参数就不应当出现。可以使用多种加密方法，例如AES‑128，其表示使用具有128比特密钥和PKCS7填充的高级加密标准加密的加密方法[参见RFC3852]。新的EXT‑X‑KEY标签取代任何之前的EXT‑X‑KEY标签。
具有URI参数的EXT‑X‑KEY标签标识密钥文件。密钥文件可包含要用于对于播放列表文件中列出的随后的媒体文件进行解密的密码密钥。例如，AES‑128加密方法使用16字节密钥。密钥文件的格式可以是二进制格式的16字节的合并（packed）数组。
AES‑128的使用通常要求在加密和解密时提供相同的16字节初始化向量（IV）。改变IV可用于增加密码的强度。当使用AES‑128加密算法时，在加密或解密媒体文件时媒体文件的序号可被用作IV。
EXT‑X‑PROGRAM‑DATE‑TIME标签可使得下一个媒体文件的开始与绝对日期和/或时间相关联，并包含或指示时区。在一实施例中，日期/时间表示法为ISO/IEC 8601:2004。在该标签中的日期和时间值能够提供媒体时间线到合适的墙钟时间的信息映射，其可用作基于日期和时间而为显示或其他目的的寻找用于重放的内容的基础。在一实施例中，如果服务器提供该映射，就应当在播放列表文件中每一个EXT‑X‑DISCONTICUITY标签后面放置一EXT‑X‑PROGRAM‑DATE‑TIME标签。该标签格式可以为：
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>为以每秒比特数表示的流比特率的近似上限。在一实施例中，属性BANDWIDTH可以是每一个媒体文件的总比特率的上限，其被计算以包括出现或将要出现在播放列表中的容器（container）开销。属性PROGRAM‑ID=<i>为在播放列表文件范围内唯一标识一特定呈现的数字。播放列表文件可包含具有相同PROGRAM‑ID的多个EXT‑X‑STREAM‑INF URI以描述相同呈现的不同流，并且这些不同的播放列表可包含附加的EXT‑X‑STREAM‑INF标签。在本公开中将进一步描述不同流和不同播放列表（例如，参见图9A‑9D）。属性CODECS=”[format][,format]＊”可用于在播放列表文件中指定出现在媒体文件中的媒体样本类型，其中每一种格式指定一种媒体样本类型；在一实施例中，有效的格式标识符可以是由RFC 4281定义的ISO文件格式名称空间中的那些。属性RESOLUTION=<N>×<M>可指定流中的视频分辨率，其中N为流中视频的近似编码水平分辨率，其能以像素数目来表示，M为近似编码垂直分辨率。
EXT‑X‑DISCONTINUITY标签指示在该标签后面的媒体文件与其之前的媒体文件之间的编码间断性。可改变的特征组为：
·文件格式
·轨道的数目和类型
·编码参数
·编码序列
·时间戳序列
其格式为：
#EXT‑X‑DISCONTINUITY
EXT‑X‑VERSION标签指示播放列表文件的兼容版本。在一实施例中，播放列表文件、其相关媒体以及其服务器都应当遵守描述由标签值表示的协议版本的该文档的最近版本的所有条款。
其格式为：
#EXT‑X‑VERSION:<n>
其中“n”为表示协议版本的整数。
在一实施例中，播放列表文件不能包含超过一个的EXT‑X‑VERSION标签。在一实施例中，不包含EXT‑X‑VERSION标签的播放列表文件应当遵守该协议的版本1。在一实施例中，如果播放列表文件具有该标签，那么它的取值应当是服务器、播放列表文件以及相关媒体文件都遵守的最低协议版本。
服务器设备可使用前述标签和属性来组织、传输和处理表示原始媒体内容的媒体文件。客户端设备使用该信息以按如下方式重新组合和呈现媒体文件：为客户端设备的用户提供实时或准实时流体验（例如，实况广播如音乐或体育事件的浏览）。
播放列表文件中每一个媒体文件URI都标识作为原始呈现（即，原始媒体内容）的一片段的媒体文件。在一实施例中，每一个媒体文件都被格式化为MPEG‑2传输流、MPEG‑2节目流或MPEG‑2音频基本流。格式可通过指定CODEC的方式被指定，并且播放列表可通过指定CODEC的方式来指定格式。在一实施例中，在一呈现中的所有媒体文件都具有相同格式；但是，在其他实施例中可支持多种格式。在一实施例中，传输流文件应当包括单独的MPEG‑2节目，并且在每个文件的开始应当有节目关联表和节目映射表。包含视频的文件应当具有至少一个密钥帧和足以完整初始化视频解码器的信息。播放列表中的媒体文件必须是具有前一个序列号的媒体文件末尾的编码流的延续，除非它是出现在播放列表文件中的第一个媒体文件，或者如果它是以EXT‑X‑DISCONTINUITY标签引导的。客户端应当准备通过选择合理子集来处理特定类型（例如，音频或视频）的多个轨道。在一实施例中，客户端应当忽略传输流内部其无法识别的私有流。用于媒体文件内部的流中的样本以及在多个媒体文件中相应流之间的样本的编码参数应当保持一致。但是客户端应当在遇到编码变化时对其进行处理，例如通过缩放视频内容以提供分辨率变化。
图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‑128CBC加密可应用于各个媒体文件。在一实施例中，整个文件都被加密。在一实施例中通常不横跨媒体文件而应用密码块链。媒体文件的序号可用作IV，或者IV可以是如前面描述的EXT‑X‑KEY标签的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，其值可以增加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添加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，生成具有这里所描述的指示不同编码等级的标签的变体播放列表。例如，该标签可包括用于每个编码等级的具有相应媒体播放列表文件的URI的EXT‑X‑STREAM‑INF标签。
该变体播放列表可包括用于不同编码等级的媒体播放列表文件的URI。因此，客户端设备可从指示编码等级的变体播放列表中提供的选项中选择目标比特率，并获取相应播放列表文件。在一实施例中，客户端设备在重放过程中可在比特率之间变化（例如，有关图9A‑9D所描述的）。在操作252，将表示不同编码等级的变体播放列表存储到服务器。在操作242，还生成在变体播放列表中涉及的每个播放列表，然后在操作252中对其进行存储。
在操作272，响应于来自客户端设备的请求，服务器传输表示不同编码等级的变体播放列表。在操作282，服务器接收对变体播放列表中指定的与选择的比特率相对应的媒体播放列表中的一个的请求。在操作292，响应于该请求，服务器传输与来自客户端设备的请求对应的媒体播放列表文件。然后客户端设备可以使用媒体播放列表从服务器请求媒体文件。在操作297，服务器响应于请求而为客户端设备提供媒体文件。
图3A是用于客户端设备使用非流传输协议支持内容流的技术的一实施例的流程图。图3A中的示例是以HTTP的方式提供的；但是，也可以以类似方式使用其他非流传输协议。图3A‑3B中所示的方法可由一个客户端设备或由多个独立的客户端设备来执行。例如，在这些方法的任何一种的情况下，单独的客户端设备执行所有操作（例如，请求播放列表文件、使用播放列表文件中的URI请求媒体文件、组合媒体文件以生成和提供呈现/输出），或者多个不同的客户端设备执行其中一些但不是全部的操作（例如，第一客户端设备请求播放列表文件和使用播放列表文件中的URI请求媒体文件，并存储那些媒体文件以供第二客户端设备使用，第二客户端设备处理媒体文件以生成和提供呈现/输出）。
在操作300，客户端设备可从服务器请求播放列表文件。在一实施例中，根据符合HTTP的协议作出该请求。该请求利用存储在服务器上的初始的播放列表文件的URI。在替代实施例中，支持其他非流传输协议。响应于该请求，服务器将在网络中将相应播放列表文件传输到客户端。如上文所讨论的，网络可以是有线的或者无线的，并且可以是有线或无线网络的任何组合。另外，网络可以是数据网络（例如，IEEE 802.11、IEEE 802.16）或蜂窝电话网络（例如，3G）。
在操作310，客户端设备接收播放列表文件。在操作320，将播放列表文件存储在客户端设备的存储器中。例如，存储器可以是硬盘、闪速存储器、随机访问存储器。在一实施例中，每次从播放列表URI中加载或重新加载播放列表文件时，客户端都对其进行检查以确定播放列表文件以#EXTM3U标签开头，如果不出现该标签的话就不再继续。正如上文所讨论的，播放列表文件包括一个或多个标签，以及一个或多个到媒体文件的URI。
在操作330，客户端设备包括组合器代理，其使用播放列表文件以通过请求由播放列表文件中的URI所指示的媒体文件重组原始内容。在一实施例中，组合器代理是作为标准网络浏览器应用的一部分的插件模块。在另一个实施例中，组合器代理可以是与网络浏览器进行交互以接收（多个）播放列表文件并使用（多个）播放列表文件组合媒体文件的独立应用。作为进一步示例，组合器代理可以是嵌入到客户端设备中的专用硬件或固件组件。
组合器使得来自播放列表文件的媒体文件从由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。
如果已经加载了要被播放的第一个媒体文件并且播放列表文件包含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包括实现逻辑功能控制以指导服务器流代理400的操作的控制逻辑410，以及与指导服务器流代理400操作有关的硬件。逻辑可以是硬件逻辑电路或软件例程或固件。在一实施例中，服务器流代理400包括一个或多个应用412，其表示为了控制逻辑410而提供指令的代码序列和/或程序。
服务器流代理400包括存储器414，其表示存储器设备或对用于存储数据或指令的存储器资源的访问通道。存储器414可包括服务器流代理400本地的存储器，以及，或作为选择，包括服务器流代理400驻留的主机系统的存储器。服务器流代理400还包括一个或多个接口416，表示同服务器流代理400的外部实体（电子的或人类的）有关的到服务器流代理400/从服务器流代理400的访问接口（输入/输出接口）。
服务器流代理400还包括服务器流引擎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包括执行指导客户端流代理500操作的逻辑功能控制的控制逻辑510，以及与指导客户端流代理500操作有关的硬件。逻辑可以是硬件逻辑电路或软件例程或固件。在一实施例中，客户端流代理500包括一个或多个应用512，其表示为控制逻辑510提供指令的代码序列或程序。
客户端流代理500包括存储器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包含一个或多个播放列表文件的URI，该播放列表文件在播放列表600的媒体文件被播放之后要被使用。
存储器标签670指示客户端设备是否能在媒体文件内容重放之后存储媒体文件，和/或存储媒体文件多长时间。在一实施例中，存储器标签670为EXT‑X‑ALLOW‑CACHE标签。结束标签680指示播放列表文件600是否为供呈现的最后一个播放列表文件。在一实施例中，结束标签680为EXT‑X‑ENDLIST标签。
下面的部分包含根据一个实施例的多个示例的播放列表文件。
简单播放列表文件
#EXTM3U
#EXT‑X‑TRAGEDURATION:10
#EXTINF:5220,
http://media.example.com/entire.ts
#EXT‑X‑ENDLIST
滑动窗口播放列表，使用HTTPS
#EXTM3U
#EXT‑X‑TRAGEDURATION: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中所显示的顺序来执行操作顺序；例如，可以在操作903执行过程中执行操作907等。在操作911，客户端设备基于来自操作907的测量比特率，从变体播放列表中选择替代的媒体播放列表；该替代的媒体播放列表可以具有比第一流的现行比特率高的第二比特率。这通常意味着替代流将具有比第一流更高的分辨率。如果基于当前条件（例如，在操作907中测量的比特率）替代的媒体播放列表是比第一流的当前播放列表更好的匹配者，则选择该替代的媒体播放列表。在操作913，重新获取并处理替代流的替代媒体播放列表。这通常意味着客户端设备可接收和处理第一流和替代流两者，因而两者对于呈现来说都是可用的；呈现一个并准备好呈现另一个。然后在操作915，客户端设备选择转换点以在流的版本之间切换，停止呈现第一流并开始呈现替代流。与图9B‑9D一起共同提供如何完成该切换的示例。在一些实施例中，客户端设备可在作出切换之前停止接收第一流。
图9B示出在操作921和923，客户端设备重新获取、存储和呈现由第一媒体播放列表（例如，第一流）指定的内容，并且在操作925，当呈现由第一播放列表指定的内容时，客户端设备还重新获取和存储由第二媒体播放列表（例如，第二流）指定的内容。当呈现从第一媒体播放列表获得的内容时对由第二媒体播放列表指定的内容的重新获取和存储（例如，于临时缓冲区中）造成节目内容在时间上的重叠955（如图9D中所示），从而允许客户端设备在节目的版本之间切换而不会对节目造成实质中断。这样，可以在多种情况下实现节目版本之间的切换，而不会使用户察觉到切换的发生（虽然在某些情况下，在切换之后用户会注意到更高分辨率图像）或者不会对节目的呈现造成实质中断。在操作927，客户端设备确定转换点，在该转换点从由第一媒体播放列表指定的内容切换到由第二媒体播放列表指定的内容；图9D中显示了转换点的示例（转换点959）。在切换之后，随后在操作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，在一实施例中，该转换点为匹配的音频分段（例如，分段957）之后的下一个独立（自包含的）视频帧（例如，i帧961）。以i帧961（以及其相关音频采样）开始，节目的呈现使用从第二媒体播放列表获得的第二流。在一实施例中上述方法可用于从较慢比特率到较快高比特率的变化以及从较快比特率到较慢比特率的变化，但是，在另一实施例中，该方法仅可用于从较慢低比特率到较快高比特率的变化，而另一方法（例如，不尝试定位转换点，但尝试尽快存储和呈现来自较慢比特率流的内容）可用于从较快高比特率到较慢比特率的变化。
图10是用于提供利用替代流来为客户端设备提供播放列表或媒体内容或其二者的多个冗余位置的技术的一实施例的流程图。如果播放列表包含上文讨论的替代流，则替代流不仅仅作为带宽替代或设备替代来操作，还作为失败回退（fallback）。例如，如果客户端不能重新加载流的播放列表文件（例如，由于404错误或网络连接错误），客户端可尝试切换到替换流。参考图10，如同结合图2C的说明所讨论的，在操作1002，为了实现故障备援（failover）保护，第一服务器设备或第一内容分发服务被配置为创建一个流或多个替代带宽流。在操作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进行有效压缩，然后由客户端设备自动解压。可以在www.ietf.org/rfc/rfc1952.txt找到gzip压缩设施的版本描述；可在www.ietf.org/rfc/rfc1951.txt找到deflate压缩设施的版本。许多网络服务器和客户端设备上的许多网络浏览器可自动支持deflate或gzip设施。
在一实施例中，客户端设备周期性地请求更新的播放列表；例如，客户端设备每隔几秒（例如，每隔10、20或30秒或其他时间周期）从服务器请求更新的播放列表。不断增长的播放列表（如用于实况正在进行的篮球赛的播放列表，其允许客户端在实况比赛过程中的任意时间从实况比赛开头开始观看）变得足够大使得压缩的使用可限制网络带宽的消耗，因为不断增长的播放列表通过网络被重复发送。
在一实施例中，当客户端设备请求播放列表（如更新的播放列表）时，其可选择地指定可支持的压缩技术（如deflate或gzip）；这些技术的支持意味着客户端设备可解压或译码被压缩或编码的内容。通过压缩技术的可选指定，网络服务器接收客户端设备对播放列表的请求，在一实施例中，并不需要该网络服务器来支持用于播放列表的压缩技术，而是可发送非压缩播放列表。网络服务器通过向客户端设备发送非压缩播放列表或使用在客户端设备对播放列表的请求中指定的压缩技术之一进行压缩的播放列表，来响应客户端设备的请求。客户端设备如这里所描述的接收和使用播放列表；如果播放列表是压缩的，则使用客户端设备中的解码器，如客户端设备上网络浏览器中的解码器，对其进行解码。
图12A和12B显示当附加媒体文件将被添加时（例如，当正被传输的当前播放列表不包含EXT‑X‑ENDLIST标签时）用于后继播放列表的传输的服务器定时模型的一实施例。如果当前播放列表不包含呈现的最后一个媒体文件，那么数据处理系统或服务器可制作包含至少一个新的媒体文件URI的播放列表新版本。图12A和12B显示服务器定时模型的一实施例，用于确保具有新的媒体文件URI的新播放列表能够以延续播放列表前一个版本的方式传输到客户端设备。例如，当允许在播放列表中指定的媒体文件具有较短的持续时间（例如，仅几秒钟长）时可使用该模型。在一实施例中，通过为每个媒体文件设置最大媒体文件持续时间和通过基于最大媒体文件持续时间设置播放列表持续时间的最小总量，服务器或其它数据处理系统可确保内容连续分发或传输到客户端设备，即使每个媒体文件仅有几秒钟的持续时间。
现在参照图12A，如果在操作1200所确定的下一个播放列表文件中不出现endlist标签，则操作1201可用于建立作为播放列表中每个媒体文件的最大媒体文件持续时间的目标持续时间。可由将数据流细分为多个媒体文件并将其存储为各个文件的数据处理系统执行操作1201。细分数据流的过程使用目标持续时间（例如，当前播放列表文件的目标持续时间）来确保播放列表文件中指定的每个媒体文件都小于目标持续时间（或小于目标持续时间加上或减去一小段时间）。如操作1203所示，产生播放列表的数据处理系统还确保播放列表文件的持续时间至少为目标持续时间的倍数。在一实施例中，该倍数可以是三个用作最小播放列表持续时间的目标持续时间（或目标持续时间的某些其他倍数），其中，通过播放列表中指定的媒体文件的累积持续时间定义播放列表的持续时间。产生播放列表的系统（例如，服务器）通过确保每个播放列表指定至少足够数量的媒体文件以满足最小持续时间来遵守播放列表的最小持续时间；例如，如果最小持续时间是3个目标持续时间，则每个播放列表都应包含至少3个目标持续时间。
操作1205还可用作确保一致的连续的数据流从数据处理系统（如传输媒体文件的服务器）中可用的进一步机制。该进一步机制可减少客户端设备用于确定播放列表是否发生变化的轮询和牵引的总量。在操作1205，可创建服务器以便服务器具有传输下一个播放列表的最早时间和最晚时间。最早时间和最晚时间可被用作基于或相对于前一个播放列表文件（恰好先于新播放列表）变为可用的时间的时间窗口。例如，最早时间可基于紧接的前一个播放列表首次可用于从服务器传输（但不必已经传输）的时间。例如，最晚时间也可基于紧接的前一个播放列表首次可用于从服务器传输（但不必已经传输）的时间。例如，在一实施例中，最早时间可被指定为从之前的播放列表文件首次对传输变为可用开始不早于目标持续时间（例如，在操作1201中设置的目标持续时间）的第一预定百分比（例如，二分之一）的时间，最晚时间可被设置为不晚于从紧接的前一个播放列表文件首次对从服务器的传输变为可用开始不晚于目标持续时间的第二预定百分比（例如，1.5倍）的时间。在一实施例中，播放列表文件首次对传输可用的时间可以是播放列表文件的创建时间（该时间由服务器上的文件系统所记录）。在包括时间线1211的图12B中显示该示例。目标持续时间1213为播放列表持续时间1215的一部分，播放列表持续时间表示在时间1209被一个或多个服务器首次变为可用的紧接的前一个播放列表的持续时间，在时间1209，该前一个播放列表文件首次对传输变为可用。在该播放列表中指定的媒体文件差不多在时间1209开始它们的传输。根据图12B中显示的服务器定时模型，服务器不应当传输下一个播放列表文件，直到达到最早时间1217，其为时间1209之后的目标持续时间的二分之一，并且，服务器不应当在任何晚于时间1219的时间使下一个播放列表文件可用，在图12B所述的示例中，时间1219被指定为时间1209之后的1.5倍目标持续时间。可使用该服务器定时模型以确保播放列表文件对客户端设备可用，来为客户端设备提供足够时间以重新获取在播放列表中指定的媒体文件，并随后在重放过程中一致且连续地、没有拖延地在内容呈现中呈现那些媒体文件。在一实施例中，当内容为实况事件的传输并且来自实况事件的数据流被细分为多个媒体文件时可使用这些服务器定时模型，随后，相对于实况事件准实时地将那些多个媒体文件传输到客户端设备，客户端设备在多个媒体文件从实况事件（如篮球比赛等）的数据流中被分出来之后不久接收该多个媒体文件。
图13示出可被用于防止客户端设备重放中出现拖延的方法的实施例，尤其是当客户端设备正准实时地呈现实况事件时以及当客户端设备正在呈现接近实况事件的当前结尾（在时间上最新）的内容时。例如，如果实况事件为篮球比赛，客户端设备的用户宁愿仅观看比赛中的最新事件而不愿从比赛最开头开始观看比赛。如果用户想要仅观看进行中的比赛的最新事件，则用户可试图对重放进行设置以从距离可用媒体流结尾10或15秒为起始点开始。当用户设置客户端设备使其在该模式下操作时，网络问题或延迟可突然导致数据不可用并可阻止新数据变得可用，因此在很短时间内，客户端设备可用完要呈现的内容。可使用图13的方法通过在客户端设备执行规定以减少上述问题发生的几率，该规定要求在当前播放列表文件结尾之前至少一段时间（例如，30秒）的起始点开始重放。例如，如果播放列表文件内指定有5个媒体文件（每个媒体文件持续10秒），那么该规定的一种实现方式是强制开始点在不晚于播放列表指定的五个媒体文件的序列中的第三个媒体文件。现参照图13，操作1301用于确定endlist标签或标记是否出现在播放列表中。如果出现这样的endlist标签，那么图13的方法可在没有新的内容添加到播放列表时停止，因此在一实施例中不需要执行操作1303中的规定。另一方面，如果在播放列表中不出现endlist标签，那么在客户端设备执行规定要求开始点必须是至少在播放列表文件结束之前一时间段。可根据媒体文件的目标持续时间指定该时间段。例如，在一实施例中，要求客户端设备从距离播放列表文件结尾超过三倍目标持续时间的媒体文件开始。
本发明的另一个方面涉及当在来自两个播放列表的流之间（例如，两个变型流）切换或在两组媒体文件之间切换时使用的方法。结合图9A、9B、9C和9D提供了用于在来自两个不同播放列表的流之间切换的方法示例。在该方法中，两个流之间在时间上的重叠被用于确保一致且连续的重放，以便流之间的切换或转换是无缝的。如图9D所示，重叠955表示来自两个流的媒体内容在客户端设备被存储并能够在客户端设备被重放的时间段，从而允许在两个流之间进行无缝切换。在一实施例中，重叠部分为从不改变的且在客户端设备中设置的最小数字。虽然该实施例运作良好，但在某些时候该重叠部分不必要地太长。也就是说，重叠部分可防止切换或转换的发生，即使设备已准备好进行转换。例如，当从较低分辨率到较高分辨率切换时，不必要的长的重叠会迫使用户在较高分辨率显示内容已经可用和准备好被呈现时观看一段时间的较低分辨率显示内容。例如，高速的连接可提供快速开发重叠部分的能力，该重叠部分短于低速连接或连接类型所需的重叠部分。在根据图14A的实施例中，客户端设备可适应连接速度或连接类型，并基于连接速度或连接类型修改所需的最小重叠。例如，如果连接速度或类型较快，则可相对于较低连接速度或连接类型所需的最小重叠而缩短最小重叠。当条件改变（例如，客户端设备丢失3G连接且必须依赖2G或更慢的连接）时，可改变最小重叠。因此，客户端设备可基于连接速度或类型适配最小重叠。现参照图14A，在操作1401，客户端设备确定连接的速度或类型。重新参考图9D，可以看到来自第二播放列表的第二数据流为当客户端设备还接收来自第一播放列表的流时接收的新的数据源。这时，在操作1403，客户端设备可确定连接速度或连接类型以确定基于当前连接速度或连接类型所需的最小重叠量。当诸如由无线连接到蜂窝电话塔、WiFi基站的条件改变时，可基于改变的条件适配该最小重叠。当客户端设备在无线蜂窝电话网络或其他数据网络中移动时这会特别有利。当确定当前条件的最小重叠存在后，在操作1405，客户端设备可从来自第一播放列表或旧的数据源的流切换或转换到可以是来自第二播放列表的流的新的数据源。已结合图9A‑9D的相关描述提供了该转换的示例。
图14B、14C和14D示出两个流之间如何重叠的另一个方面（例如，结合图9A‑9D所示和描述的重叠或结合图14A所描述的重叠）。可通过自适应导出的重叠（已连同图14A对其进行描述）实现图14B、14C和14D所示的方法，或者可通过不变的固定重叠使用该方法。图14B‑14D中描述的方法以从“旧流”1410（例如，其可以是以第一速度下载的较低分辨率视频，该第一速度在比特率上比用于新的流1414的后续下载的第二速度低）中下载媒体文件开始。如同哈希标记1411所指示的那样旧流1410已经被下载，并且在客户端设备上其正为用户在重放点（例如，重放头位置）1412呈现；在当前重放点1412之外的旧流1410中已经下载的内容为缓存内容，其在连接失败时应当是有效的。然后客户端设备读取新流1414的播放列表并从播放列表文件中确定内容“块”，如块1416和1415，甚至在下载那些块的内容之前；例如，新流的播放列表文件可至少近似地指示内容块1416和1415相对于旧流1410的时间位置。该确定可允许客户端设备谨慎决定通过请求和重新获取块1415的一个或多个媒体文件而下载新流1414的第一个块1415，图14C示出该下载的结果（块1415A具有哈希标记以显示此块已被下载）。重放位置已经在时间上前进到一个新的位置（仍然在旧流1410的最左边块中）。在该实例中，块1415的下载足够快以致于重放位置没有离开旧流1410的最左边块。在下载需要更长时间的情况下，则应谨慎选择块1415，以便重放能够至少在块1415A附近被切换。在图14C所描述的点上，客户端设备检查在块1415A所提供的重叠和重放的当前点（如图14C中的1412所示）之间还剩多少时间。如果考虑到连接速度还有足够时间的话，客户端设备可下载作为当前重叠部分之前的块的块或分段1416，然后客户端设备重复上述检查以确定在刚下载的块1416A（如同哈希标记所指示的，在其被下载之后在图14D中所示的）所提供的重叠和重放的当前点（如图14D中的1412所示）之间还剩多少时间。就像图14D所示的示例的情况一样，如果1416A的下载很快发生，那么客户端设备可在时间上向回移动重叠点，减少在流之间切换所需的时间（并因此允许在块1416A中的切换）；另一方面，如果在下载1416A过程中有延时以致于切换不能在块1416A中发生，那么客户端设备可使用块1415A作为可用以使得切换在块1415A中发生的重叠部分。
本发明的另一个方面使用定义图像分类率的属性。该属性可允许客户端设备决定它不应当切换分辨率或者不应当基于该属性切换流。例如，客户端设备确定已经在播放可显示的最高分辨率并且通过数据网络下载设备可用的更高分辨率是没有意义的。
图15示出在一实施例中用于使用这样的属性的方法的示例。在操作1501，客户端设备接收播放列表文件，并且在操作1503，客户端设备根据播放列表文件确定定义客户端设备可用的图像分辨率的属性存在于播放列表文件中。基于该属性，在操作1505，客户端设备确定是否重新获取另一个播放列表文件或是否重新获取与该属性相关的媒体文件。通过提供分辨率属性，客户端设备可智能地决定如何处理播放列表中的数据。另外，客户端设备可作出有关数据重新取得的决定，该决定可防止不必要的下载，因而将网络上数据流量的总量减到最小。
本发明的实施例可允许系统基于日期和时间搜索内容。例如，用户想要看2009年4月9日下午5点的一记全垒打或想要看某个日期大致时间的另一个事件。本发明的实施例可通过时间戳，通过使用与相应媒体文件的开头相关的EXT‑X‑PROGRAM‑DATE‑TIME标签，提供该能力；通过在播放列表文件的媒体文件之前出现标签使得该标签与相应媒体文件关联。系统，如服务器，存储可由客户端设备重新获取（例如，下载）的一个或多个播放列表并用于搜索日期和时间以找到想要的媒体文件；或者，客户端设备请求（例如，通过日期和时间搜索请求）服务器搜索一个或多个播放列表以识别一个或多个匹配日期和时间搜索请求的媒体文件，并且服务器通过识别该一个或多个媒体文件作出响应。在一实施例中，标签指示媒体文件基本精确的开头，并且媒体文件中的时间戳可用于以时间上的更精确粒度来找到重放点。例如，标签的时间戳指示媒体文件在2009年4月9日下午5:03开始，并且媒体文件中的时间戳（或时间的其他指示）在下午5:03以后以分钟或秒等为增量指定时间，以允许设备在例如下午5:06或下午5:05:30开始重放（通过重放开始点的选择）。
图16A示出描述根据一实施例的用于使用时间戳标签创建播放列表文件的方法的流程图。由通过包括软件、硬件、固件或上述的任意组合的处理逻辑实现的服务器执行该方法。在一些示例中，由媒体提供商，如MLB，提供该服务器。
在方框1610，处理逻辑创建时间戳标签并将每个时间戳标签与一个媒体文件相关联。时间戳标签中的时间戳指示相关媒体文件的开始日期和时间。上面已经讨论了时间戳标签的一些实施例的细节。
在方框1620，处理逻辑创建具有一个或多个时间戳标签（例如，EXT‑X‑PROGRAM‑DATE‑TIME标签）的播放列表文件，其中每一个时间戳标签与一特定媒体文件相关联。注意到，媒体文件本身也具有内部时间戳。在方框1630，处理逻辑分配播放列表以便播放列表文件可用于使用时间戳标签中的日期和时间进行日期和时间的搜索。在一些实施例中，在储存库中存储播放列表，客户端设备可从中下载播放列表。
图16B示出描述根据一实施例的用于使用连同时间戳标签而创建的播放列表文件的方法流程图。由通过包括软件、硬件、固件或上述的任意组合的处理逻辑实现的客户端设备执行该方法。由与播放列表文件相关联的媒体的个别消费者、订阅者或浏览者使用客户端设备访问和播放该媒体。
在方框1650，处理逻辑接收对在特定日期和时间开始的节目分段的用户请求。例如，用户可请求于2010年4月6日下午8:15开始的篮球比赛的第四节，而不是整个篮球比赛。响应于用户请求，在方框1652，处理逻辑从媒体服务器下载一个或多个与节目相关联的播放列表文件。在方框1654，处理逻辑使用在播放列表文件内部的时间戳标签中的日期和时间搜索下载的播放列表文件以寻找与请求分段的日期和时间最接近的日期和时间标志（时间戳）。然后在方框1656，处理逻辑从请求分段的日期和时间中减去其日期和时间。这就产生一持续时间。然后在方框1657，处理逻辑向前经过播放列表中的后续媒体文件持续时间，直到在被标记日期的媒体文件之后的大约该持续时间时，处理逻辑定位到目标媒体文件。然后在方框1658，处理逻辑下载该目标媒体文件，因为其是哪个文件包含请求分段的最好猜测。
在一些实施例中，在被标记日期的媒体文件和目标媒体文件之间的所有媒体文件为单一编码的一部分，即，在它们之间没有中断标签。如果它们是，处理逻辑从目标文件中的那些媒体文件时间戳中减去被标记日期的文件中的媒体文件时间戳以得到精确持续时间，从而允许精确定位所请求的日期和时间。
使用播放列表文件中时间戳标签中的日期和时间，处理逻辑不必下载整个节目的所有媒体文件以在媒体文件中进行搜索以发现所请求的分段。由于在用户没有请求整个节目时客户端设备不必下载整个节目的所有媒体文件，可实现带宽的显著节省。此外，许多典型的媒体文件仅包含任意时间戳，通常以零开始。因此，上述时间戳标签的日期和时间将媒体文件中的任意时间戳与实际日期和/或时间相关联。与扫描每个媒体文件相比，使用时间戳标签，客户端设备可更有效地定位包含特定日期和/或时间的播放列表元素。
本发明的实施例允许将时间元数据以ID3格式插入到媒体流中。媒体流包含以预定格式编码的视频和/或音频数据。例如，媒体流可包含以MPEG‑2格式编码的视频和音频数据，MPEG‑2是由运动图像专家组（MPEG）开发的国际标准ISO/IEC 13818。广义上说，元数据包含媒体流中数据相关的信息，以及涉及有关特定时间（例如，进球得分的时间）的元数据的定时元数据。注意到，定时元数据可随时间改变。可将定时元数据以预定的用于存储元数据的格式，如ID3格式，插入到媒体流中。在一些实施例中，可将视频数据分成一系列帧。还可将视频数据的定时元数据分入与该系列帧有关的容器。每一个容器可存储相应帧的定时元数据以及与相应帧有关的时间二者。可选地，每一个容器可存储相应帧的定时元数据以及相应帧的帧数目二者。在一些实施例中，帧的定时元数据包含该帧的一组预定信息。例如，定时元数据包含记录视频数据的相应帧的位置的位置信息（例如，全球定位系统（GPS）数据）。
在一实施例中，下面内容描述了如何在这里所描述的HTTP现场流传输协议所使用的MPEG‑2传输流中携带ID3元数据作为定时元数据（参见ISO/IEC13818‑1:2007信息技术‑运动图像的通用编码和相关音频信息：下文作为“MPEG‑2标准”提及的系统）。根据MPEG‑2标准的第2.12节，可在传输流中携带元数据。例如，可在基本流（PES）中携带元数据，而不是在传送带中。ID3元数据是自描述的，不需要配置信息，因此不需要使用元数据解码器配置数据的规定。元数据流可与主要节目素材（也即，音频/视频内容）在相同节目中。
表S1、S2、S3和S4提供了可被使用的语法的实施例。在下面的语法表中，仅以有效轮廓和字段名显示该语法结构（左栏）。这就意味着，为了清楚起见，省略条件为假时的’if’方框。针对完整语法、字段大小和可接受值可查阅MPEG‑2标准。在具有每个字段名的行中，右栏指示在该上下文中所需的值，或者包含该行的解释。
使用的代码点概述
ID3定义格式和语义，因此，相同的注册的format_identifier可用于metadata_format_identifier和metadata_application_format_identifier二者。在注册机构SMPTE注册中心（参见http://www.smpte‑ra.org），为这些所注册的值为“ID3”（ID3空格，或0x490x440x330x20）（待分配）。为了指示使用的注册值，字段metadata_format和metadata_application_format可分别取值为oxff和oxffff。在一实施例中，可在私用数据流中载有该元数据，而不是以MPEG‑2标准的第12.4节中定义的元数据访问单元（MAU）的形式格式化的流。因此，如同MPEG‑2标准第2.12.3节中所规定的，用于流的stream_id的值为private_stream_id_1、0xbd。如同MPEG‑2标准第2.12.9.1节中所规定的，stream_type被设置为0x15，指示在PES流中携带元数据。由于通常仅携带一个元数据流，因此metadata_service_id通常被设为0；但是，如果需要的话，可使用任何合适的值以区别该元数据流与其他流。
使用的描述符
元数据描述符的格式和内容记载在MPEG‑2标准第2.6.58‑2.6.61节中。
用于节目的PMT的描述符循环
在节目的program_info循环中，为了声明元数据流的存在，可在PMT中设置metadata_pointer_descriptor（MPEG‑2标准第2.6.58节）。元数据可与主要节目（音频/视频）内容在相同的节目中。在一实施例中，不支持使用该描述符来引用另一个节目。
表S1


在节目映射中，还可在基本流的循环中声明基本流（MPEG‑2标准第2.4.4.8节）。
表S2

用于基本流的PMT的描述符循环
在用于基本流的es_info循环中，为了声明元数据流的格式，可在PMT中设置metadata_descriptor（MPEG‑2标准第2.6.60节）。
表S3


PES流格式
ID3元数据可作为完整ID3v4帧存储在PES分组中，包括完整ID3头部流。ID3标签在PES报头之后立即开始；该PES报头包含PTS（PTS_DTS_flags到’10’）。PTS与音频和视频帧在同一时间线上。可将data_alignment比特设为0。PES报头包含非零值的PES_packet_length。如果ID3标签长于65535个字节，那么它就可具有超过1个PES报头。第二及后续PES报头包括具有设置为0的data_alignment，以及设置为’00’的PTS_DTS_flags（因而没有PTS）。PES报头根据MPEG‑2标准第2.4.3.7节中的记载进行格式化。
表S4


以和音频或视频相同的方式将元数据流合并到传输流中。例如，那就意味着，在transport_packet()（参见MPEG‑2标准第2.4.3.2节）中，仅当PES报头紧接其后时才可将payload_unit_start_indicator设为1。（接下来，PES报头指示ID3数据的开头是否在其后，或者其是否已经被分成多个PES分组，如前面段落提到的）。
在本发明的一实施例中，媒体文件的处理（例如，播放列表的重新获取和播放列表中指定的媒体文件的重新获取，以及媒体文件中内容的解码）可独立于用于呈现和控制被呈现媒体的用户界面而完成。例如，用户应用，如用于观看实况事件（例如，作为用于观看棒球比赛的美国职业棒球联盟（MLB）的应用）或其他流的应用，可提供用户界面以呈现和控制（例如，可接收对媒体文件的选择）呈现，而另一个软件进程（例如，为如用于服务媒体的后台程序这样的媒体服务的软件进程，其可被称作“媒体服务”）可重新获取播放列表并获取和解码媒体文件。在一些情况下，可对媒体文件进行加密，由用户应用（例如，MLB应用）控制加密；例如，用户应用可将客户端证书（例如，提供认证、信任链和可撤回性的X.509证书）安装到其密钥链中（持久地或仅在存储器中），该密钥链可用于当建立HTTP安全套接字层（SSL）连接以下载用于对媒体内容进行解密的密钥时应答服务器询问。在其他情况下，播放列表包含用于一个或多个密钥的URL，所述密钥使用由用户应用或与用户应用交互的服务器所使用的自定义URL方案；在这种情况下，用户应用注册用于这些自定义URL方案的URL协议处理程序（handler），可调用这些处理程序以获得密钥（如新密钥），从而允许用户应用在带外传送密钥（例如，隐藏在它们的应用二进制中），或者使用私有协议从服务器获得密钥，该私有协议被用户应用和与用户应用交互的服务器理解，但不能被其他系统理解。
图17A示出允许媒体服务后台程序与用户应用交互的软件结构的实施例。该结构包括媒体服务后台程序（“媒体服务”）1710和示范性用户应用、事件媒体提供商（EMP）应用1720，二者在运行在客户端设备上的进程中都是可执行的，客户端设备例如，智能手机、个人数字助理、台式电脑、笔记本电脑、平板设备等。客户端设备的一个实施例可使用图8中所示的电子系统800来实现。在一些实施例中，媒体服务1710和EMP应用1720二者共享关于存储器控制、存储器空间、存储器分配、文件系统控制和网络控制的相同的特权。同样地，媒体服务1710可访问EMP应用1720可访问的数据。而且，阻止媒体服务1710访问EMP应用1720不能访问的数据。
在一些实施例中，EMP应用1720进一步包括核心媒体堆栈1721，核心媒体堆栈是用于访问网络堆栈1723的自定义软件堆栈，其又访问URL协议处理程序、EMP处理程序1725。EMP应用1720注册用于自定义URL方案的EMP处理程序1725，其可被调用以获得一个或多个密钥。因此，EMP应用1720可在带外传输密钥（例如，隐藏在应用二进制中）。
一般而言，媒体服务1710和EMP应用1720相互交互以下载和重放来自内容提供商的应用的用于现场流内容的媒体文件，在当前示例中，该内容提供商为EMP。重放可在客户端设备上的媒体服务1710中完成。在一些实施例中，媒体服务1710可下载用于对媒体文件进行解密的密钥，如果下载失败，媒体服务1710可请求EMP应用1720从内容提供商服务器下载密钥，在当前示例中该内容提供商服务器为EMP服务器1730。运行在客户端设备上的EMP应用1720可登记以获得一个或多个密钥。在一实施例中，EMP应用1720在下载媒体文件之前就已经登记并获得了密钥。下面讨论媒体服务1710和EMP应用1720之间交互的一些实施例的细节，以进一步阐述概念。
参照图17A，在一实施例中的EMP应用1720将具有至少一个URL和一个密钥的播放列表发送到媒体服务1710（1）。使用该密钥，媒体服务1710尝试在该URL访问由EMP提供的媒体源，并下载来自媒体源的播放列表中指定的媒体文件。可对媒体文件进行编码或加密以防止对媒体文件内容的未经授权的浏览。如果媒体服务1710未能下载媒体文件，或者它未能解码或解密所下载的媒体文件（2），那么媒体服务1710将该故障报告给EMP应用1720（3）。
响应于来自媒体服务1710的故障报告，EMP应用1720使用其核心媒体堆栈1721访问网络堆栈1723以请求新密钥（4），其接着为了新密钥而访问EMP处理程序1725（5）。EMP处理程序1725连接到网络（例如，互联网）上的EMP服务器1730以向EMP服务器1730请求新密钥（6）。响应于该请求，EMP服务器1730将新密钥发送给EMP处理程序（7）。然后，EMP处理程序1725将新密钥传递到核心媒体堆栈1721（8），其随后将新密钥传递到媒体服务1710（9）。
当媒体服务1710从核心媒体堆栈1721接收新密钥，媒体服务1710试着使用新密钥再次下载媒体文件，然后使用新密钥对下载的媒体文件进行解码（10）。可选地，如果之前成功下载了媒体文件，但媒体服务1710未能对媒体文件进行解密，那么媒体服务1710可试着使用新密钥对之前下载的媒体文件进行解密。如果媒体服务1710使用新密钥成功下载并解码媒体文件，那么EMP应用1720可在客户端设备上呈现解码的媒体文件。
图17B和17C示出可由独立于用户应用（例如，“AppX”）的播放器服务完成媒体文件处理（例如，播放列表的重新获取和播放列表中识别的媒体文件的重新获取，以及加密媒体文件的解码）的另一个实施例，该用户应用呈现和控制用于呈现来自经处理的媒体文件的内容的用户界面。媒体文件的处理与用户界面的控制之间的分离允许内容提供商创建唯一的用户界面，并通过由内容提供商或为内容提供商所创建的应用来呈现该用户界面，并且，它还允许内容提供商使用对反常的工程师很隐藏或困难的自定义URL或自定义协议以保护其内容。自定义URL或自定义协议可由内容提供商的应用（例如，“AppX”）以及与内容提供商的应用交互的系统（例如，由内容提供商或内容提供商代理控制的服务器）来控制。图17B示出在客户端设备1750上的软件结构的示例，客户端设备例如为智能手机、个人数字助理、台式电脑、笔记本电脑、平板设备、娱乐系统、或消费电子设备等。例如，客户端设备可以是图8中所示的系统。客户端设备1750可通过网络1752（例如，互联网或电话网络等）与一个或多个服务器1753进行交互和通信。一个或多个服务器可存储和传输播放列表（例如，播放列表1754）以及播放列表中涉及的媒体文件，并且这些服务器可由提供应用（例如，AppX）的内容提供商来控制，因此，将应用和服务器设计为利用自定义协议一同工作，以确保内容被保护或在控制内容分发的过程中提供更大的灵活性等。
客户端设备1750包括操作系统（OS）1756，该操作系统可包括播放器服务1757，尽管在另一个实施例中可独立于操作系统提供播放器服务。操作系统1756可维持用于存储应用（如AppX）注册的信息的注册表1755；该存储在注册表中的信息可包含显示自定义URL和使用该自定义URL的应用之间的关系的信息，以便播放器服务或OS调用使用自定义URL的应用以从该自定义URL中获取对象（例如，解密密钥）。也就是说，通过使用在播放列表中发现的自定义URL在注册表中查找相关应用（其可由与应用相关的标识符确定），注册表允许OS或播放器服务确定要调用的应用。在一实施例中，自定义URL由EXT‑X‑KEY标签指定，并且，作为该标签的参数，播放器服务被配置以接受被指定为http、https和注册的标识符（例如，在如注册表1755的注册表中已经注册的标识符）中的一个的URL。客户端设备1750包括一个或多个用户应用，如AppX 1751（或者，例如，美国职业棒球联盟（MLB）应用，或提供从一个或多个播放列表，如这里所描述的播放列表，中获得流内容的用户界面的其他应用）。这些应用可由提供内容的实体来提供（例如，MLB提供流向客户端并在MLB应用的用户界面中呈现的内容，棒球比赛，该MLB应用在客户端设备上执行），或者这些应用可由创建具有其他人创建的内容的一般用途播放器的用户界面的应用开发者提供。
可根据图17C所示的方法操作客户端设备1750和一个或多个服务器1753以解析不能被播放器服务，如播放器服务1757，识别的自定义URL。在图17C的操作1761中，例如AppX 1751的应用，当其被安装或安装之后，能够使得自定义URL被注册到注册表中，如注册表1755。在一实施例中，作为安装过程的一部分，应用可调用操作系统1756以使得其一个或多个自定义URL同将这些一个或多个自定义URL与应用相关联的标识符一起被存储到注册表1755中。在安装之后，可由用户启动和使用应用，该步骤可在操作1763中当用户在应用中做出选择以使得应用呈现选择的HTTP流时发生。响应于该输入，在操作1765，应用调用（在图17B的调用2中）播放器服务1757以呈现（例如，显示）HTTP流。在操作1767，播放器服务取回（调用3）由用户输入指定的播放列表，并确定播放列表中包含不能被播放器服务识别或支持的自定义URL；在图17B的情况下，自定义URL针对播放器服务用来对播放列表中涉及的媒体文件进行解密的解密密钥；在确定播放列表包含自定义URL的基础上，播放器服务调用操作系统1756（调用4）来检查注册表1755以确定应当被请求用来解析或使用自定义URL的应用。在操作1769，操作系统1756确定播放列表中的自定义URL将被AppX 1751解析，操作系统1756接着调用（调用5）AppX 1751以使得AppX使用自定义URL取回对象（在这种情况下为由AppX用来对呈现内容进行解密的解密密钥）。在操作1771，AppX 1751可以接收来自操作系统1756的调用并作为响应可确定要使用的URL，并且调用操作系统（调用6）以使用AppX 1751确定的URL取回对象（在这种情况下为解密密钥）。然后在操作1773，操作系统1756接收对象并将其传递到AppX 1751，AppX 1751随后将该对象传递到播放器服务1757以允许播放器服务使用该对象处理播放列表或媒体文件或二者（如在操作1775中）。在操作1773的一个可替换实施例中，操作系统1756一旦接收到对象就可将其直接传递到播放器服务1757。
图17D示出由应用，如AppX，执行的为了使用自定义URL的方法的示例。该方法可与图17A中所示的软件结构一同使用。在操作1780，应用，如AppX，可以使得其一个或多个自定义URL被注册；该注册可以在应用的安装过程中或在第一次启动应用时完成。在应用被启动之后，其可接收用户输入，例如HTTP流的选择（在操作1781），并且作为响应，应用可以调用（例如，通过API）播放器服务以呈现HTTP流。如果HTTP流的播放列表包含不能被播放器服务识别或处理的自定义URL，那么应用从播放器服务或操作系统中接收调用（在操作1783），以使得应用解析由应用注册的自定义URL（例如，appx://appx.com/key）。在操作1784，应用随后可响应于操作1783中的调用对自定义URL进行解析；该解析可包括预定的、专有的（对于应用）方案，该方案包括基于例如应用的特权（例如，保护等级或应用开销）、内容要求、请求浏览内容的日期和时间等确定合法的URL。在解析自定义URL之后，应用可调用操作系统或网络堆栈以从耦合到网络（例如，互联网）的远程服务器请求由自定义URL表示的对象（例如，解密密钥）。操作系统或网络堆栈可获得对象（例如，通过将解析的URL发送到以对象作为响应的服务器），并使得该对象被传递到播放器服务（直接地或通过应用）；如果对象被直接传递到播放器服务，那么操作1785可由组件执行，而不是由应用执行。
图17E示出可由设备上的播放器服务和操作系统之一或二者执行的为了使用自定义URL的方法的示例。该方法可与图17A中所示的软件结构一起使用。在操作1790，播放器服务从应用（例如，AppX）接收调用以呈现HTTP流，并在操作1791中，作为响应，播放器服务可使用在请求中指定的数据取回该应用中描述的播放列表。然后，在操作1792，播放器服务可确定播放列表包含自定义URL，并且随后在操作1793中调用操作系统使其检查注册表，如注册表1755，以确定自定义URL是否已经被注册；或者，播放器服务可以自己调用服务来检查注册表。检查注册表的结果可确定注册自定义URL的应用（或可确定没有这样的注册，在这种情况下，播放器服务可显示HTTP流不可用的错误消息）。如果应用在用于自定义URL的注册表中被识别，那么，在操作1794，播放器服务或操作系统调用应用，并将自定义URL传递到应用以促使应用解析自定义URL。在应用解析自定义URL之后，其促使对象（例如，解密密钥）被获得，并且在操作1795，播放器服务接收对象（通过应用，或通过网络堆栈或操作系统组件）。在接收对象之后，在操作1796，播放器服务可处理播放列表中涉及的媒体文件，通过例如取回每个媒体文件并使用对象对其进行解码以及对其进行显示。
本发明的另一个实施例使用分布式系统，该系统利用至少两个设备以使用本文所描述的播放列表和流式方法提供重放。图20、21、22A和22B提供了这样的分布式系统的一个示例，其中一个设备可启动在另一个设备上的远程重放，该另一个设备驱动和提供输出给TV或其他呈现设备，如立体音响系统等。参照图20，第一设备2001被配置成通过例如有线网络或无线网络或如有线连接这样的直接连接与第二设备2003通信。在一实施例中，第一设备可以是平板电脑或笔记本电脑或智能手机，第二设备可以是机顶盒或音频/视频控制器，如加州库佩蒂诺的苹果公司的Apple TV。在一实施例中，第一设备可以是加州库佩蒂诺的苹果公司的iPad。设备2001和2003中每一个都可以是电子系统，如结合图8描述的电子系统，并可包括一个或多个处理器、存储器和外围设备，如输入或输出或输入/输出接口。在一实施例中，设备2001和2003中每一个都包括允许设备加入WiFi无线网络的无线网络接口。在一实施例中，连接2005可以是与WiFi网络的连接，在其他实施例中，可使用其他无线连接或有线连接将两个设备2001和2003相联结。设备2003包括到呈现设备如TV或立体音响系统的输出，该输出提供媒体的远程呈现，该呈现可通过在应用或应用，如设备2001上的应用2007，中选择该媒体来启动。
设备2001可包括多个软件组件，其中该软件组件包括例如应用或应用2007，应用2007可以是例如用于在设备2001上呈现棒球比赛的美国职业棒球应用或用于通过本文所描述的流式方法呈现电影或其他内容的Netflix应用或应用的应用。设备2001还包括类似于图17B中所示的播放器服务1757或图17A中所示的媒体服务器后台程序1710的媒体服务器2009。设备2001还包括远程重放服务2011，其是在第一和第二设备之间提供接口的软件组件，用于通过第二设备允许选择或启动的内容在第一设备上远程重放，然后该第二设备输出内容到与第二设备2003的输出相联结的呈现设备，如TV。可由第一设备的用户激活或选择远程重放服务，使其与第二设备通信以通过第二设备促使远程重放到与第二设备的输出相联结的呈现设备上，如TV上。在一实施例中，远程重放服务可以是由苹果公司的iPad或iPhone上提供的AirPlay设备的一部分。设备2001还包括操作系统2013，其提供操作系统的标准的和已知的服务，以使得设备具有本领域已知的一个或多个应用的功能。
第二设备还可包括媒体服务器2017，其类似于媒体服务器或播放器服务1757，或者类似于图17A中的媒体服务器后台程序1710。此外，第二设备2003还包括操作系统2019和远程重放后台程序2015。在一实施例中，远程重放后台程序2015是作为后台进程的后台程序，其在第二设备启动时被启动，并被配置用于监视某些命令，如“播放”URL命令或“播放”URL调用，然后被配置成将该调用提供给媒体服务器，如媒体服务器2017。后台程序可作为后台进程操作，并在启动时启动自己，而不需要来自第二设备2003的用户的任何交互。也可以理解为应用2007类似与图17B中的应用1751。
在一可替代实施例中，媒体服务器和每个设备的远程重放部分可以结合在一起以便在合并对象之间不需要公开的API调用。
图21示出如何利用一系列调用和返回使用图20中所示的软件结构，以提供图20中所示的分布式系统的环境中自定义URL的使用，其中，可由第一设备启动重放并由第二设备远程地将重放通过第二设备的输出提供给呈现设备，如TV或立体音响系统或TV和立体音响系统的组合。调用和调用的返回被显示为带圈的数字。例如，第一设备2001中的应用进行调用以播放URL到媒体服务器，该调用在图21中示出为的圆圈中的“1”。现在将结合图22A和22B中所示的方法进一步讨论软件组件的交互以及这些组件之间的调用。
现参照图22A和22B，方法由操作2025开始，在两个设备，如两个无线网络设备，之间建立连接，设备之一被建立以允许其在第二设备上或通过第二设备播放和控制媒体。在一实施例中，第一设备可以是平板电脑或笔记本电脑或其它包含应用如应用2007的数据处理系统，用户可使用该设备通过第二设备或在第二设备上远程地选择要被呈现的内容。在一实施例中，第一设备可包括输出，如显示器，用于当通过第二设备在呈现设备，例如TV或第二设备的其他显示器，上呈现媒体时也显示相同的媒体。在一实施例中，第一设备的用户可选择远程重放模式，如iPad上的AirPlay模式，并在这种情况下建立第一设备以允许其在第二设备上控制和播放媒体；类似地，该设置还可建立设备之间的连接。可以理解，操作2025和2027的顺序可以颠倒，并且可在启动应用并选择重放媒体之后建立该连接。在操作2027，系统响应用户请求或自动地由第一设备启动应用，并接收重放视频或其它媒体的请求。例如，用户在iPad上启动Netflix应用，然后在Netflix应用中选择特定视频或其它内容以进行重放。响应于用于重放的特定视频或其它媒体的选择，在操作2029，第一设备上的应用调用第一设备上的媒体服务器以播放用于播放列表的URL。该调用如图21中调用1所示。作为响应，第一设备上的媒体服务器确定远程重放模式是否已经被选择或使能。如果没有，那么重放通过第一设备以图17A‑17E中所描述的方式出现，如果需要解析自定义URL的话。另一方面，如果远程重放模式已经被选择或使能，那么第一设备上的媒体服务器通过图21中的调用2调用远程重放服务。实际上，该调用将URL传递到第二设备上的远程重放后台程序2015，该URL可以是用于播放列表的URL或用于播放列表中的密钥的URL。该调用如图21中调用3所示。在操作2031，远程重放后台程序，如远程重放后台程序2015，从第一设备接收URL并调用第二设备上的媒体服务器播放该URL；该调用如图21中调用4所示。作为响应，第二设备上的媒体服务器2017确定该URL为媒体服务器2017不能处理的自定义URL。在一实施例中，自定义URL为任何不属于标准URL方案的URL，该标准URL方案如HTTP方案、HTTPS方案、文件方案或DAV方案。自定义URL方案将被应用理解，就如何解码和处理自定义URL以取回由该URL指向的数据或内容而言。
然后在操作2035，第二设备上的媒体服务器，如媒体服务器2017，调用第二设备上的远程重放后台程序，如远程重放后台程序2015，以请求对自定义URL的解析。作为响应，远程重放后台程序通过图21中所示的调用6调用远程重放服务。然后在操作2039，远程重放服务，如第一设备上的远程重放服务2011，接收解析自定义URL的请求，并在调用7中调用媒体服务器，如第一设备上的媒体服务器2009，对自定义URL进行解析。接着在操作2041，媒体服务器2009接收自定义URL并调用应用如应用2007（在一实施例中，在查阅注册表以确定要调用的合适的应用之后），以对自定义URL进行解析。对应用的调用如图21中调用8所示。然后，在操作2043，应用解析URL并返回自定义URL的内容，如密钥或播放列表或由自定义URL指向的其他内容，并且该内容被返回到第一设备上的媒体服务器，如图21中的返回9所示。然后在操作2045，第一设备上的媒体服务器将自定义URL的内容返回到远程重放服务，如远程重放服务2011，其转而将该URL的内容返回到第二设备上的远程重放后台程序，该远程重放后台程序随后将该URL的内容返回给第二设备上的媒体服务器。此时，在操作2049，第二设备上的媒体服务器可使用该URL的内容处理重放过程，该内容可以是密钥或播放列表，并且每当媒体服务器2017遇到自定义URL时，这一过程可根据需要重复。在这种情况下，当遇到自定义URL，可由图21中所示的调用5开始重复这一过程，并以图22A中的操作2035开始，通过自定义URL调用的解析继续，再次以操作2047结束。
可以理解，在操作2047，如果URL的内容为密钥，那么该密钥将被用于对媒体文件进行解密，如果内容为播放列表，那么第二设备上的媒体服务器将根据本公开其余部分的描述使用播放列表以取回并解码由该播放列表指定的媒体文件。如果该播放列表中的密钥也由自定义URL指定，那么该过程将再次重复，如上文所述从操作2035开始到操作2047结束。
图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以存储信息和指令。数据存储设备如闪存存储器或磁盘或光盘以及相应的驱动器可被耦合到电子系统800。
电子系统800还通过总线805与显示设备850耦合，如阴极射线管（CRT）或液晶显示器（LCD），以向用户显示信息。电子系统800还包括字母数字输入设备860，其包括字母数字和其他键，可耦合到总线805以传送信息和命令选择给处理器810。另一类型的用户输入设备为光标控制器870，如触控板、鼠标、轨迹球或光标方向键，以传送方向信息和命令选择给处理器810并在显示器850上控制光标移动。
电子系统800进一步包括一个或多个网络接口880以提供对网络如局域网的访问。网络接口880包括例如具有天线885的无线网络接口，该天线885可表示一个或多个天线。电子系统800可包括多个无线网络接口，如WiFi、蓝牙和移动电话接口的组合。网络接口880还可包括例如有线网络接口，以通过网络电缆887与远程设备进行通信，该网络电缆可以是例如以太网电缆、同轴电缆、光纤电缆、串行电缆或并行电缆。
在一实施例中，网络接口880提供对局域网的访问，例如，通过遵循IEEE 802.11b和/或IEEE 802.11g标准，和/或无线网络接口提供对个人区域网络的访问，例如，通过遵循蓝牙标准。其他无线网络接口和/或协议也可以得到支持。
除了或者替代通过无线LAN标准的通信，网络接口880使用例如时分多址（TDMA）协议、全球移动通信系统（GSM）协议、码分多址（CDMA）协议和/或任何其他类型的无线通信协议提供无线通信。
在一些实施例中可使用一个或多个应用编程接口（API）。API为由程序代码组件或硬件组件（以下称为“API‑执行组件”）执行的接口，其允许不同的程序代码组件或硬件组件（以下称为“API‑调用组件”）访问和使用一个或多个功能、方法、过程、数据结构、类和/或由API‑执行组件提供的其他服务。API可定义在API‑调用组件和API‑执行组件之间传递的一个或多个参数。
API允许API‑调用组件的开发者（可以是第三方开发者）利用由API‑执行组件提供的指定特征。可以有一个API‑调用组件，也可以有多个这样的组件。API可以是计算机系统或程序库为了支持从应用请求服务而提供的源代码接口。操作系统（OS）可具有多个API以允许运行在该OS上的应用调用那些API中的一个或多个，并且，服务（如程序库）可具有多个API以允许使用该服务的应用调用那些API中的一个或多个。API可以以编程语言的形式指定，当构建应用时可解释或编译该编程语言。
在一些实施例中，API‑执行组件可提供不止一个API，每一个API都为由API‑执行组件执行的功能提供不同的观点或具有访问不同方面的功能方面的不同方面。例如，API‑执行组件的一个API可以提供第一组功能并对第三方开发者可见，API‑执行组件的另一个API可以被隐藏（不可见）并提供第一组功能的子集以及另一组功能，如不在第一组功能中的测试或调试功能。在其他实施例中，API‑执行组件自身可通过隐含的API调用一个或多个其他组件，因此其既是API‑调用组件又是API‑执行组件。
API定义当访问和使用API‑执行组件的指定特征时API‑调用组件使用的语言和参数。例如，API‑调用组件通过由该API表示的一个或多个API调用和激活（例如通过函数或方法调用体现）来访问API‑执行组件的指定特征，并通过API调用或激活使用参数传递数据和控制信息。响应于来自API‑调用组件的API调用，API‑执行组件通过该API返回一值。虽然API定义API调用的语法和结果（例如，如何调用API调用和该API调用的作用），但API不能显示API调用如何完成由该API调用指定的特征。不同的API调用通过一个或多个应用编程接口在调用（API‑调用组件）和API‑执行组件之间传输。API调用的传输可包括发布、启动、激活、调用、接收、返回或响应函数调用或消息；也就是说，传输既可描述API‑调用组件的动作，也可描述API‑执行组件的动作。函数调用或API的其他调用可通过参数列表或其他结构发送或接收一个或多个参数。参数可以是常量、关键词、数据结构、对象、对象类、变量、数据类型、指针、数组、列表、指向函数或方法的指针，或引用由API所传递的数据或其他项目的其他方法。
另外，数据类型或类可由API提供并由API‑执行组件执行。因此，API‑执行组件可声明变量、使用指针通过使用API中提供的定义来使用或实例化这种类型和类的常量值。
通常，API可用于访问由API‑执行组件提供的服务或数据，或用于启动由API‑执行组件提供的操作或计算的执行。举例来说，API‑执行组件和API‑调用组件每个都可以是操作系统、库、设备驱动器、API、应用或其他模块中的任何一个（应当理解的是，API‑执行组件和API‑调用组件彼此之间可以是相同或不同的模块类型）。在某些情况下，API‑执行组件至少部分以固件、微代码或其他硬件逻辑来体现。在一些实施例中，API可允许客户端程序使用由软件开发包（SDK）库所提供的服务。在其他实施例中，应用或其他客户端程序可使用由应用框架提供的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，如来自操作系统提供商的一组API和来自插件提供商的另一组API以及来自另一个提供商（例如，软件库提供商）或该另一组API的创建者的另一组API。
图18为示出一示例性API结构的框图，其可被用于本发明的一些实施例中。如图18所示，API结构1800包括执行API 1820的API‑执行组件1810（例如，操作系统、库、设备驱动器、API、应用、软件或其他模块）。API 1820指定一个或多个函数、方法、类、对象、协议、数据结构、格式和/或由API‑调用组件1830使用的API‑执行组件的其他特征。API 1820可以指定至少一个调用惯例，该惯例指定API‑执行组件中的函数如何从API‑调用组件接收函数以及该函数如何返回结果到API‑调用组件。API‑调用组件1830（例如，操作系统、库、设备驱动器、API、应用、软件或其他模块）通过API 1820执行API调用以访问和使用由API 1820指定的API‑执行组件1810的特征。响应于API调用，API执行组件1810通过API 1820返回一值到API‑调用组件1830。
可以理解，API‑执行组件1810可包括附加函数、方法、类、数据结构、和/或没有通过API 1820指定并且对API‑调用组件1830不可用的其他特征。应当理解的是，API‑调用组件1830可与API‑执行组件1810在同一系统上，或者可远程定位并使用网络上的API 1820访问API‑执行组件1810。虽然图18示出与API 1820交互的单个API‑调用组件1830，但应当理解，以不同于API‑调用组件1830的语言（或与其相同的语言）编写的其他API‑调用组件也可以使用API 1820。
API‑执行组件1810、API 1820和API‑调用组件1830可被存储于机器可读的非暂时性存储介质，该存储介质包括用于以机器（例如，计算机或其他数据处理系统）可读的形式存储信息的任何机制。例如，机器可读介质包括磁盘、光盘、随机存取存储器、只读存储器、闪速存储器设备等。
在图19（“软件堆栈”）中，一个示例性实施例，应用可使用多个服务API调用服务1或2并使用多个操作系统API来调用操作系统（OS）。服务1和2可使用多个操作系统API调用操作系统。
注意到服务2有两个API，其中一个（服务2的API 1）接收来自应用1的调用并返回值到应用1中，另一个（服务2的API 2）接收来自应用2的调用并返回值到应用2。服务1（例如，可以是软件库）调用操作系统API 1并接收来自操作系统API 1的返回值，服务2（例如，可以是软件库）调用操作系统API 1和操作系统API 2并接收来自操作系统API 1和操作系统API 2的返回值。应用2调用操作系统API 2并接收来自操作系统API 2的返回值。
在本说明书中引用的“一个实施例”或“一实施例”表示结合该实施例描述的特定特征、结构或特性被包括在本发明的至少一个实施例中。在本说明书中不同位置出现的短语“在一实施例中”不一定都指的是同一个实施例。
在之前的说明书中，本发明通过参考特定实施例的方式来描述。但是，很明显在不背离本发明宽泛的精神和范围的前提下，可以对其做出各种修改和变化。相应地，说明书和附图被认为是阐述意义而不是限制意义。
在一实施例中，一种存储可执行指令的机器可读的非暂时性存储介质，当指令被数据处理系统执行时，可使得该系统执行如下方法：
在客户端设备上执行一用户应用以呈现媒体文件并控制所述媒体文件的呈现；以及
在所述客户端设备上运行一媒体服务进程，独立于所述用户应用，以取回指定所述媒体文件的播放列表以及所述媒体文件可用的媒体源，从所述媒体源取回所述媒体文件，并对取回的所述媒体文件进行解码以及将来自所述媒体文件的解码内容提供给所述用户应用。
在一实施例中，其中所述媒体服务进程和所述用户应用对存储器控制、存储器空间、存储器分配、文件系统控制和网络控制共享相同的特权。
在一实施例中，其中所述用户应用提供一用户界面以控制所述显示并且通过一应用编程接口（API）与所述媒体服务进程通信，并且其中所述用户应用和所述媒体服务进程是不同的软件进程。
在一实施例中，其中所述媒体服务进程取回媒体文件，所述媒体文件是使用由所述用户应用处理或者由所述用户应用取回并处理的密钥进行解码的。
在一实施例中，其中所述用户应用安装一客户端证书，所述证书用于在创建连接以下载解密密钥时应答服务器的询问。
在一实施例中，其中所述播放列表包含用于使用自定义URL方案的解密密钥的URL。
在一实施例中，其中当所述媒体服务进程下载或解密媒体文件失败时，所述媒体服务进程通过所述API调用所述用户应用以使得所述用户应用取回一个或多个返回到所述媒体服务进程的密钥。
在一实施例中，其中所述媒体服务进程取回媒体文件，所述媒体文件是使用由所述用户应用处理或者由所述用户应用取回并处理的密钥进行解码的。
在一实施例中，其中所述用户应用安装一客户端证书，所述证书用于在创建连接以下载解密密钥时应答服务器的询问。
在一实施例中，其中所述播放列表包含用于使用自定义URL方案的解密密钥的URL。
在一实施例中，由数据处理系统执行的机器执行方法，所述方法包括：
在客户端设备上执行一用户应用以呈现媒体文件并控制所述媒体文件的呈现；以及
在所述客户端设备上运行的一媒体服务进程，独立于用户应用，以取回指定所述媒体文件的播放列表以及所述媒体文件可用的媒体源，从所述媒体源取回所述媒体文件，并对取回的所述媒体文件进行解码以及将来自所述媒体文件的解码内容提供给所述用户应用。
在一实施例中，其中所述媒体服务进程和所述用户应用对存储器控制、存储器空间、存储器分配、文件系统控制和网络控制共享相同的特权。
在一实施例中，其中所述用户应用和所述媒体服务进程通过一API进行通信，并且其中所述用户应用和所述媒体服务进程是不同的软件进程。
在一实施例中，其中所述媒体服务进程取回媒体文件，所述媒体文件是使用由所述用户应用处理或者由所述用户应用取回并处理的密钥进行解码的。
在一实施例中，其中所述用户应用安装一客户端证书，所述证书用于在创建连接以下载解密密钥时应答服务器的询问。
在一实施例中，其中所述播放列表包含用于使用自定义URL方案的解密密钥的URL。
在一实施例中，其中所述媒体服务进程获取媒体文件，所述媒体文件是使用由所述用户应用处理或者由所述用户应用取回并处理的密钥进行解码的，并且其中所述用户应用安装一客户端证书，所述证书用于在创建连接以下载解密密钥时应答服务器的询问，并且其中所述播放列表包含用于使用自定义URL方案的解密密钥的URL。
在一实施例中，一种数据处理系统包括：
用于在客户端设备上执行一用户应用以呈现媒体文件并控制所述媒体文件的呈现的装置；以及
用于在所述客户端设备上运行一媒体服务进程的装置，其独立于用户应用，用以取回指定所述媒体文件的播放列表以及所述媒体文件可用的媒体源，从所述媒体源取回所述媒体文件，并对取回的所述媒体文件进行解码以及将来自媒体文件的解码内容提供给所述用户应用。
在一实施例中，其中所述媒体服务进程和所述用户应用对存储器控制、存储器空间、存储器分配、文件系统控制和网络控制共享相同的特权。
在一实施例中，一种存储可执行指令的机器可读的非暂时性存储介质，当所述指令被数据处理系统执行时，可使得该系统执行如下方法：
在客户端设备上执行一用户应用以呈现媒体文件并控制所述媒体文件的呈现；以及
在所述客户端设备上运行一媒体服务进程，独立于用户应用，以取回指定所述媒体文件的播放列表以及所述媒体文件可用的媒体源，从所述媒体源取回所述媒体文件，并对取回的所述媒体文件进行解码；
通过所述媒体服务器接收所述播放列表中的一URL，所述URL涉及所述媒体服务器使用的用于解密至少一个所述媒体文件的数据；
由所述媒体服务器调用所述用户应用以处理所述URL来获得所述媒体服务器使用的所述数据；
响应于所述用户应用处理所述URL以获得所述数据而接收所述数据；
使用所述数据解码至少一个所述媒体文件。
在一实施例中，其中所述数据是一解密密钥。
在一实施例中，一种存储在机器可读的非暂时性介质上的用户应用执行由所述用户应用执行的权利要求20中的那些部分。
在一实施例中，一种存储在机器可读的非暂时性介质上的媒体服务器执行由所述媒体服务器进程执行的权利要求20中的那些部分。
在一实施例中，其中所述用户应用使用一自定义URL，所述URL用于保护通过所述用户应用提供的内容。
在一实施例中，其中一注册表存储所述自定义URL和所述用户应用之间的关系，并且其中当所述媒体服务器不能解码媒体文件时，所述媒体服务器检查所述注册表以调用所述用户应用。
在一实施例中，其中所述自定义URL由一EXT‑X‑KEY标签指定。
在一实施例中，其中所述用户应用由所述媒体文件的提供者授权。
在一实施例中，其中所述用户应用将自定义URL和所述用户应用之间的关系注册到一注册表，所述自定义URL用于为所述媒体文件取回一个或多个解密密钥，并且其中当所述用户应用第一次被安装或第一次被启动时，所述用户应用将所述关系注册到所述注册表。
在一实施例中，其中所述关系将所述媒体服务器指向使用所述自定义URL的所述用户应用。
在一实施例中，其中所述自定义URL不被所述媒体服务器所支持。
在一实施例中，其中所述自定义URL用于取回被提供给所述媒体服务器以对所述播放列表中的所述媒体文件进行解码的所述解密密钥。
在一实施例中，其中所述用户应用对自定义URL的解析取决于如下条件中的至少一个：（a）所述用户应用的相对于所述媒体文件中的内容的特权等级；（b）所述媒体文件中的内容；（c）显示所述媒体文件中的内容的请求的日期或时间或日期和时间。
在一实施例中，其中所述解密密钥通过所述用户应用被返回给所述媒体服务器。
在一实施例中，一种存储可执行指令的机器可读的非暂时性存储介质，当指令被数据处理系统执行时，可使得该系统执行如下方法：
在客户端设备上执行一用户应用，所述用户应用被配置以控制所述媒体文件的显示；以及
在所述客户端设备上运行一媒体服务进程，独立于用户应用，以取回指定所述媒体文件的播放列表以及所述媒体文件可用的媒体源，从所述媒体源取回所述媒体文件，并对取回的所述媒体文件进行解码；
通过所述媒体服务器接收在所述播放列表中或用于所述播放列表的一URL，所述URL涉及被用于处理至少一个所述媒体文件的数据；
由所述媒体服务器调用所述用户应用以处理所述URL来获取远程媒体服务器使用的数据；
响应于所述用户应用处理所述URL以获得所述数据而接收所述数据；
传输所述数据到所述远程媒体服务器。
在一实施例中，其中所述URL是用于其中一个播放列表的一个自定义URL或者是用于所述播放列表中至少一个媒体文件的一个解密密钥，并且其中所述用户应用使用所述自定义URL保护通过所述用户应用提供的内容。
在一实施例中，其中一注册表存储所述自定义URL和所述用户应用之间的关系，并且其中当所述媒体服务器不能处理所述URL时，所述媒体服务器检查所述注册表以调用所述用户应用。
在一实施例中，其中所述远程媒体服务器是一机顶盒的一部分，被配置以取回和处理一播放列表，并被配置以产生被传输回所述媒体服务器的一消息，以请求对所述自定义URL的解析，并且其中传输数据到所述媒体服务器提供了对所述自定义URL的解析。
在一实施例中，一种提供输出给一显示装置的设备，该设备包括：
一远程重放组件，被配置以允许所述设备由另一设备创建以控制；
一媒体服务器组件，所述媒体服务器组件被配置以取回并处理指示媒体文件的播放列表以及取回并解码所述播放列表中指示的媒体文件，并且所述媒体服务器组件被配置以产生一消息以解析一自定义URL，所述URL或者表示所述播放列表，或者表示所述播放列表中的数据，并且所述远程重放组件被配置以将所述消息传递给所述另一设备；
一输出装置，用于为所述显示装置提供视频数据或音频数据或者视频数据和音频数据，所述输出装置耦合到提供所述视频数据或音频数据或者所述视频数据和音频数据的所述媒体服务器组件；
一输入/输出（I/O）接口，耦合到所述远程重放组件，所述I/O接口被配置以从所述媒体服务器组件传递所述消息以解析一自定义URL，并且所述I/O接口被配置以将所述自定义URL的解析传递到所述媒体服务器组件，以允许所述输出提供所述视频数据或音频数据或者所述视频数据和音频数据，并且其中所述另一设备上的应用解析所述自定义URL并通过I/O接口提供所述URL的解析。
在一实施例中，一种数据处理系统包括：
用于在一客户端设备上执行一用户应用以呈现媒体文件并控制所述媒体文件的呈现的装置；以及
用于在所述客户端设备上运行一媒体服务进程的装置，其独立于所述用户应用，用以取回指定所述媒体文件的播放列表以及所述媒体文件可用的媒体源，从所述媒体源取回所述媒体文件，并对取回的所述媒体文件进行解码以将来自所述媒体文件的解码内容提供给所述用户应用。
在一实施例中，其中所述媒体服务进程和所述用户应用对存储器控制、存储器空间、存储器分配、文件系统控制和网络控制共享相同的特权。
在一实施例中，其中所述用户应用提供一用户界面以控制所述显示并且通过一应用编程接口（API）与所述媒体服务进程通信，并且其中所述用户应用和所述媒体服务进程是不同的软件进程。
在一实施例中，其中所述媒体服务进程取回媒体文件，所述媒体文件是使用由所述用户应用处理或者由所述用户应用取回并处理的密钥进行解码的。
在一实施例中，其中所述用户应用安装一客户端证书，所述证书用于在创建连接以下载解密密钥时应答服务器的询问。
在一实施例中，其中所述播放列表包含用于使用自定义URL方案的解密密钥的URL。
在一实施例中，其中当所述媒体服务进程下载或解密媒体文件失败时，所述媒体服务进程通过所述API调用所述用户应用以使得所述用户应用取回一个或多个返回到所述媒体服务进程的密钥。
在一实施例中，其中所述媒体服务进程取回媒体文件，所述媒体文件是使用由所述用户应用处理或者由所述用户应用取回并处理的密钥进行解码的。
在一实施例中，其中所述用户应用安装一客户端证书，所述证书用于在创建连接以下载解密密钥时应答服务器的询问。
在一实施例中，其中所述播放列表包含用于使用自定义URL方案的解密密钥的URL。
在一实施例中，一种数据处理系统包括：
一客户端设备上的一用户应用，用以显示媒体文件并控制所述媒体文件的显示；以及
所述客户端设备上的一媒体服务进程，其独立于用户应用，用以取回指定所述媒体文件的播放列表以及所述媒体文件可用的媒体源，从所述媒体源取回所述媒体文件，并对取回的所述媒体文件进行解码以及提供来自所述媒体文件的解码内容给所述用户应用。
在一实施例中，其中所述媒体服务进程和所述用户应用对存储器控制、存储器空间、存储器分配、文件系统控制和网络控制共享相同的特权，并且其中所述用户应用和所述媒体服务进程通过一API进行通信，并且其中所述用户应用和所述媒体服务进程是不同的软件进程。
在一实施例中，其中所述媒体服务进程取回媒体文件，所述媒体文件是使用由所述用户应用处理或者由所述用户应用取回并处理的密钥进行解码的。
在一实施例中，其中所述用户应用安装一客户端证书，所述证书用于在创建连接以下载解密密钥时应答服务器的询问。
在一实施例中，其中所述播放列表包含用于使用自定义URL方案的解密密钥的URL。
在一实施例中，一种数据处理系统包括：
用于在客户端设备上执行一用户应用以显示媒体文件并控制所述媒体文件的显示的装置；以及
用于在所述客户端设备上运行一媒体服务进程的装置，其独立于所述用户应用，用以取回指定所述媒体文件的播放列表以及所述媒体文件可用的媒体源，从所述媒体源取回所述媒体文件，并对取回的所述媒体文件进行解码；
用于通过所述媒体服务器接收一URL的装置，所述URL涉及所述媒体服务器使用的用于解密或显示至少一个所述媒体文件的数据；
用于由所述媒体服务器调用所述用户应用以处理所述URL以获得所述媒体服务器使用的所述数据的装置；
用于响应于所述用户应用处理所述URL以获得所述数据而接收所述数据的装置；
用于使用所述数据解码至少一个所述媒体文件的装置。
在一实施例中，其中所述数据是一解密密钥。
在一实施例中，其中所述用户应用使用一自定义URL，所述URL用于保护通过所述用户应用提供的内容。
在一实施例中，其中一注册表存储所述自定义URL和所述用户应用之间的关系，并且其中当所述媒体服务器不能解码一媒体文件时，所述媒体服务器检查所述注册表以调用所述用户应用。
在一实施例中，其中所述自定义URL由一EXT‑X‑KEY标签指定。
在一实施例中，其中所述用户应用由所述媒体文件的一提供者授权。
在一实施例中，其中所述用户应用将自定义URL和所述用户应用之间的关系注册到一注册表，所述自定义URL用于为所述媒体文件取回一个或多个解密密钥，并且其中当所述用户应用第一次被安装或第一次被启动时，所述用户应用将所述关系注册到所述注册表。
在一实施例中，其中所述关系将所述媒体服务器指向使用所述自定义URL的所述用户应用。
在一实施例中，其中所述自定义URL不被所述媒体服务器所支持。
在一实施例中，其中所述自定义URL用于取回被提供给所述媒体服务器以对所述播放列表中的所述媒体文件进行解码的所述解密密钥。
在一实施例中，其中所述用户应用对自定义URL的解析取决于如下条件中的至少一个：（a）所述用户应用的相对于所述媒体文件中的内容的特权等级；（b）所述媒体文件中的内容；（c）显示所述媒体文件中的内容的请求的日期或时间或日期和时间。
在一实施例中，其中所述解密密钥通过所述用户应用被返回给所述媒体服务器。
附录
下面的附录是根据本发明一个特定实施例的协议草案说明。需要理解的是该附录中的一些关键词（比如：必须，不允许，应当，不得，等等）的使用只适用于该特定实施例，而不适用于本发明描述的其他实施例。
摘要
本文档描述了一种用于传输无限多媒体数据流的协议。详述了文件的数据格式以及流的服务器（发送者）和客户端（接收者）将采取的动作。描述了该协议的第二版本。
目录
1.引言
2.概述
3.播放列表文件
3.1引言
3.2新标签
3.2.1EXT‑X‑TARGETDURATION
3.2.2EXT‑X‑MEDIA‑SEQUENCE
3.2.3EXT‑X‑KEY
3.2.4EXT‑X‑PROGRAM‑DATE‑TIME
3.2.5EXT‑X‑ALLOW‑CACHE
3.2.6EXT‑X‑ENDLIST
3.2.7EXT‑X‑STREAM‑INF
3.2.8EXT‑X‑DISCONTINUITY
3.2.9EXT‑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.参考文献
规范性文献
参考性文献
1.引言
本文档描述了一种用于传输无限多媒体数据流的协议。该协议支持媒体数据的加密和流替代版本（比如比特率）的提供。媒体数据可以在创建后很快被传输，从而允许近似实时的播放。数据通常由HTTP承载【RFC2616】。
在11节中列举描述比如HTTP的相关标准的外部参考文献。
2.概述
一多媒体演示（或呈现）被一个URI【FRC3986】指定到播放列表文件，该文件是媒体URI和信息标签的序列表。每个媒体URI涉及一个媒体文件，该文件是一单独的、连续的流的分段。
为了播放流，客户端首先获取播放列表文件，然后获取并播放该播放列表中的每个媒体文件。如同该文档中描述的，客户端重新加载播放列表文件来发现其他的分段。
该文档中的关键词“必须”，“不允许”，“必需的”，“应当”，“不得”，“应该”，“不应该”，“推荐的”，“可能”和“可选择的”将按照RFC 2119【RFC 2119】中的描述予以解释。
3.播放列表文件
3.1引言
播放列表必须是扩展的M3U播放列表文件【M3U】。该文档通过定义额外的标签来扩展M3U文件格式。
M3U播放列表是包含单独的行的文本文件。行或者是以单个LF字母结束，或者是以一个LF字母跟随的CR字母结束。每一行是一URI、一空格或者由注释符‘#’开头。忽略空白行。除非元素中有特别说明，否则空格是不允许出现的。
一个URI行标识一个媒体文件或者一个不同的播放列表文件（参见章节3.2.7）
URI可以是相关的。必须针对包含相关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文件的首行必须是#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‑DISCONTINUITY和EXT‑X‑VERSION。
3.2新标签
3.2.1EXT‑X‑TARGETDURATION
EXT‑X‑TARGETDURATION标签指示最大媒体文件的持续时间。播放列表中每个媒体文件的EXTINF持续时间必须小于或等于目标持续时间。该标签必须在播放列表中出现一次，其格式为：
#EXT‑X‑TARGETDURATION：<s>
其中，s是一个整数，代表以秒为单位的目标持续时间。
3.2.2EXT‑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中。
参看章节6.3.2和6.3.5中关于处理EXT‑X‑MEDIA‑SEQUENCE标签的信息。
3.2.3EXT‑X‑KEY
媒体文件可能被加密。EXT‑X‑KEY标签提供解密它之后的媒体文件所需的信息。其格式为：
#EXT‑X‑KEY：METHOD=<method>[，URI=“<URI>“][，IV=<IV>]
该方法属性指示加密方法。定义了两种加密方法：无（NONE）和AES‑128。
无（NONE）的加密方法意味着媒体文件没有被加密。如果加密方法为无（NONE），URI和IV的属性不允许显示。
AES‑128加密方法表示媒体文件被使用带128位密钥和PKCS7填充【RFC5652】的高级加密标准【AES_128】加密。如果加密方法是AES‑128，URI属性必须显示。IV属性可以显示；参看章节5.2。
如果URI属性显示，则它指示如何获取密钥。如果IV属性显示，则它指定和密钥一起使用的初始化矢量。IV属性出现在协议版本2中。
一个新的EXT‑X‑KEY取代之前任何的EXT‑X‑KEY。
如果播放媒体文件不包含EXT‑X‑KEY标签，则媒体文件没有被加密。
参看章节5关于密钥文件的格式。更多关于媒体文件加密的信息参看章节5.2，6.2.3和6.3.6。
3.2.4EXT‑X‑PROGRAM‑DATE‑TIME
EXT‑X‑PROGRAM‑DATE‑TIME标签将下一媒体文件的开头和绝对日期和/或者时间结合起来。日期/时间表示法是ISO/IEC 8601：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.2.5EXT‑X‑ALLOW‑CACHE
EXT‑X‑ALLOW‑CACHE标签指示客户端是否可以或者不允许缓存下载的媒体文件用以稍后重播。它可以出现在播放列表文件的任何位置；不允许出现超过一次。其格式为：
#EXT‑X‑ALLOW‑CACHE：<YES|NO>
更多关于EXT‑X‑ALLOW‑CACHE标签的信息参看章节6.3.3
3.2.6EXT‑X‑ENDLIST
EXT‑X‑ENDLIST标签指示再没有媒体文件将被添加到播放列表文件中。它可以出现在播放列表文件的任何位置；不允许出现超过一次。其格式为：
#EXT‑X‑ENDLIST
3.2.7EXT‑X‑STREAM‑INF
EXT‑X‑STREAM‑INF标签指示播放列表文件中的下一个URI识别另一个播放列表文件。其格式为：
#EXT‑X‑STREAM‑INF：[attribute=value][,attribute=value]*<URI>
在同一EXT‑X‑STREAM‑INF标签中，一个属性不允许出现超过一次。如下属性被定义：
BANDWIDTH=<n>
其中n是每秒的比特数。它必须是出现或将出现在播放列表中的每一媒体文件所有比特率的上限，容器开销也被计算在内。
PROGRAM‑ID=<i>
其中i是一个数字，它唯一识别在播放列表文件范围内的一特别的演示。
一个播放列表文件可以包含具有相同PROGRAM‑ID的多个EXT‑X‑STREAM‑INF标签来识别相同演示的不同编码。这些不同的播放列表可以包含额外的EXT‑X‑STREAM‑INF标签。
CODECS=”[format][,format]＊”
其中每一个格式指定出现在播放列表文件中的媒体文件中的媒体样本类型。
有效的格式标识符是那些在ISO文件格式名空间中被RFC 4281【RFC4281】定义的。
RESOLUTION=<N>x<M>
其中N是流中视频的近似编码水平分辨率，以像素数表示。M是近似编码垂直分辨率。
3.2.8EXT‑X‑DISCONTINUITY
EXT‑X‑DISCONTINUITY标签指示它之前一个媒体文件和它之后一个媒体文件之间编码的不连续性。可能改变的特性集是：
О文件格式
О轨道的数量和类型
О编码参数
О编码序列
О时间戳序列
其格式为：
#EXT‑X‑DISCONTINUITY
更多关于EXT‑X‑DISCONTINUITY标签的信息参看章节4，6.2.1和6.3.3。
3.2.9EXT‑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以允许它的客户端获取文件。
服务器必须创建一个播放列表文件。该播放列表文件必须符合章节3中描述的格式。服务器要提供的每个媒体文件的URI必须按照将要播放的顺序出现在播放列表中。如果它的URI在播放列表文件中，则对于客户端整个媒体文件必须是可用的。
播放列表文件必须包含一个EXT‑X‑TARGETDURATION标签。它必须标识任何添加到该播放列表文件中的媒体文件的最大EXTINF值。对于整个演示，它的值必须保持一致。典型的目标持续时间是10秒。
播放列表文件应该包含一个EXT‑X‑VERSION标签用于标识流的兼容性版本。它的值应该是服务器，播放列表文件和相关媒体文件都遵循的最小协议版本。
服务器必须为每一个媒体文件创建一URI以允许它的客户端获取文件。
如果该播放列表文件是由HTTP发布，服务器应该支持客户端的使用“gzip”内容编码的请求。
播放列表文件的变动必须从客户端角度自动执行。
播放列表中的每一个媒体文件URI必须以标识媒体文件的四舍五入持续时间的EXTINF标签作为前缀。
服务器可以通过将EXT‑X‑PROGRAM‑DATE‑TIME标签作为它URI前缀的方式将绝对日期和时间与一个媒体文件结合起来。日期和时间的值提供了一个媒体的时间线的信息性映射给一个合适的挂钟时间。该映射可以作为搜索、显示或其他目的的基础。如果服务器提供了这样的一个映射，它应该在播放列表文件中的每个EXT‑X‑DISCONTINUITY标签后放置一个EXT‑X‑PROGRAM‑DATE‑TIME标签。
如果播放列表包含演示的最终媒体文件，则播放列表必须包含EXT‑X‑ENDLIST标签。
如果播放列表不包含EXT‑X‑ENDLIST标签，服务器必须生成一个包含至少一个新媒体文件URI的可用的放媒体文件的新版本播。它必须在相对于播放列表的先前版本可用的时间是可用的：不早于该时间之后的0.5倍的目标持续时间，不晚于该时间之后的1.5倍的目标持续时间。
如果服务器希望移除整个演示，它必须使得该播放列表文件对于客户端不可用。它应该确保播放列表文件中所有的媒体文件在移除时保持对客户端可用的时间至少为播放列表文件的持续时间。
6.2.2滑动窗口播放列表
服务器可以将媒体文件的可用性限制到只给那些最近添加到播放列表中的。为此，播放列表文件必须始终恰好包含一个EXT‑X‑MEDIA‑SEQUENCE标签。对于每个从播放列表文件中移除的媒体文件URI，它的值必须增加1。
媒体文件URI必须按照它们被添加的顺序从播放列表文件中移除。
当服务器从播放列表中移除一个媒体文件URI，媒体文件应该保持对于客户端的可用性一段时间，该段时间等于媒体文件的持续时间加上媒体文件出现其中的最长播放列表文件的持续时间。
如果服务器计划在媒体文件通过HTTP分发给客户端后移除它，它应该确保HTTP响应包含反映计划生存时间的一个过期标头。
不包含EXT‑X‑ENDLIST标签的播放列表文件的持续时间必须是至少三倍于目标持续时间。
6.2.3加密媒体文件
如果媒体文件是将要加密的，服务器必须定义一个URI，该URI将允许授权的客户端获取包含解密密钥的一个密钥文件。该密钥文件必须遵循章节5中描述的格式。
服务器可以在密钥响应中设置HTTP过期标头来标识密钥可以被缓存。
如果加密方法是AES‑128，AES‑128CBC加密必将被应用到单个媒体文件。整个文件必须被加密。密码块链不允许跨媒体文件使用。用于加密的IV必须或者是媒体文件的序列号，或者是章节5.2中描述的EXT‑X‑KEY标签的IV属性值。
服务器必须使用播放列表文件中最即刻早于它URI的EXT‑X‑KEY标签指定的方法和其他属性加密每一个媒体文件。之前有EXT‑X‑KEY标签且方法为无（NONE）的媒体文件，或者之前没有任何EXT‑X‑KEY标签的媒体文件不允许加密。
如果播放列表文件包含使用密钥加密的媒体文件的URI，服务器不允许从播放列表文件中移除EXT‑X‑KEY标签。
6.2.4提供不同的流
服务器可以提出多个播放列表文件以提供同一演示的不同编码。如果是这样，它应该提供一变化播放列表列举每个不同的流以允许客户端在不同编码之间动态转换。
不同的播放列表必须为每个不同的流包含一EXT‑X‑STREAM‑INF标签。同一演示的每个EXT‑X‑STREAM‑INF标签必须具有相同的PROGRAM‑ID属性值。在不同的播放列表中，每个演示的PROGRAM‑ID值必须是唯一的。
如果一EXT‑X‑STREAM‑INF标签包含CODECS属性，该属性值必须包含【RFC4281】定义的、存在于出现在或即将出现在播放列表文件中的任何媒体文件中的每个格式。
当产生不同的流时，服务器必须符合下列限制：
每个不同的流必须呈现相同的内容，包括流不连续性。
每个不同的播放列表文件必须具有相同的目标持续时间。
只出现在一个而并非其它不同播放列表文件中的内容必须出现在该播放列表文件的开头或者结尾，并且不允许长于目标持续时间。
不同流中匹配的内容必须具有匹配的时间戳。它可以允许客户端同步流。
基本音频流文件必须通过在ID3 PRIV标签【ID3】前追加拥有者标识“com.apple.streaming.transportStream Timestamp”的方式标识文件中第一个样本的时间戳。二进制数据必须是作为大端8字节数表示的一个33位MPEG‑2程序基本流时间戳。
另外，所有的不同流应该包含相同的编码音频比特流。它允许客户端在流之间没有音频干扰地转换。
6.3客户端操作
6.3.1引言
客户端如何给播放列表文件获取URI超出本文档的论述范围，在此假定它已经完成。
客户端必须从URI获取播放列表文件。如果这样获取的播放列表文件是一个不同的播放列表，客户端必须从该不同的播放列表中获取该播放列表文件。
本文档没有详细说明客户端对不同流的处理方式。
6.3.2加载播放列表文件
每当播放列表文件从播放列表URI中被加载或重新加载：
客户端必须确保播放列表文件以EXTM3U开头，并且如果出现EXT‑X‑VERSION标签，该标签指示客户端支持的协议版本，如果没有出现该EXT‑X‑VERSION标签，客户端不允许尝试使用该播放列表。
客户端应该忽略所有它不能识别的标签和属性。
客户端必须确定如章节6.3.5中描述的下一个要加载的媒体文件。
如果播放列表包含EXT‑X‑MEDIA‑SEQUENCE标签，客户端应该认为在播放列表中的每个媒体文件将会在一个时间变为不可用。该时间为播放列表文件加载的时间加上播放列表文件的持续时间。播放列表文件的持续时间是它之中的媒体文件的持续时间之和。
6.3.3播放播放列表文件
当重放开始时，客户端应该从播放列表中选择首先播放的媒体文件。如果EXT‑X‑ENDLIST没有出现，客户端倾向于定期地播放媒体（比如以标称的重放速率按照播放列表的顺序）。客户端不应该选择从播放列表文件的结尾开始少于三倍目标持续时间的文件。这么做会导致重放停顿。
为了实现正常的重放，媒体文件必须按照它们在播放列表文件中出现的顺序被播放。客户端可以以它希望的任何方式显示可用的媒体，包括定期重放，随机读取和特技模式。
客户端在播放以EXT‑X‑DISCONTINUITY标签开头的媒体文件之前必须准备重新设置它的解析器和解码器。
客户端应该在当他们为补偿潜伏期和处理能力中的临时变动而要求的不间断重放之前尝试加载媒体文件。
如果播放列表文件包含EXT‑X‑ALLOW‑CACHE标签并且它的值为否，客户端不允许在下载的媒体文件被播放后缓存它们。否则，客户端可以为以后的重播无限期的缓存媒体文件。
客户端可以使用EXT‑X‑PROGRAM‑DATE‑TIME标签值向用户呈现程序起始时间。如果该值包含时区信息，客户端应该把它考虑进去。但是如果它不包含，客户端不允许推测起始时区。
客户端不允许依赖EXT‑X‑PROGRAM‑DATE‑TIME标签值的正确性和一致性。
6.3.4重新加载播放列表文件
除非包含EXT‑X‑ENDLIST标签，客户端必须周期性的重新加载播放列表文件。
但是客户端不允许尝试以超过本章节指定的频率重新加载播放列表文件。
当客户端第一次加载播放列表文件或者重新加载播放列表文件时发现媒体文件自从上次被加载后已经有所改变，客户端必须在尝试再一次重新加载该播放列表文件之前等待一段时间。这段时间叫做初始最小重新加载延时。它从客户端开始加载播放列表文件开始计算。
初始最小重新加载延时是播放列表中最后一个媒体文件的持续时间。媒体文件持续时间由EXTINF标签确定。
如果客户端重新加载一播放列表文件并且发现它没有改变，则客户端必须在重试之前等待一段时间。这个最小的延时是目标等待时间的倍数。这个倍数在第一次尝试时为0.5倍，第二次尝试时为1.5倍，此后为3.0倍。
6.3.5确定下一个将要加载的文件
客户端必须在播放列表文件每次被加载或重新加载时检查以确定下一个加载的媒体文件。
如同章节6.3.3中描述的，第一个加载的文件必须是客户端选择第一个播放的文件。
如果第一个播放的文件已经被加载，并且播放列表文件不包含EXT‑X‑MEDIA‑SEQUENCE标签，客户端必须证实当前播放列表文件在最后加载的媒体文件最初被发现的位移处包含该媒体文件的URI，加载如果不包含则停止重放。下一个将要加载的媒体文件必须是播放列表中跟随最后一个加载的URI的第一个媒体文件URI。
如果第一个播放的文件已经加载，并且播放列表文件包含EXT‑X‑MEDIA‑SEQUENCE标签，则下一个将要加载的媒体文件应该是那个具有大于最后一个加载的媒体文件序列号的最小序列号的媒体文件。
6.3.6解密加密的媒体文件
如果播放列表文件包含标识密钥文件URI的EXT‑X‑KEY标签，客户端必须获取那个密钥文件并且用密钥文件中的密钥解密EXT‑X‑KEY标签之后所有的媒体文件直到遇到另一个EXT‑X‑KEY标签。
如果加密方法是AES‑128，AES‑128CBC加密应该被应用到单个媒体文件。整个文件必须被解密。密码块链不允许跨媒体文件使用。如章节5.2中描述的，解密使用的IV必须或者是媒体文件的序列号，或者是EXT‑X‑KEY标签的IV属性值。
如果加密方法是无（NONE），客户端必须将所有跟随EXT‑X‑KEY标签的媒体文件当作明文（不加密的）直到遇到另一个EXT‑X‑KEY标签。
7.协议版本兼容性
客户端和服务器必须执行协议版本2或者更高版本以使用：
ОEXT‑X‑KEY标签的IV属性
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‑TARGE TDURATION: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/low.m3u8
#EXT‑X‑STREAM‑INF:PROGRAM‑ID=1,BANDWIDTH=7680000
http://example.com/low.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】关于安全性考虑的章节。
客户端应该随意加载由URI标识的资源以防止引起拒绝服务式攻击。
HTTP请求经常包含会话状态（“信息（cookies）”），它可能包含私有用户数据。实施必须遵循RFC 2965【RFC2965】指定的信息（cookie）限定和期满规则。同样参看RFC 2965和RFC 2964【RFC2964】关于安全性考虑的章节。
加密密钥由URI指定。这些密钥的传递应该由诸如TLS【RFC5246】（原来的SSL）上的HTTP的机制结合一安全领域或者会话信息（cookie）来保障。
10.参考文献
规范性文献
【AES_128】美国商务部/国家标准和技术部，“高级加密标准（AES），FIPS PUB 197”，2001年11月，<http://csrc.nist.gov/publications/fips/fips197/fips‑197.pdf<http://csrc.nist.gov/publications/fips/fips197/fips‑197.pdf>>。
【ISO_13818】国际标准化组织，“ISO/IEC国际标准13818；移动图像和相关音频信息的通用编码”，2007年10月，<http://www.iso.org/iso/catalogue_detail?csnumber=44169>。
【ISO_8601】国际标准化组织，“ISO/IEC国际标准8601：2004；数据元素和互换格式—信息互换—日期和时间表示法”，2004年10月，<http://www.iso.org/iso/catalogue_detail?csnumber=40874>。
【RFC2046】Freed,N.和N.Borenstein，“多目的互联网邮件扩展（MIME）第二部分：媒体类型”，RFC 2046，1996年11月。
【RFC2119】Bradner,S.，“关键词在RFC中指示需求级别的使用”，BCP 14，RFC 2119，1997年3月。
【RFC2616】Fielding,R.,Gettys,J.,Mogul,J.,Frystyk,H.,Masinter,L.,Leach,P.,和T.Berners‑Lee,“超文本传输协议—HTTP/1.1”，RFC 2616，1999年6月。
【RFC2964】Moore,K.和N.Freed,“HTTP状态管理的使用”，BCP 44，RFC 2964，2000年10月。
【RFC2965】Kristol,D.和L.Montulli,“HTTP状态管理机制”，RFC 2965，2000年10月。
【RFC3629】Yergeau,F.，“UTF‑8，ISO 10646的一种变形格式”，STD 63，RFC 3629，2003年11月。
【RFC3986】Berners‑Lee,T.,Fielding,R.,和L.Masinter,“通用资源标志符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
【RFC4281】Gellens,R.,Singer,D.,和P.Frojdh,“用于‘桶’媒体类型的编解码器参数”，RFC 4281，2005年11月。
【RFC5246】Dierks,T.和E.Rescorla,“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
【RFC5652】Housley,R.,“加密消息语法（CMS）”，RFC 5652，2009年9月。
【US_ASCII】美国国家标准化协会“ANSI X3.4‑1986，信息系统—编码字符集用于信息互换的7位美国国家标准代码（7位ASCII），1986年12月。
12.2参考性文献
【ID3】ID3.org<http://ID3.org>，“ID3音频文件数据标签格式”，<http://www.id3.org/Developer_Information>。
【M3U】Nullsoft公司，“M3U播放列表格式，该发明最初用于Winamp媒体播放器”，<http://wikipedia.org/wiki/M3U>。