CN103392344B

CN103392344B - 使用用于流化的http网络的格式未知的流化体系结构

Info

Publication number: CN103392344B
Application number: CN201180067319.0A
Authority: CN
Inventors: C·R·基诺克斯; N·S·布鲁基斯; V·杰纳尔德安; A·拉尔瓦尼; R·索; B·瑟亚纳雷亚纳安; S·L·鲁迪恩; A·O·奥鲁格比莱; W·P·科尔比三世; P·拉加泰; M·P·帕沃; C·H·雷奥; A·S·F·帕丁加雷维蒂尔
Original assignee: Akamai Technologies Inc
Current assignee: Akamai Technologies Inc
Priority date: 2010-12-17
Filing date: 2011-12-19
Publication date: 2017-02-15
Anticipated expiration: 2031-12-19
Also published as: EP2652949A2; US20120265853A1; CN103392344A; EP2652949A4; WO2012083298A2; WO2012083298A3

Abstract

本专利文件描述了用于在广播受众规模向各种运行时环境以及固定线路和移动环境中的客户端设备在线分发多媒体（包括HD视频）的分布式计算机平台等。可以应用其教导以通过计算机网络分发实况和按需内容流。本教导还涉及摄取给定源格式的内容流，以及供应给定目标格式的流。例如，***可以在内容分发网络中具有摄取源格式的实况流，使用中间格式在***内传输流，并向请求了（例如，利用HTTP请求）流的客户端输出目标格式的流的机器。流可以被存档以供以后回放。

Description

使用用于流化的HTTP网络的格式未知的流化体系结构

对相关申请的交叉引用

本申请是2011年12月16日提出的美国申请No.13/329,057的连续申请，并要求它的优先权，并要求2010年12月17日提出的专利申请号为No.61/424,092的美国临时申请、2011年11月3日提出的专利申请号为No.61/555,378的美国临时申请、2010年12月17日提出的专利申请号为No.61/424,482的美国临时申请、2010年12月17日提出的专利申请号为No.61/424,112的美国临时申请的优先权。如前所述的所有申请的全部内容在此通过引用而合并于此。

技术领域

本申请一般涉及在广播受众规模向各种运行时环境和客户端设备在线分发诸如高清晰度视频之类的流化的内容。

背景技术

分布式计算机***在现有技术中是已知的。一个这样的分布式计算机***是由服务提供商运营和进行管理的“内容分发网络”或“CDN”。服务提供商通常代表第三方提供内容传送服务。这种“分布式***”通常是指通过网络链接起来的自治计算机与被设计为执行各种服务（如内容分发或外包的站点基础架构的支持）的软件、***、协议和技术一起的集合。通常，“内容分发”是指代表内容提供商存储、高速缓存或传输内容，或流化媒体或应用，以及与此一起使用的附属技术，包括但不仅限于，DNS查询处理、供应、数据监控和报告、内容定向、个性化，以及商务智能。

尽管内容分发网络提供大量的优点，但是，它们常常包括为多个第三方运行时环境支持内容的分发的专用平台，专用平台又基于他们自己的专有的技术、媒体服务器以及协议和格式。这些不同的平台实现和维护起来昂贵，特别是全球地并且规模随着最终用户的数量增大时。此外，同时，内容提供商（诸如大规模的广播公司、电影经销商等等）希望它们的内容以与诸如广播TV（包括高清晰度或“HD”电视）和DVD之类的传统的媒体互补的方式在线提供。此内容也可以以不同的比特率提供。最终用户还希望如他们现在与通过卫星或有线电视提供的传统的基于DVR的内容所做的那样与内容进行交互。进一步的复杂因素是，基于因特网的内容分发不再仅限于诸如台式机之类的固定线路环境，因为越来越多的最终用户现在使用诸如智能电话或平板计算机之类的移动设备来接收和查看。

因而，需要给集成的内容分发网络平台提供在广播受众规模向最流行的运行时环境（诸如等等）以及向诸如之类的移动设备提供在线内容（诸如HD质量的视频），以匹配观众期望从传统的广播TV得到的东西的能力。此处所公开的技术解决此需要及其它需要，考虑下面的公开这些需要将变得清晰。

发明内容

根据此处的原理，集成的分发平台可以向在固定线路和移动环境中的许多类型的客户端设备上操作的流行的运行时环境在线分发HD视频和音频质量的内容。

通过例示，在本发明的一个非限制性方面，平台从编码器摄取实况内容流，并将它转换为诸如分段MP4之类的中间格式（IF），供在***内传输流时使用。客户端向作为平台（通常是基于HTTP的平台）的一部分的内容服务器作出请求。内容服务器优选地是运行HTTP代理进程并提供高速缓存的服务器。内容服务器可以检索目标格式的实况流，并将它供应到客户端。可替换地，内容服务器可以从其自己的高速缓存，或从别处检索IF段，并使用由平台所提供的指令来将它转换为输出格式，或在将流提供到客户端之前对流执行其它功能。这样的功能的一个示例通过此处所描述的二进制端包含（BSI）来示出。实况流IF段也可以存档在平台内，供以后作为视频点播或DVR功能的一部分来播放。

前述的功能可以在由内容分发网络服务提供商运营的内容分发网络中实现。实况内容流与内容提供商相关联，CDN代表内容提供商通过它的多个内容分发机器来向进行请求的客户端提供流。许多不同的内容提供商可以使用CDN来向进行请求的客户端分发它们的完全不同的内容。每一个内容提供商都优选地能够配置他们自己的流化参数来向各种运行时环境和固定线路或移动环境分发内容。

通过进一步的例示，在本发明的另一个非限制性方面，***包括多个互连的机器，它们可以是内容分发网络（CDN）的一部分。每一个机器都表示带有至少一个处理器和计算机存储器的计算机，计算机存储器用于保存要由所述至少一个处理器执行以便于实况流以目标格式向客户端分发的计算机程序指令或代码，实况流以源格式产生。源格式和目标格式通常是多媒体容器格式，并且可以相同也可以不同。

第一机器以源格式从编码器接收实况流，并将它转换为中间格式，并以中间格式供应实况流。如上文所指示的，中间格式（IF）是用于在CDN内传输流的格式，并优选地是尽管不一定是分段的格式。在一种方法中，第一机器提供入口点流管理器，该入口点流管理器接收多路分解的实况流，设置并管理实况流发布点，并响应于来自第二机器的请求以中间格式供应当前实况流段。

第二机器以所述中间格式从所述第一机器接收所述实况流并生成：（i）目标格式的所述实况流，或（ii）在将所述实况流从所述中间格式转换为目标格式时所使用的指令。更具体而言，在一种实现方式中，第二机器具有第一进程和第二进程，所述第一进程接收来自所述第三机器的进入的HTTP请求，并将那些请求转发到所述第二进程，所述第二进程将所述请求转发到生成下列各项中的至少一项的转换库功能：（i）目标格式的所述实况流，以及（ii）在将所述实况流从所述中间格式转换为目标格式时所使用的指令。更具体而言，对于分段的中间格式，指令指定如何将一组IF段转换（例如，多路复用）为目标格式。

第三机器（优选地，运行实施（field）客户端请求的HTTP代理的内容服务器）从第二机器接收下列各项中的至少一项：（i）目标格式的实况流，以及（ii）指令。如果接收到指令，那么第三机器使用指令来生成目标格式的实况流。最终，第三机器向客户端供应目标格式的实况流。第三机器可以高速缓存中间格式的流（即，IF段）或指令，供以后在供应其它客户端时使用。

在很多情况下，还存在第四机器，存储实况流的档案供进行DVR或VOD播放、以及流元数据的网络存储子***。当中间格式的当前实况流段被从所述第一机器向所述第二机器供应时，第一机器将所述实况流存档到所述第四机器。

在与按需流化相关的本发明的再一个非限制性方面，***包括多个互连的机器，第一机器接收并解析源格式的并且与按需流相关联的文件的至少一部分。所述第一机器从与内容提供商相关联的源服务器或与内容分发网络服务提供商相关联的远程存储***接收所述文件的所述至少一部分。第一机器生成下列各项中的至少一项：（i）表示目标格式的所述文件的至少一部分的输出对象，以及（ii）在创建表示目标格式的所述文件的至少一部分的输出对象时所使用的指令。第二机器接收输出对象，或用于创建输出对象的指令。优选地，第二机器是HTTP代理服务器，该HTTP代理服务器实施客户端对按需流的请求，并向第一机器发出对这样的指令或其它信息的请求，以便服务客户端请求。第二机器以目标格式向请求了按需流的客户端供应输出对象（或从指令生成输出对象，并供应它）。第二机器可以高速缓存输出对象或指令，供以后再使用。

在很多情况下，中间格式在第一和第二机器之间使用。在此情况下，第一机器将文件的至少一部分转换为中间格式，通常是分段的格式，然后，生成指定如何从一个或多个中间格式段创建目标格式的输出对象的指令。第一机器可以创建对文件的至少一部分的中间索引。中间索引包括，例如，下列各项中的至少一项：合成时间、解码时间、中间段（IF）边界、以及到中间格式段的文件中的字节范围偏移。中间索引可以提供到源格式的所述文件中的普通接口，并且它可以被高速缓存，供第一机器再使用。

指令通常是多路复用指令，并可以包括格式容器特定的标头和对于IF段的请求URL。如上文所指示的，他们通常还包括用于将IF段多路复用为目标格式的指令。第二机器可以高速缓存指令和/或中间格式段。

上文引用的“指令”可以使用此处称为二进制端包含或BSI的功能来实现，以在给定输入对象（例如，IF段）和通常定义要对输入对象数据采取的操作或动作的指令的情况下，生成输出对象（例如，目标格式的流的一部分），该功能可在诸如第三机器之类的HTTP代理中执行。因此，运行HTTP代理的内容服务器可以具有从一个或多个源获取数据的基于字节的解释器，并使用一个或多个动作，指示服务器如何将输入对象改变为输出对象。这可以包括定义以什么顺序，从什么源，来填充输出缓冲器以便为客户端生成输出对象。这样的指令可以被高速缓存，供在生成其它输出对象并对多个客户端请求作出响应时再使用。

可以利用BSI执行的动作的示例是组合、***、替换以及删除。也可以包括条件逻辑。因此，例如，基于字节的解释器可以解析并排序要采取的动作，构建要被填充的输出缓冲器，安置来自一个或多个源的字节以填充该高速缓冲器。

如本领域技术人员将认识到的，前述的描述只提供本发明的示例。它不是限制性的，此处的原理可以以各种***、方法、设备以及非瞬时的计算机可读取介质来实现。还应注意，功能向不同的机器的分配不是限制性的，因为可以以各种方式组合或分配上面所列举的功能。

附图说明

通过下面的结合附图对本发明进行的详细说明，可以比较全面地理解本发明，其中：

图1是示出了配置为内容分发网络的已知分布式计算机***的一个实施例的示意图；

图2是示出了在其上面可以实现图1的***中的内容分发服务器的机器的一个实施例的示意图；

图3是示出了如2010年8月17日提出的美国申请No.12/858,177所描述的用于实况流式分发的体系结构的一个实施例的示意图；

图4是示出了如2010年8月17日提出的美国申请No.12/858,177所描述的视频点播方法的体系结构和请求流的一个实施例的示意图；

图5是用于实况流化的体系结构的一个实施例的示意视图；

图6是用于按需流化的体系结构的一个实施例的示意视图；

图7是更详细地示出了图5的实况流化体系结构的示意视图；

图8示出了当从编码器向入口点（EP）发布流时所使用的说明性第一实况流化工作流；

图9示出了当最终用户作出对内容的实况请求时所使用的说明性第二实况流化工作流；

图10示出了可以在图5、7、8和9所示出的示例性体系结构中宣告实况流所采用的进程的示例；

图11示出了用于复制实况流的技术的示例；

图12示出了当最终用户发出对内容的请求时所使用的按需流化工作流的一个实施例；

图13更详细地示出了转换库组件的示例；

图14示出了支持以给定格式摄取和输出内容流的工作流的一个实施例；

图15示出了用于支持以另一种给定格式摄取和输出内容流的工作流的一个实施例；以及

图16示出了使用二进制端包含来便于流化的工作流的一个实施例；

图17是示出了可以被用来实现此处的教导的计算机***中的硬件的框图。

具体实施方式

下面的描述阐述了本发明的各实施例以提供对此处所公开的方法和设备的结构、功能、制造、以及使用的原理的全面了解。此处所描述的并且在各个附图中所示出的***、方法和设备是非限制性示例；本发明的范围只由权利要求书定义。与一个示例性实施例一起所描述的或所示出的特征可以与其它实施例的特征相结合。这样的修改及变化都包括在本发明的范围内。此处引用的所有专利、出版物和参考文献的全部内容以引用的方式而明确地并入本文中。

图1示出了已知的分布式计算机***（如下面所描述的），该分布式计算机***通过此处所公开的技术扩展，以给基于HTTP的平台提供在广播受众规模向最流行的运行时环境以及固定线路和移动环境中的最新的设备分发在线HD视频的能力。

在此示例性实施例中，分布式计算机***100被配置为内容分发网络（CDN），并且假设具有分布在因特网中的一组机器102a-n。通常，大多数机器是位于因特网的边缘附近的服务器，即，位于最终用户接入网络或与它们相邻。网络操作命令中心（NOCC）104可以用来经管和管理***中的各种机器的操作。附属于内容提供商的第三方站点，如网站106，将内容（例如，HTML、嵌入的页对象、流式媒体、软件下载等等）的分发的负载分摊到分布式计算机***100，具体来说，分摊到CDN的服务器（有时被称为内容服务器，或者考虑到它们位于因特网的“边缘”的附近的可能性，有时被称为“边缘”服务器）。这样的内容服务器可以被一起组合到现场点（POP）107。

通常，内容提供商通过将给定内容提供商域或子域化名（例如，通过DNS CNAME）为由服务提供商的权威性的域名服务进行管理的域，来分摊他们的内容分发的负载。需要这样的内容的最终用户可以被定向到分布式计算机***，以更加可靠而有效地获得该内容。虽然未详细地示出，但是，分布式计算机***也可以包括其它基础架构，如，分布式数据收集***108，用于从内容服务器收集使用情况及其它数据，跨区域或区域集合地聚合该数据，并将该数据传递到其它后端***110，112，114和116，以便于监控、记录、警告、计费、管理及其它操作和管理功能。分布式网络代理118监控网络以及服务器负载，并向DNS查询处理机制115提供网络、流量和负载数据，该机制115对于由CDN进行管理的内容域是权威性的。分布式数据传输机制120可以用来向内容服务器分发控制信息（例如，管理内容的元数据，以便于负载平衡等等）。

如图2所示，CDN中的给定机器200（有时被称为“边缘机器”）包括运行支持一个或多个应用206a-n的操作***内核（如Linux或变体）204的商品硬件（例如，Intel Pentium处理器）202。为便于内容分发服务，例如，给定机器通常运行一组应用，如HTTP代理207、名称服务器208、本地监视进程210、分布式数据收集进程212，等等。HTTP代理207（此处有时称为全局主机或“克隆（ghost）”）通常包括用于管理高速缓存和内容从机器的分发的管理器进程。对于流式媒体，机器根据支持的媒体格式的需要通常包括一个或多个媒体服务器，如Windows Media Server（WMS）或Flash2.0服务器。在某些情况下，本专利文件中的功能被描述为由已经从常规形式适当地修改的HTTP代理207或内容服务器的克隆进程来执行，或嵌入到其中。这是典型的实施方式，因而充当方便的说明。然而，这只是一个实施例，不是限制性的。任何这样的功能都可以在克隆外部实现，例如，作为在内容服务器中运行的单独的进程。

图2所示出的机器可以被配置成提供一个或多个扩展的内容分发功能，优选地基于特定于域地、特定于客户的，优选地使用通过使用配置***分发给内容服务器的配置文件。给定配置文件优选地是基于XML的，并且包括便于一个或多个高级内容处理功能的一组内容处理规则和指令。配置文件可以通过分布式数据传输机制分发给CDN内容服务器。美国专利No.7,111,057（通过引用合并于此）示出了用于分发和管理CDN服务器内容控制信息的有用的基础架构，此边缘服务器控制信息及其它边缘服务器控制信息（有时被称为“元数据”）可以由CDN服务提供商本身提供，或（通过外部网等等）操作源服务器的内容提供商客户提供。

CDN可以包括可以位于可以被内容服务器访问的网络数据中心的网络存储子***（此处有时称为“网络存储器（NetStorage）”），诸如在美国专利No.7,472,178中所描述的，该申请以引用的方式并入本文中。

CDN可以操作服务器高速缓存层次结构，以提供客户内容的中间高速缓存；在美国专利No.7,376,716中描述了一个这样的高速缓存层次结构子***，该申请以引用的方式并入本文中。

对于实况流式分发，CDN可以包括实况分发子***，诸如在美国专利No.7,296,082中所描述的，该申请以引用的方式并入本文中。

2010年8月17日提出的美国申请系列No.12/858,177（现在作为美国出版物No.2011/0173345发布，其内容以引用的方式并入本文中）描述了可以如何扩展上述技术，以提供集成的基于HTTP的分发平台，该平台可以向最流行运行时环境以及向固定线路和移动环境中的最新的设备在线分发HD视频质量内容。平台支持分发“实况”和“按需”内容。

如美国申请系列No.12/858,177所描述的，下面术语应该具有下面的代表性含义。仅仅为了方便起见，随后的描述（相对于实况流式分发）是在Adobe Flash运行时环境的上下文中呈现的，但是，这不是限制，因为类似类型的解决方案也可以对于其它运行时环境（固定线路和移动的）实现（包括，但不仅限于，Microsoft Silverlight、Apple iPhone等等）。

编码器是以某种格式（流式、卫星等等）获取某种原始或轻微地压缩的视频种子并向入口点分发被编码用于流式分发的通常由客户拥有的或管理的机器。原始视频种子通常是实况流。入口点（EP）通常是在CDN流化机器上运行的从编码器接收视频数据并使此数据对流的客户可用的进程。对于Adobe Flash，此可以是被配置成接受来自编码器的连接的Flash媒体服务器（Flash Media Server）（FMS）。Flash媒体服务器是Adobe Corporation出品的用于Flash媒体的服务器进程。在本实施例中，中间区域（IR）通常是CDN已经配置的与流式机反射器（streaming set reflector）类似地操作的Flash媒体服务器，诸如在美国专利No.7,296,082和美国专利No.6,751,673中所描述的。这些机器将流从FMS EP中继到FMS边缘区域，提供散开和路径分集。“区域”通常暗示位于一起并通常通过后端局域网彼此互连以便进行负载分担的一组机器（以及它们的相关联的服务器进程）。Flash机器是已经被配置成接受客户端请求的Flash媒体服务器。在代表性的实施例中，这是在Flash EP、IR以及内容服务器上运行的软件。中间格式（IF）是用于将流式数据从EP发送到内容服务器HTTP代理的内部（对CDN而言）格式。正如下面比较详细地描述的，IF优选地包括几个不同的构件，包括“流清单（流清单）”、“段索引”、以及“IF段”。实况、数字视频记录（DVR）和视频点播（VOD）一般用来表示下列各项：“实况”是指当发生事件时实时地供应的媒体；“DVR”是指供应从“实况”种子获取的但是在稍后的时间供应的内容；“VOD”是指从单一、完整的文件或文件集供应的媒体。实时消息传送协议（RTMP）是Flash所使用的流化和RPC协议。加密的实时消息传送协议（RTMPE）是使用嵌入到服务器和客户端中的秘密的RTMP的加密的版本。“SWF”或“小网络格式”是用于Flash客户端应用的格式。SWF验证是指Flash Player可以通过与嵌入在客户端和服务器中的秘密一起发送SWF本身的散列，来向FMS认证它正在播放未修改的SWF所采用的技术。

图3是示出了如2010年8月17日提出的美国申请No.12/858,177所描述的用于实况流式分发的示例性体系结构的概述。如图3所示，在此实施例中，***一般被分成两个独立层：流记录层300以及流播放器层302。记录过程（由流记录层300所提供）从编码器304向前启动。优选地，即使当前没有观众，也记录流（因为以后可能有DVR请求）。回放进程（由流播放器层302所提供）从给定时间开始播放给定流。因而，“实况流”实际上相当于带有开始时间“现在”的“DVR流”。

参考图3，实况流化进程以从编码器304向入口点306传送流开始。指示EP区域（未示出）中的RTMP拉取器（Puller）组件308（例如，运行在基于Linux的机器上）预订EP306上的流，并将所产生的数据推送向优选地在其它机器上运行的一个或多个存档器（Archiver）310进程。在此实施例中，存档器310中的一个可以作为跨存档进程执行领头推送选协议的结果，作为“领头”来操作。优选地，存档器310对于实况或几乎实况的请求，充当内容服务器的HTTP代理进程（在312示出了其中的一个）的源服务器。HTTP代理312向发出请求的最终用户客户端（其中的一个是客户端314）提供HTTP分发。此实施例所示出的客户端314是包括适当的硬件和软件以连接到因特网、遵循至少HTTP、并且包括内容呈现引擎的设备。客户端设备类型将根据设备是通过固定线路环境还是移动环境连接到因特网而变化。代表性的客户端314是包括通常带有对于媒体播放器、编解码器等等的原生或插件支持的浏览器的计算机。如果启用DVR，则内容优选地还上传到存储子***316，以便存储子***充当对于DVR请求的源，如下文所描述的。

也如图3所示，内容提供商可以选择分发流的两个副本，主要副本，以及备份副本，以允许流在网络或其它问题的情况下以最小的中断继续。优选地，主要流和备份流通过HTTP代理在整个***中被视为独立的，HTTP代理优选地具有当主要流具有故障时从主要流转移到备份流的能力，反之亦然。

在操作中，内容请求（例如，来自最终用户客户端314）被定向到HTTP代理312，优选地使用诸如在美国专利No.6,108,703、7,240,100、7,293,093等等中所描述的技术。当HTTP代理312接收到对给定流的HTTP请求时，它可能通过高速缓存层次结构318（参见，例如，美国专利No.7,376,716等等）作出优选地由HTTP代理元数据驱动的各种请求（如美国专利No.7,240,100、7,111,057等等所描述），以定位、了解、并下载流以供应到客户端314。优选地，流化特定的知识由直接连接到客户端314的内容服务器HTTP代理312来处理。任何前进（go-forward）（高速缓存丢失）请求（从HTTP代理发出）优选地是标准HTTP请求。在一个实施例中，内容作为渐进下载Flash视频（FLV）文件从HTTP代理312传送给客户端314。如上文所指示的，此处对Adobe FLV的引用此处作为示例使用，图3所示出的体系结构不限于与AdobeFLV一起使用。对于安全流，优选地，客户端314首先使用内容服务器认证技术和/或SWF验证后向信道来向HTTP代理312认证。

当客户端314请求特定流时，HTTP代理312（客户端通常通过DNS被定向到它）通过检索“流清单（Stream manifest）”来开始流化进程，流清单优选地只包含流的缓慢改变的属性和HTTP代理跟踪实际流内容所需的信息。下载此清单的URL优选地确定地从分发（例如，通过图1的分布式数据传输机制）到HTTP代理的元数据构建。优选地，清单本身与流清单管理器（SMM）***（未示出）相关联地存储和/或存储在存储子***316中。优选地，流清单描述构成流的各种“轨道”，其中，优选地，每一个轨道都构成比特率和类型的不同的组合，其中，类型是“音频”、“视频”、或“interleaved_AV”。流清单优选地包括每一个轨道的“索引信息（indexInfo）”时间范围的序列，它们描述了前向URL模板、流属性、以及HTTP代理请求该时间范围的内容所需的各种其它参数。

对于“实况”请求，HTTP代理开始请求相对于“现在”的内容，“现在”一般而言大致等于内容服务器的HTTP代理进程上的时间。给定寻找时间，HTTP代理下载“段索引”，其名称优选地基于indexInfo范围中的信息和纪元（epoch）寻找时间来计算。优选地，段索引覆盖给定时段（例如，每隔几分钟）。通过查询段索引，获得“中间格式（IF）段”编号和到该IF段中的偏移。然后，HTTP代理可以开始下载段（例如，通过高速缓存层次结构318，或从CDN基础结构内的别处），跳过指定的偏移之前的数据，然后，开始从那里（向发出请求的客户端314）供应。优选地，IF段的大小被确定为由HTTP代理最佳地高速缓存。一般而言，除非流清单利用新indexInfo范围以别的方式指示，否则对于实况流化，HTTP代理持续从连续编号的IF段供应数据。

在基于实况HTTP的分发的上下文中，中间格式（IF）描述了用于从RTMP拉取器直到HTTP代理获取数据的流的内部表示。“源”格式（SF）是入口点306提供内容的格式，“目标”格式（TF）是HTTP代理312向客户端314分发数据的格式。这些格式不必相同。因而，SF可以不同于TF，即，流可以以FLV格式获取，并以动态或自适应（可变比特率）格式来供应。格式是用于输送流的容器；通常，实际原始音频和视频块被视为不透明数据，虽然也可以实现不同的编解码器之间的代码转换。通过经由HTTP代理传递格式（并通过常规HTTP分发给客户端314），用于分发内容的容器可以被改变，只要可以适当地管理基础编解码器。

上文所描述的体系结构对于实况流化是有用的，特别是通过诸如Flash之类的格式。平台还可以被用来支持视频点播（VOD）。具体而言，解决方案可以从客户和基于存储子***的源提供VOD流化，提供单一和多比特率（SBR和MBR）流化，为存储在flv和mp4/flv容器中的源内容提供支持（支持的mp4/flv代码包括AAC、MP3、用于音频的PCM、以及用于视频的H.264，等等），并最小化最终用户直接请求的东西以外的内容的下载。

对于VOD分发，流记录器层300（图3的）被替换为优选地转换层。对于使用HTTP的VOD分发，可以动态地从源内容生成段索引（例如，通过扫描FLV或解析MP4MOOV原子），并高速缓存这些索引。然后，实际数据检索可以直接从HTTP代理的区域处的源材料或通过到中间格式的中间转换（例如，通过高速缓存层次结构父）被实现为“部分对象高速缓存”（POC）检索。部分对象高速缓存是指HTTP代理根据需要只获取段中的内容对象，而并非下载整个内容对象的能力。HTTP代理可以高速缓存这些段，以备将来使用，而并非在从代理供应之后必须释放它们。以这种方式从其检索内容对象段的源服务器必须支持HTTP范围请求的使用。

如2010年8月17日提出的序列号No.12/858,177所描述的，通常VOD内容被分摊负载，以用于向CDN的HTTP分发。在第一实施例中，使用转换工具（脚本）来将源内容FLV转换为IF，然后，将所产生的IF文件上传到存储子***。在此方法中，使用元数据来让HTTP代理前进到存储子***，以检索流清单，然后，该清单引用存储子***的其余内容。在此方法中，首先，将mp4/FLV的文件转换为FLV（例如，使用ffmpeg复制模式），以将容器改变为FLV。另一种方法是让CDN客户将原始媒体文件上传到存储子***，并在那里运行转换工具。再一个替代方案是让客户（或编码器）直接产生IF的内容。

在2010年8月17日提出的序列号No.12/858,177中描述了示例性转换层方法。在此方法中，按需动态IF生成器机器获取对IF（清单、索引、以及段）的请求，并通过动态地（例如，从存储子***或客户源）检索FLV或mp4/f4v输入文件范围来满足这些请求。从那里，HTTP代理处理基本上与上文参考转换工具所描述的相同。生成器机器优选地运行其自己的HTTP代理（“转换器HTTP代理”）以高速缓存各种输入和输出，与接受请求（例如，从到转换器HTTP代理的本地主机（localhost）连接）的转换器进程（下面所描述的）一起，并通过相关联的高速缓存进程、基于从HTTP代理中检索到的数据，生成IF。在一种替代方案中，转换器进程可以包括转换器HTTP代理的一部分，在这样的情况下，IF生成在代理内进行。段生成也可以在HTTP代理或者甚至进一步的下游（到客户端314本身中）执行，诸如在客户端314维持与一个或多个对等客户端的会话连接的情况下。

图4中示出了VOD方法的体系结构和请求流。在此实施例中，转换层400位于源402（例如，客户源或存储子***或其它内容源）和流播放器层404之间。在代表性的实施例中，转换层400在CDN的其自己的部分（例如，在Microsoft IIS或等效网络）中，优选地在专用于此用途的区域中执行。可替换地，转换器可以在基于HTTP的机器区域的子集上运行。

尽管上文所描述的实施例提供了利用HTTP网络来进行对象分发的格式未知的流化体系结构，但是，下面描述了多个体系结构增强。

实况流化组件

图5是示出了用于流化实况内容的体系结构的一个实施例的高级别的组件图。在此实施例中，入口点（EP）502从编码器500摄取要分发的流，将流从其原生格式多路分解为IF格式，诸如分段的格式，如f-MP4，并将流存档到存储器504（通常，网络存储子***）中。EP502将“当前”实况流段供应到通常在单独的SMT机器上运行的流化中间层（SMT）进程506。SMT506从EP502检索“当前”实况流段，并且它生成希望的原生格式的多路复用的输出。在替换实施例中，SMT506生成多路复用指令，供内容服务器与CDN中的HTTP代理进程（或“克隆（ghost）”）508一起使用。如果需要，指令与IF段一起返回到内容服务器进程508，虽然IF段可能预先被内容服务器508高速缓存，或由内容服务器从存储器504检索。多路复用指令可以作为下面将更详细地描述的二进制端包含或BSI来实现。内容服务器克隆进程508将最终用户请求转发到SMT506，高速缓存来自SMT506的响应，该响应是流的原生输出对象或者BSI段，当使用BSI时，内容服务器克隆508还从BSI和IF段创建输出对象。内容服务器克隆508还将原生输出对象分发到最终用户客户端，通常是客户端播放器应用。它不需要理解任何容器格式。存储器504存储用于进行DVR或VOD播放的档案，并且它还存储实况流会话元数据。

按需流化组件

图6是示出了用于流化按需内容的体系结构的一个实施例的高级别的组件图。在此实施例中，SMT604从客户源600或者存储器604（再次，通常是网络存储子***）请求和接收原生按需文件。SMT606解析原生源文件索引，并创建中间元索引（MetaIndex）。它还生成多路复用的输出对象，或者SMT606生成多路复用指令（BSI或等效功能），供内容服务器克隆进程608用来创建原生对象。内容服务器克隆进程608将最终用户请求转发到SMT606，高速缓存来自SMT的响应，该响应是原生输出对象或者BSI段，当使用BSI时，内容服务器克隆进程608还从BSI和IF段创建输出对象。存储器604通常以原生格式存储按需文件。

实况流化操作

图7示出了EP和SMT组件以及它们的相应的功能的进一步的细节。

在此实施例中，EP700包括两个服务：摄取服务器706和入口点流管理器（ESM）701。摄取服务器706由特定于格式的摄取服务器706和叫做转换库（TransformLib）的功能库708组成。库708是链接到摄取服务器706中的共享库。库包含用于多路复用和多路分解的特定于格式的逻辑。在操作中，摄取服务器706从编码器702接收流，认证编码器702，将接收到的数据传递到库708以用于多路分解，并将多路分解的流发送到ESM701。如上文所指示的，库从原生格式（例如，MP3、MPEG2-TS或以别的）多路分解为诸如f-MP4之类的IF。ESM710是优选地驻留在EP700上的独立于格式的组件。ESM701的角色优选地跨不同的流化格式而是相同的。它从摄取服务器706接收多路分解的流，管理ESM发布点，将流存档到存储器705，从SMT供应“当前”实况请求，并向所有SMT通告有效流。EP机器可以是基于Windows的服务器，或基于Linux的服务器，或别的。优选地，ESM代码是跨平台兼容的。

SMT机器包括两个主要服务；SMT712和本地克隆进程714。本地克隆进程714处理来自内容服务器克隆进程715的进入的HTTP请求。作为响应，本地克隆进程714向本地SMT组件712作出转发请求。SMT组件712将进入的请求传递到转换库716以进行处理，该处理基于容器格式。优选地，转换库716首先将特定于容器的进入的URL重写为IF（例如，f-MP4）前向URL。然后，SMT712代表转换库716检索IF段。最后，转换库716使用IF段来创建指令（BSI），并将任何IF请求供应回内容服务器克隆715。如果指令集（BSI）方法被禁用，则转换库716创建原生格式的输出对象。如所指示的，本地克隆进程714作出前向请求（SMT组件712），它将前向响应高速缓存在本地磁盘上。中间高速缓存进程可以用在SMT712和本地克隆进程714之间。通过在SMT机器中使用本地克隆进程714，可以使用（并优化）内容服务器和SMT之间的克隆到克隆通信。

图8示出了当CDN客户从其编码器向CDN EP发布流时使用的第一实况流化工作流实施例的实施例。

图9示出了当最终用户向内容服务器作出实况请求时所使用的第二实况流化工作流的实施例。

现在参考图8，编码器向EP发布实况流。摄取服务器优选地使用streamID查询适当的流配置，来认证编码器连接（步骤1）。然后，摄取服务器多路分解输入，并将流推送到ESM（步骤2）。ESM自动创建发布点，优选地，将三（3）个基于XML的文件上传到存储器：实况会话（LiveSession）、LSM、以及ACF。在每一个实况流会话开始时，创建这些每会话元数据文件（步骤3）。LiveSession文件包括实况流信息，诸如入口点IP、sessionID，以及streamState。LSM包括特定于会话的元数据，如比特率等等。ACF包括用于配置实况流的档案副本的信息。随着ESM从摄取服务器接收到段，它将段聚集到本地盘上的段中。当段大小到达累积阈值时，它将段上传到存储器。与上传到存储器的每个段一起，ESM还上传FDX文件（步骤4）。FDX（段索引）文件是提供已被上传到存储器的段的索引的二进制编码的文件。此索引告诉SMT什么段在存储器中，在哪里定位它们。对于不在FDX文件里的段，段位于EP上（因为它还没有上传到存储器）或者段实际上不存在。一旦流停止，LSM和livesession.xml文件就被更新，以将“streamState”属性从“开始”改变为“停止”。

图9示出了当最终用户客户端向内容服务器上的内容服务器克隆进程作出实况流化请求时的工作流的示例性实施例。客户端（例如，客户端媒体播放器应用）向内容服务器克隆进程作出流请求（步骤1）。然后，此进程向SMT作出前向请求（步骤2）。如果这是向SMT机器的对此实况流的第一请求，则SMT构建并高速缓存有关实况流的信息。为获得此有关实况流的信息，SMT从存储器拉取过去的DVR段的信息，并从EP拉取当前段的信息。SMT向存储器发出获得livesession.xml和LSM文件的请求。LSM文件将给出有关实况流以及查询什么FDX文件以获得特定段索引范围的信息（步骤3）。为知道什么段位于EP上，SMT向EP作出清单请求，清单将列出驻留在EP上的当前段索引集（步骤4）。一旦SMT发现并获取请求的段，它就将段多路复用为输出格式。当使用BSI指令时，SMT不创建实际输出对象，而是SMT创建包含适当的容器格式标头和IF段请求的BSI指令响应（步骤7）。内容服务器发出对IF段的请求，优选地，此请求仅对于“mdat”数据（是视频/音频数据）（步骤8）。然后，内容服务器克隆进程使用响应中的指令和IF段来构建输出对象。它将所产生的输出对象作为对原始请求的响应发送回到最终用户（步骤9）。为让SMT知道什么段在存储器中，优选地，它连续地轮询存储器，以了解FDX文件的最新的版本（步骤10）。对于FDX文件的轮询间隔通常是给定的，潜在地可配置的时间长度（步骤10）。为让SMT知道什么段在EP上可用，优选地，SMT轮询EP，以了解最新的清单文件（步骤11）。

下面一节描述从客户端播放器→内容服务器→SMT的实况、档案和IF请求的优选的URL格式。

在一个实施例中，对于实况流请求，客户端播放器URL可以具有下列格式：

http://<domain>/<formatPrefix>/<streamID>/<streamName>/<additionalParams>

实况和档案URL优选地具有表示流化容器格式和请求的类型（例如，实况、档案）的前缀。

在一个实施例中，对于档案流请求，客户端播放器URL可以具有下列格式：

http://<domain>/<formatPrefix>/<streamID>/<streamName>/<sessio nID>/<streamName>/<additionalParams>

URL的sessionID部分区别来自不同的实况流会话的档案。档案URL给出存储器中的档案目录的位置。档案URL“格式”简单地是到档案被上传到的默认存储位置的路径。在需要时，档案可以被移动到不同的存储器目录，在这样的情况下，档案路径URL被改变到新的存储器目标位置。优选地，档案URL立即可用于回放，即使实况事件还没有结束。档案URL表示到目前为止被存档到存储器的内容。例如，如果实况流事件已经运行了60分钟，并且58分钟的事件被存档到存储器，则档案URL表示58分钟长的VOD文件。随着更多内容被存档到存储器，档案URL表示更长的VOD文件。

通过取得客户端请求的“基础URL”并将段（<params>）附加到末尾，构建IF URL。“基础URL”通常是URL的直至并包括文件名的部分。IF URL参数是通过逗号分隔的名称/值对，并指定比特率和响应类型：

http://<domain>/<formatPrefix>/<streamID>/<streamName>.<fileExtension>/

Fragment（brt=<bitrate>,idx=<fragmentIndex>,trk=<trackName>,typ=<fragmentType>）

说明性参数标签名称包括：

·brt–比特率

·idx–段索引

·trk–轨道名称（通常音频或视频）

·typ–响应段的类型，可能的值是bsi、frg、hdr、dat

对于“typ”参数，如果指定了“bsi”，则SMT将返回BSI段响应。（请注意，对于涉及BSI之外的指令集的实施方式，参数可以是“instr_set_name”。）如果指定了“frg”，则SMT将返回f-MP4段。如果指定了“hdr”，则SMT将只返回f-MP4标头。如果指定了“dat”，则SMT将返回f-MP4段的mdat框。mdat框是包含音频/视频样本的MP4框。

在操作中，随着ESM从摄取服务器接收到实况流段，ESM将数据写入到本地盘。对于多比特率流，ESM具有将所有比特率聚合到单一文件或者每比特率具有不同文件的可配置选项。聚合到单一文件的优点是，到存储器的文件上传的数量缩小。单一文件的缺点是，不可能只检索单一比特率的段，而不也检索其它比特率的段，从而使得当由最终用户请求单一比特率时，在SMT上高速缓存不那么有效。但是，在任一种情况下，所有段通常都位于单一文件中（对于一个比特率或者许多）。ESM尾窗口参数配置多少ESM将保存在本地盘上。一旦段超出尾窗口之外，ESM将从本地盘中删除它。

如果启用了“存档到存储器”参数，则ESM将把流存档到存储器，供以后进行DVR或VOD回放。通常，ESM存储实况流的最后“n”分钟。如果客户希望它们的实况流的4小时DVR窗口，则客户启用“存档到存储器”，以便比n分钟旧的段被保存在存储器中，并可用于DVR。对于某些流，客户可以禁用“存档到存储器”，并且实况流不上传到存储器。在这样的情况下，从EP供应实况流段请求。某些客户具有24x7流，并且希望，比方说，1天DVR功能。在该情况下，客户启用“存档到存储器”，并启用一（1）天“存档尾窗口”。通过存档到存储器，从存储器有比“n”分钟旧的DVR请求。“存档尾窗口”设置可以限制存储在存储器中的档案的大小。例如，如果“存档尾窗口”被设置为1天，则ESM将自动地从存储器中删除比1天旧的存储器段。这对客户有好处，因为他们可以具有长DVR窗口，但是不必担心为他们的长时间运行的实况流清理存储器。

SMT可以通过来自ESM的流“通告”来确定所有活动的实况流。图10示出了优选技术。在此特定实现中，SMT必须知道所有实况流的状态，因为内容服务器克隆进程可以向任何SMT发出实况流请求，并且SMT必须知道从哪一个EP获得段。另一方面，如果实况流状态是不活动的，则SMT将知道只从存储器中检索段（假定启用了“存档到存储器”选项）。

在图10所示出的实施例中，使用从SMT到ESM的HTTP GET请求，完成SMT和ESM之间的实况流通告。为减少从SMT到EP的HTTP请求的量，优选地，EP区域（例如，EP区域1或2，如图所示）中的每一个ESM向相同区域中的其它EP发出HTTP请求，并要求EP上的所有实况流。ESM将来自相同区域中的其它EP的所有活动的实况流聚集在一起。因而，SMT只须向EP区域（即，一组EP机器）中的单一EP机器发出HTTP GET请求，以获得有关区域中的所有活动的实况流的信息。其次，当SMT向EP机器发出请求时，优选地，通过SMT本地克隆进程利用给定（例如，5秒）生存时间（TTL），发出请求。然后，当SMT区域中的其它SMT机器向EP区域发出相同请求时，可以通过高速缓存间协议或ICP（即，SMT区域中的其它SMT可以用来对请求作出响应的协议，如果可能的话，消除了前进到EP的必要性）潜在地供应该请求，因为SMT区域中的另一个SMT仅仅在几秒钟以前发出相同请求。

由于到EP的前向请求显式地将包含EP IP地址，所以区域中的所有SMT应该向EP区域中的相同EP机器发出HTTP请求，以使用ICP。如果请求不是向同一EP机器发出的，则高速缓存密钥将不同，并且无法使用ICP。因此，选择要查询的EP机器的算法优选地是确定性的，并可跨所有SMT重复，以便所有SMT都将向EP区域中的同一个EP发出前向请求。优选地，从SMT向EP的轮询每隔几秒钟进行，并通过全局服务器设置来进行配置。具有短的轮询间隔最小化了客户发布流和SMT知道流存在于EP上之间的时间量。从SMT到EP的请求逻辑处理EP停机供维护或临时无法访问的情况。

如上文所指示的，实况流档案存储在存储器上，供以后进行VOD回放。实况流会话的任何元数据也都存储在存储***上，优选地，与实况流档案存储在相同位置。如果没有启用“存档到存储器”，则没有东西存储在存储器上。

为简化向任何容器格式的输出多路复用，如上文所指示的，摄取的段被多路分解为IF格式（中间格式）。一旦摄取流被转换（多路分解）为IF，多用调制器可以从IF格式转换为任何支持的流化容器格式。这简化了从任何输入（源）格式到任何输出（目标）格式的转换。Microsoft出品的PIFF（受保护的可互操作的文件格式）容器格式，可以被用作IF容器格式的基础。PIFF通过提供分段的多比特率HTTP流化的指南和UUID扩展，增强了MPEG-4部分12规范。除PIFF之外，用于容器格式的其它选择是Adobe的用于Flash的HTTP流化（Zeri）、Apple的MPEG2-TS、或专有的格式。

对于实况流配置，优选地，对于每一个流化格式，存在不同的元数据信道。

容错、冗余、以及复制

对于流冗余和故障转移，客户可以向主要入口点和一个或多个备份入口点发布流。EP还可以支持DEEM（动态入口点到编码器映射），以提供从编码器到入口点的最佳DNS映射。如果EP发生故障，则DEEM可以通过快速地将入口点别名（例如，通过DNS CNAME）重新映射到正在运行的EP，来最小化流停机时间。DEEM功能包括当EP别名从一个EP切换到另一个EP时恢复实况流会话的能力。当编码器向一个EP推送流而该EP发生故障时，DEEM重新映射别名，然后，编码器开始推送向新EP，EP将段“附加”到以前的实况流会话。这意味着，来自以前的会话的实况流DVR被保留，并且存储器中的档案不中断。

为使EP支持DEEM，每当编码器向EP推送流时，EP都必须确定流是否是全新的流还是从以前的实况流会话的DEEM故障转移。EP通过从存储器获得相应的livesession.xml来确定流的状态。livesession.xml包含“streamState”。如果流是DEEM故障转移，则“streamState”将具有“已开始”值。EP还执行一致性检查，诸如查询旧EP，以确定流是否实际存在。一致性检查确保新EP不会当流不是DEEM故障转移流时无意地将流视为DEEM故障转移流。对于当流不存档到存储器时的情况，EP简单地摄取实况流，而不从存储器中检索livesession.xml。SMT执行将来自不同EP的实况流缝合到单一实况流中的工作。

livesession.xml包含对于DEEM支持的下列属性：

·streamState–保存流的状态

·lastRefreshTime–EP利用当前状态最近更新livesession.xml时的时间

·discontinuityThreshold–EP将不会恢复以前的实况流的时间阈值

默认地，“discontinuityThreshold”被设置为给定时长，例如，30分钟。这意味着，如果EP发生故障，并且编码器在30分钟内不向新EP推送流，则实况流会话将不会恢复。EP通过针对“lastRefreshTime”减去当前时间，检查是否超过阈值。如果此时间差超过30分钟，则EP将不会恢复以前的实况流会话。

为使SMT支持DEEM，SMT通过流通告来跟踪流状态。当编码器停止时，实况流变换到EP上的“停止”状态。如果EP发生故障，则流不流畅地变换到“停止”状态。SMT跟踪不流畅的流状态转换，并且如果需要，它将实况流会话缝合在一起。SMT组合来自以前的实况会话的DVR段以及当前恢复的实况流会话。从最终用户观点来看，合并的实况流会话是单一实况流会话。

在某些情况下，可能需要将单一摄取流复制到另一个EP。一种可能的使用情况便于实况流档案冗余，该冗余可以用于在备份EP上提供实况流档案的热备份。在此方法中，如果主要EP发生故障，则编码器可以开始向备份推送流，并且过去的DVR仍可用，因为它是自动复制的。这样的复制的另一种使用情况是实况流重新分配，其中，实况流可以被复制到遥远的EP（例如，在美国摄取，复制到欧洲）。利用复制到另一个遥远的EP的流，供应该遥远区域的内容服务器、SMT、EP以及存储器可以靠得更近（例如，所有都在欧洲），缩短了它们之间的网络距离。图11示出了一种说明性技术。在此实施例中，优选地，摄取入口点上的ESM具有复制流的选项。复制的流被全部发送到备份EP或者另一个EP。在使用流复制的情况下，目标流优选地使用与源流不同的流ID。

按需流化操作

类似于实况流化，如图12所示，在按需实施例中，SMT组件处理来自内容服务器的按需请求。同一个SMT机器可以处理实况和按需请求二者。

如图12所示，SMT机器优选地具有两个主要服务：SMT以及本地克隆。SMT服务使用转换库来处理请求URL，以及转换库构建到存储器或客户源的适当的前向请求。通过SMT本地克隆进程，发出这些前向请求，这些前向请求使用高速缓存进程作为SMT和本地克隆之间的媒介。优选地，相同转换库组件用于按需和实况流化。

下面详细描述了当最终用户向内容服务器发出按需流请求时的工作流。客户端播放器向内容服务器发出流请求（步骤1）。内容服务器克隆进程向SMT机器作出前向请求（步骤2）。如果这是向SMT机器的对此按需流的第一请求，则SMT需要构建并高速缓存有关按需流的信息。为获得此信息，SMT首先将请求URL传递到转换库，转换库构建对原生格式文件的适当的前向请求。SMT通过SMT的本地克隆进程，向存储器/客户源发出这些前向请求（步骤3）。转换库获取前向响应，并构建请求的输出格式的响应（例如，BSI）（步骤4）。SMT将响应返回到内容服务器（步骤5）。BSI响应包含特定于容器的格式标头和对于IF段的请求URL。基于BSI指令，内容服务器克隆进程发出构建输出对象的IF请求（步骤6）。输出对象以原生格式返回到最终用户（步骤7）。如上文所指示的，BSI是可选的，但是，可以被用来缩小内容服务器克隆进程上的高速缓存占用空间。如果BSI未启用，则SMT可以将原生输出对象返回到内容服务器克隆进程。原生输出对象可以由内容服务器高速缓存，正如来自源服务器的任何HTTP对象一样。

对于按需请求，客户端播放器URL可以具有下列格式：

http://<domain>/<formatPrefix>/<forwardpath>/<streamName>

类似于实况和档案URL，按需URL具有表示流化容器格式和请求的类型（即，按需）的前缀。

如果启用了BSI功能，则SMT返回包括容器标头和mdat数据的IF URL的BSI段。对于iPhone，例如，IF URL对于音频和视频看起来像下面的格式：

http://example.com/iosvod/path/video.mp4/Fragment（brt=512000,idx=5000,trk=video,typ=dat）

http://example.com/iosvod/path/video.mp4/Fragment（brt=64000,idx=5026,trk=audio,typ=dat）

将段（<params>）部分附加到客户端请求（例如，上面的示例中的video.mp4）的“基础URL”。“基础URL”通常是URL的直至并包括文件名的部分，但是，可以随着流化格式而变化。

为多路复用到期望的输出格式，SMT上的转换库包含多路分解原生输入文件并多路复用到请求的输出对象的逻辑。对于请求处理工作流，转换库首先解析原生输入文件，以生成MetaIndex。MetaIndex是包含诸如合成时间、解码时间、IF段边界、以及到每一个IF段的原生源文件的字节范围偏移之类的信息的通用索引。输出多路复用器使用MetaIndex来从原生源文件中提取适当的字节，并使用诸如合成时间之类的其它信息来构建适当的容器标头。MetaIndex提供到原生源文件的普通接口。此接口是原生源文件上面的抽象层，以便输出多路复用器不必要知道基础容器格式。此设计的优点是，如果希望支持新输入容器格式，则实现新原生源文件解析器/多路分解器，但是，输出多路复用器仍保持不变。类似地，如果希望支持新输出容器格式，则实现新多路复用器，但是，输入多路分解器仍保持不变。图13示出了此抽象层。在需要时，MetaIndex可以被高速缓存在SMT的本地克隆进程高速缓存内，供以后再使用或供ICP对等伙伴使用。创建MetaIndex会花费时间，并且高速缓存在本地克隆进程上缩小对于第一VOD段请求的响应时间。为支持本地克隆进程高速缓存，SMT通过克隆作出对于“/metaIndex”的本地主机请求。回送请求由本地SMT处理，其响应被克隆进程高速缓存。区域中的其它SMT也获得使用此MetaIndex的优点，因为它通过ICP可用。

上文所描述的体系结构（对于实况或按需）是可扩展的，以支持任何流化格式。下面一节描述了如何支持新流化容器格式。

图14示出了用于支持iPhone内容的摄取和iPhone内容的输出的技术的一个示例性实施例。在此实施例中，iPhone EP1400摄取Apple分段的MPEG2-TS流，转换库1408支持用于多路分解和多路复用MPEG2-TS的MPEG2TS。转换库1408解析iPhone URL，并将它们重写为前向路径。在EP1400上，iPhone摄取服务器1406处理来自编码器1402的HTTP POST/PUT的请求。iPhone摄取服务器将TS段传递到转换库1408，以便多路分解为IF（例如，f-MP4）格式。然后，iPhone摄取服务器将IF段发送到本地ESM1401。ESM将流存档向存储器，并向SMT宣告实况流，如上文所描述的。在SMT1412上，转换库1416处理m3u8和MPEG2-TS的iPhone请求URL。转换库1416构建BSI响应，并将它返回到内容服务器1415。对于MPEG2-TS段，每188字节，数据分组与容器标头交织。这意味着，对于音频/视频的每188字节，将会有一些容器标头。优选地，BSI语法支持循环构造，以降低BSI响应的复杂性，并且仍生成适当的MPEG2-TS段。使用BSI来多路复用内容服务器上的对象是可选的。如果禁用了BSI的话，SMT1412还可以将原生MPEG2-TS段返回到内容服务器1415。

图15示出了用于支持Shoutcast（在线音乐）格式的实施例。Shoutcast是主要用于通过类似于HTTP的连接进行音频实况流化的协议。为播放Shoutcast流，客户端发出HTTP请求，并且HTTP响应体是连续的音频流（即，无限制的响应体）。音频流是MP3数据（或AAC/OGG）和Shoutcast元数据的混合。Shoutcast元数据通常包含歌曲标题或歌唱家信息。尽管Shoutcast协议类似于HTTP，但是，它不是真的HTTP，因为协议包括一些非标准HTTP请求和响应标头。如图15所示，此实施例包括Shoutcast EP1500来摄取Shoutcast编码的流。提供了用于Shoutcast库的TranformLib1508以多路分解和多路复用MP3/AAC/OGG。转换库1508还解析Shoutcast URL，将它们重写到前向路径，并生成BSI指令。由于客户端播放器下载连续的无限制的HTTP响应，因此内容服务器克隆进程1415必须将分段的前向源请求转换为单一连续的客户端下载。BSI指示克隆进程如何从对前向请求的分段的响应构建客户端响应。如图15所示，对于Shoutcast支持的网络体系结构类似于如图14中所提供的iPhone支持。Shoutcast EP1500摄取流。摄取服务器使用转换库1508多路分解流。然后，它将流发送到ESM1501。ESM和SMT组件仍保持不变。SMT1512上的转换库1515解析Shoutcast URL，为Shoutcast创建BSI响应，并多路复用为Shoutcast输出格式。

额外的性能优化

对于实况流化，可以基于诸如服务级别协议、事件的优先级等等，按优先级处理一些客户流量。为提高无缺点的流分发的可能性，可以可配置的每客户地或每流地设置对于一个客户的多少流应该停留在存储器高速缓存中的每客户配额。通过将流高速缓存在存储器中，避免了对于实况流段的盘读取。配额可以是基于时间的（例如，实况流的最后5分钟）或基于大小的（例如，实况流的100MB）。当为流定义客户配额时，***尝试将流维持在存储器中。没有配额的其它流首先从存储器过期，优选地使用“最近最少使用”策略。

在此实施例中，当从编码器接收到实况流时，实况流段应该尽可能长时间地保持在存储器中，而不写入到盘中。如果存储器内服务器缓冲器已满，则可以将EP写入到盘中，优选地使用“最近最少使用”策略。此外，如果可能的话，优选地从存储器内服务器缓冲器供应向EP的对于实况流段的请求。如果段不在存储器内缓冲器中，则EP可以从盘中读取，并供应回响应。

二进制端包含（BSI）

BSI是可在内容服务器执行的以在给定输入对象和某些指令的情况下生成输出对象的功能的名称，通常来自诸如上文所描述的SMT组件之类的另一个组件的指令。指令通常定义要对输入数据执行的操纵或动作。这样的功能旨在允许对有效负载修改，因为它们被供应到发出请求的客户端，允许内容服务器在给定一般对象的情况下轻松地提供自定义或半自定义内容。在典型的但是非限制性实施例中，此功能可以被嵌入到内容服务器上的HTTP代理（克隆）应用中，虽然在替换实施例中，它可以在克隆外部实现。

通常，由内容服务器作出的许多修改导致对内容的最小的总体改变，意味着供应到发出请求的客户端的所产生的数据不同于输入，例如，只有百分之几。在一个实施例中，定义了用于表示源和输出内容之间的差异（或“diff”）的机制，允许内容服务器中的通用特征以有效的方式处理增加数量的流化格式。

一般而言，利用BSI，使除内容服务器以外的组件负责定义或生成转换逻辑，并负责提供可以被内容服务器理解的指令——与二进制“diff”信息一起。通过提供用于表示源和输出内容之间的差异（或“diff”）的机制，并给内容服务器提供使用这些来修改通用源对象的方式，面向客户端的内容服务器可以有效地处理增加数量的请求。此外，取决于情况，可以高速缓存输入（例如，通用源对象、指令等等）。在某些情况下，还可以高速缓存进程的输出。

如前面所指示的，为了说明方便起见，在本发明中，此功能叫做BSI，二进制边缘端包含（Binary-edge-Side Include），或二进制服务器集成。BSI语言，利用下面所描述的提出的语法，定义不同的源——帮助构建最终输出的进入的数据段。指令（诸如“组合”等等）定义字节范围，以及如何合并这些输入的顺序，以及控制输出标头。当实时生成时，BSI段和源对象两者都可以被高速缓存（例如，在内容服务器中），比内容服务器直接处理它们对BSI生成层造成的负载少得多。对于固定/按需应用，可以生成BSI一次，并高速缓存BSI段（例如，高速缓存在内容服务器上，或高速缓存在网络存储器上或诸如图5-6中所示出的其它专用存储子***中）。

BSI方法理想地非常快。优选地，语法是基于XML的，并且通常使指令的数量非常低，允许快速的解析。BSI的执行指示内容服务器什么顺序，从哪一个源，填充供应到客户端的输出缓冲器。

在前面所描述的流化平台的上下文中，在SMT和内容服务器之间可以使用BSI功能，以简化从输入源（在上述情况中，IF段）创建输出对象（例如，对于iPhone或其它客户端设备，表示原生格式的流的输出对象）。SMT接收IF段并且执行多路复用步骤。代替多路复用的内容作为输出，SMT创建可以供应到内容服务器的动态BSI段，以及包含内容服务器需要与它通常接收到的IF段结合的额外的比特的二进制对象。内容服务器使用此信息来创建原生格式的多路复用的输出对象，表示流的全部或一些部分。

在以前的图中示出了使用BSI来流化的示例，但是图16示出了带有更多细节的工作流的实施例。在此说明性实施例中，内容服务器克隆进程1600接收来自客户端播放器1601的对于某些目标格式的特定内容的请求（步骤1）。内容服务器向多路复用层（SMT1602）发出对要求的BSI指令的请求（步骤2）。通常，请求包括通过查询字符串的参数，以指定请求的类型（清单、内容、密钥文件等等）、请求的比特率、时间确定（段编号、时间偏移等等），及其它与多路复用相关的参数（段持续时间、A/V类型等等）。SMT1602从EP1604（步骤3）或存储器1603（步骤3a）获取相关IF段，从IF段构建适当的输出对象，好像它将供应内容，创建IF段中所包含的东西以外的所需的字节的缓冲器，以及有关如何与IF“交织”或组合二进制diff的指令。在某些实现中，应了解，任何需要的diff数据都可以直接嵌入在指令本身中。在步骤4中，SMT1602将BSI响应发送到内容服务器。响应也可以包括对所需的IF段的引用。内容服务器以各种方式中的任何一种获取IF段，包括从SMT（即，除BSI之外），从其自己的高速缓存，或从存储器1603，该存储器1603通常是前面与流化平台一起描述的网络存储子***。纯粹作为示例，图16中的步骤5示出了从存储器到达的并被高速缓存的IF段。

由于由IF段表示的大量的数据被高速缓存在内容服务器中，带有其二进制diff的BSI响应通常可以是大约要供应的对象的总大小的百分之几。内容服务器克隆1600应用BSI，生成多路复用的输出对象并将其供应到客户端（步骤6）。包括指令和diff数据的BSI响应，可以由内容服务器克隆1600高速缓存某个时间段。优选地，在请求中供应到SMT的参数（步骤2）用于高速缓存密钥中，以便只有随后对带有相同参数的内容的请求才使用高速缓存的BSI响应。不必高速缓存BSI操作的输出。

前述的方法可以提供各种优点。由于可以使用BSI指令来告诉内容服务器克隆进程如何多路复用或以别的方式创建输出对象，因此BSI为进程提供支持任何流化容器格式的方式，而不需要在内容服务器克隆进程处相关联的代码改变。为处理新容器格式或缺陷修复以支持现有的容器格式，BSI指令可以改变，但是内容服务器克隆进程逻辑保持不变。这消除了当开发或实现新流化特征时与内容服务器或其克隆进程的任何跨组件的依赖关系。

进一步地，为使用不同的容器格式流化到客户端设备，BSI可以缩小克隆高速缓存占用空间大小，因为克隆进程高速缓存IF段，但是，将IF多路复用到不同的原生格式。优选地，不高速缓存多路复用的输出；相反，只高速缓存IF段。例如，可以使用***来将AdobeZeri（用于Flash的HTTP流化）流化到运行Flash10.1的Android设备，将MPEG2-TS流化到iPhone设备。对于实况流，只高速缓存IF段，内容服务器对于Android设备，多路复用到Zeri，对于IPhone设备，多路复用到MPEG2-TS。这些仅仅代表性的示例。

为流化渐进下载风格的格式（诸如Shoutcast），数据作为长时间运行的无限制的HTTP下载而被流化到客户端。从最终用户客户端角度来看，它下载永不结束的文件。BSI功能可以用于渐进下载风格的格式，具体而言，将来自源（例如，内容提供商源或CDN存储子***）的段响应多路复用到用于客户端的连续的HTTP下载流。使用由（可由内容提供商配置的）内容服务器克隆进程应用的元数据和来自SMT的渐进下载风格的BSI，还可以使用BSI来实现特定于渐进下载的特征，如，jump-to-live-on-drift和基于用户代理的延迟的元数据注入。因而，特定渐进下载风格要求可以固有地通过BSI来支持，而不要求内容服务器中的任何改变。

分段的流化格式（诸如Zeri、iPhone以及Silverlight）也可以使用BSI功能。例如，SMT可以给内容服务器发送原生格式的内容或内容服务器克隆进程多路复用为原生格式的BSI段。如果CDN内容提供商客户只为单一容器格式执行流化，则没有必要高速缓存IF段以及通过BSI在内容服务器克隆进程上多路复用。在这样的情况下，SMT返回内容服务器克隆进程高速缓存的原生对象更有效。允许或禁止使用BSI是可配置的，优选地逐个内容提供商地，并且对于给定内容提供商，逐个站点地，或者甚至逐个文件地。

为了说明方便起见，下面的讨论引用了BSI语言，并提供BSI指令的各种示例；然而，此处所讨论的特定语言、指令和功能应该被视为说明性的，而不是限制性的。

BSI语言

在一个实施例中，语法是XML，这对于方便的解析和与其它内容服务器功能兼容是有利的（例如，也可以以XML来实现的控制文件元数据）。

源

BSI接受一个或多个源的定义。随后的动作引用源id。

动作

接下来是动作，这里是指通过id定义的源，并指示如何排序来自不同的源的字节以构建供应的输出。动作最好被结构化为使它们容易解析，并尽可能地简洁。解释器能够解析全部所需的动作，并在创建输出缓冲器时，按照使用的顺序，分类它们。这使得缓冲的数据量最少，并且它允许在客户端断开连接或遇到错误的情况下，在任何一点进行短路处理。

当可能时，应该使用诸如组合之类的指令，因为它允许编译器/解释器轻松地确定整个输出对象的字节的准确的顺序，供应它，而无需中间缓冲器。

Insert指令提供向一组已经被分配到输出缓冲器的字节应用功能的方式。例如，可能需要指令来向输出中的相邻的，而不是在我们的源中的字节应用密码或散列，因而初始组合操作期间的功能没有用。一种方式将是允许操作从输出缓冲器拉取，如由*的源所指示的。也可以实现此操作上的可选目的地-长度参数，这将允许将结果写入到相同块中，但是，如果需要，偏移字节。这将对可以填充数据的密码有用。（由于功能已经是可选项目，因此可能需要区别功能，例如，通过在前面加$）。

1.

2.<bsi:combine>[b:0:0x128,a:68:90,a:92:65043,b:0x124:0x23]</bsi:combine>

3.

4.<bsi:insert>[*:96:64:96:64:$enc]</bsi:insert>

非动作命令

这些是与动作不同，不直接作用于输出缓冲器的命令。

转换功能

转换定义在用于其他命令中时可以应用于字节范围的功能。

其它

为支持某些使用情况，可能希望允许元数据变量被置于代码中。在运行时，克隆将这些替换为元数据上下文中的变量。条件逻辑对于多种使用同样重要，但是，它可能影响上文所描述的非常简化的并且容易解释的语言。为解决此，可以向每一个语句添加“已启用”属性，该属性利用ARL元数据变量来控制。下面示出了这被用作一种IF/ELSE，取决于变量%（TEST）如何评估。

1.

2.<bsi:combine enabled="%(TEST)">[b:0:128,a:68:90,a:92:65043]</bsi:combine>

3.

4.<bsi:combine enabled="!%(TEST)">[b:129:1024,a:68024:2048,b:1153:64,c:0:*]</bsi:combine>

在此示例中，已启用的值将评估为布尔值，接受0/1，或真/假，还将允许“!”指示“非（NOT）”。在解析BSI语句之前，执行元数据变量替换；优选地，BSI段的任何高速缓存不必包括变量替换。

变体

对于***和替换，可以有允许相同源数据被注入在目的地中的多个点的可选语法。另一种优化是指示要***给定数据的模式的符号，诸如：

<bsi:insert>[a:0:*:0,b:0:64:214（128:10）...]</bsi:insert>

在此示例中，在从偏移214开始的情况下，每128字节***来自源b的字节的部分，迭代10次，等等。这样的编码将对于某些类型的转换，缩小BSI段中的大小和冗余。或者，代替数学组件，解释器可以操作，以简单地导致diff中的完整的标头的存储，但是具有重复语句，该重复语句具有两个偏移，这将非常快速。例如，假定段在源B的字节64开始，取14字节用于分组标头，将每14字节重复200次，基本上将每一个标头一个接一个地存储在diff中。然后，在目的地侧，每188字节，放置那些字节——迭代200次。此语法如下：

<bsi:insert>[a:0:*:0,b:64:14（14:200）:214（188:200）]</bsi:insert>

对于长时间运行的连接，特别对于实况媒体，将BSI段链接在一起是有用的。段结尾处的语句可以指示克隆系列中的可以根据需要检索的下一个段。这将允许组件（例如，多路复用器）生成处理当前可用的缓冲器的BSI段，然后，告诉克隆，什么段使用下一个可能的时间参数。

<bsi:continue fragment="http://origin/fragment.bsi?time=12345"/>

用于在流化平台中多路复用应用的示例

这里是示出了BSI标签的使用的多路复用的示例：

1.

2.<bsi:source id="a"type="remote"target="http://origin/IF_Fragment(time=%(TIME),bitrate=%(BITRAT E))"/>

3.

4.

5.<bsi:source id="b"type="local"/>

6.

7.<bsi:source id="c" type="inline">bGxvdy11cCAoc29tZSBhbWJpZ3VpdHkgaGVyZSB3ZSBuZWVkIH RvIGNsZWFu=</bsi:source>

8.

9.<bsi:combine>[b:0:128,a:68:90,a:92:65043,b:129:1024,a:68024:2048,b:1153:64,c:0:*]</bsi:combine>

10.

11.<bsi:validate length="67373"md5="d8e8fca2dc0f896fd7cb4cb0031ba249"/>

12.

13.<bsi:set target="header"name="Content-Type"value="video/flv"/>

14.<bsi:set target="header"name="Content-Length"value="2147483647"/>

在诸如多路复用之类的某些使用情况下，BSI和替换数据可以动态地生成，因而此处的技术还允许数据被附加到BSI段，以阻止需要另一个往返请求。因而，例如，标头可以指示特定二进制blob被附加到BSI代码，用于由克隆更容易地解析：

X-BSI-Data:bytes126-4234\r\n

基于计算机的实现

此处所描述的客户端、服务器及其它设备可以利用常规计算机***来实现，如由此处的教导修改的，带有以特殊目的硬件、由存储在其中的用于特殊目的的软件配置的通用硬件、或其组合实现的上文所描述的功能特征。

软件可以包括一个或多个分立的程序。任何给定功能可以包括任何给定模块、进程、执行线程或其它这样的编程构造的一部分。一般而言，上文所描述的每一个功能都可以实现为计算机代码，即，作为可在一个或多个处理器中执行的提供专用机器的计算机指令集。代码可以使用常规设备——诸如计算机中的处理器、数字数据处理设备、或其它计算设备——来执行，如由此处的教导所修改的。在一个实施例中，这样的软件可以以和运行诸如Linux之类的操作***的标准Intel硬件平台上的代理一起运行的编程语言来实现。功能可以嵌入到代理代码中，或它可以作为该代码的附属来执行。

尽管在上面的某些情况下阐述了由某些实施例执行的操作的特定顺序，但是，应该理解，这样的顺序是示例性的，它们可以以不同的顺序，组合的顺序等等来执行。此外，一些功能还可以在给定指令、程序序列、代码部分等等中组合或共享。说明书中对给定实施例的引用表示所描述的实施例可包括特定特征、结构或特性，但是，每一个实施例可以不一定都包括该特定特征、结构或特性。

图17是示出了这样的软件可以在其上运行以便实现本发明的各实施例的计算机***1700中的硬件的框图。计算机***1700可以以客户端设备、服务器、个人计算机、工作站、平板计算机、无线设备、移动设备、网络设备、路由器、集线器、网关或其它设备来实施。在其上面提供此处的主题的代表性的机器可以是运行Linux或Linux变体操作***和一个或多个应用以实现所描述的功能的基于Intel Pentium的计算机。

计算机***1700包括耦合到总线1701的处理器1704。在某些***中，可以使用多个处理器和/或处理器核。计算机***1700还包括耦合到总线1701的主存储器1710，如随机存取存储器（RAM）或其它存储设备，用于存储信息和待由处理器1704执行的指令。只读存储器（ROM）1708耦合到总线1701，用于为处理器1704存储信息和指令。提供了非易失性存储器设备1706，如磁盘、固态存储器（例如，闪存）或光盘，并耦合到总线1701，用于存储信息和指令。其它专用集成电路（ASIC）、现场可编程门阵列（FPGA）或电路可以被包括在计算机***1700中，以执行此处所描述的功能。

***接口1712可通信地将计算机***1700耦合到显示在计算机***上执行的软件的输出的用户显示器1714，以及将用户输入和指令传递到计算机***1700的输入设备1715（例如，键盘、鼠标、跟踪板、触摸屏）。***接口1712可以包括诸如RS-485、通用串行总线（USB）、IEEE1394，或其它通信链路之类的本地总线的接口电路、控制和/或电平移动逻辑。

计算机***1700耦合到在***总线1701和外部通信链路之间提供链路（例如，在物理层、数据链路层或以其它方式）的通信接口1717。通信接口1716提供网络链路1718。通信接口1716可以表示以太网或其它网络接口卡（NIC）、无线接口、调制解调器、光学接口，或其它种类的输入/输出接口。

网络链路1718通过一个或多个网络提供到其它设备的数据通信。这样的设备包括是局域网（LAN）1726的一部分的其它计算机***。此外，网络链路1718还通过因特网服务提供商（ISP）1720提供到因特网1722的链路。因特网1722又可以提供到诸如远程服务器1730和/或远程客户端1731之类的其它计算***的链路。网络链路1718和这样的网络可以使用分组交换、电路交换、或其它数据传输方法来传输数据。

在操作中，计算机***1700作为处理器执行代码的结果，可以实现此处所描述的功能。这样的代码可以从诸如存储器1710、ROM1708或存储设备1706之类的非瞬时的计算机可读介质中读取或由它们来提供。其它形式的非瞬时的计算机可读介质包括盘、磁带、磁性介质、CD-ROM、光学介质、RAM、PROM、EPROM、以及EEPROM。可以使用任何其它非瞬时的计算机可读介质。执行代码也可以从网络链路1718中读取（例如，接口缓冲器、本地存储器、或其它电路中的存储器）。

值得注意的是，出现在此处的商标是它们的相应的所有者的财产，并只用于标识和描述性的目的，给定所涉及的主题的本质，而不以任何方式暗示认可或附属。

根据37CFR1.96（b）（2），下面包括示出BSI解释器的示例的计算机程序列表：

Claims

1.一种***，包括：

多个互连的机器，每个机器包括形成至少一个处理器的电路以及计算机存储器，所述计算机存储器保存要由所述至少一个处理器执行以便于按需流向客户端的分发的计算机程序代码；

所述多个机器包括：

第一机器，接收并解析与所述按需流相关联的并且是源格式的文件的至少一部分，所述第一机器生成下列各项中的至少一项：(i)表示目标格式的所述文件的至少一部分的输出对象，以及(ii)在创建表示目标格式的所述文件的至少一部分的输出对象时所使用的指令；

第二机器，接收所述输出对象或用于创建所述输出对象的所述指令，并将所述目标格式的所述输出对象供应到请求所述按需流的客户端，

其中，所述第一机器将所述文件的所述至少一部分转换为分段的中间格式，所述指令指定如何从一个或多个中间格式段创建所述目标格式的所述输出对象，并且所述指令包括特定于格式容器的标头和中间格式段的请求URL。

2.如权利要求1所述的***，其中，所述第一机器至少生成(ii)在创建表示目标格式的所述文件的至少一部分的输出对象时所使用的指令。

3.如权利要求1所述的***，其中，所述第二机器包括HTTP代理服务器。

4.如权利要求1所述的***，其中，所述第二机器高速缓存所述输出对象或所述指令。

5.如权利要求1所述的***，其中，所述第一机器从与内容提供商相关联的源服务器或与内容分发网络服务提供商相关联的远程存储***接收所述文件的所述至少一部分。

6.如权利要求1所述的***，其中，所述指令包括多路复用指令。

7.如权利要求1所述的***，其中，所述第一机器创建对所述文件的所述至少一部分的中间索引，所述中间索引包括下列各项中的至少一项：合成时间、解码时间、中间段(IF)边界、以及到中间格式段的所述文件中的字节范围偏移。

8.如权利要求7所述的***，其中，所述中间索引提供到所述源格式的所述文件中的普通接口。

9.如权利要求7所述的***，其中，所述中间索引被高速缓存，以供所述第一机器再使用。

10.如权利要求1所述的***，其中，所述指令包括用于将中间格式段多路复用到所述目标格式的指令。

11.如权利要求1所述的***，其中，所述第二机器从所述第一机器接收中间格式段。

12.如权利要求1所述的***，其中，所述第二机器高速缓存中间格式段。

13.一种由多个互连的内容服务器执行的以便于按需流向客户端的分发的方法，所述方法包括：

(A)接收并解析源格式的并且与所述按需流相关联的文件的至少一部分；

(B)生成下列各项中的至少一项：(i)表示目标格式的所述文件的至少一部分的输出对象，以及(ii)在创建表示目标格式的所述文件的至少一部分的输出对象时所使用的指令；

(C)接收所述输出对象或用于创建所述输出对象的所述指令；以及

(D)将所述目标格式的所述输出对象供应到请求所述按需流的客户端，

其中所述方法还包括将所述文件的所述至少一部分转换为分段的中间格式，其中，所述指令指定如何从一个或多个中间格式段创建所述目标格式的所述输出对象，并且所述指令包括特定于格式容器的标头和中间格式段的请求URL。

14.如权利要求13所述的方法，其中，步骤(B)至少包括(ii)在创建表示目标格式的所述文件的至少一部分的输出对象时所使用的指令。

15.如权利要求13所述的方法，其中，所述客户端的请求是HTTP请求。

16.如权利要求13所述的方法，进一步包括：高速缓存所述输出对象或所述指令。

17.如权利要求13所述的方法，进一步包括：从与内容提供商相关联的源服务器或与内容分发网络服务提供商相关联的远程存储***接收所述文件的所述至少一部分。

18.如权利要求13所述的方法，其中，所述指令包括多路复用指令。

19.如权利要求13所述的方法，进一步包括：创建对所述文件的所述至少一部分的中间索引，所述中间索引包括下列各项中的至少一项：合成时间、解码时间、中间段(IF)边界、以及到中间格式段的所述文件中的字节范围偏移。

20.如权利要求19所述的方法，其中，所述中间索引提供到所述源格式的所述文件中的普通接口。

21.如权利要求19所述的方法，其中，所述中间索引被高速缓存以供再使用。

22.如权利要求13所述的方法，其中，所述指令包括用于将中间格式段多路复用到所述目标格式的指令。

23.如权利要求13所述的方法，其中，步骤(C)进一步包括：接收与所述指令相关联的中间格式段。