专利名称：递送可缓存流媒体演示的制作方法
递送可缓存流媒体演示背景流媒体是在由流供应商(使用服务器)递送时由终端用户(使用客户机)不断地接收并通常被演示给终端用户的多媒体。存在用于流媒体的若干协议，包括通常一起使用的实时流协议(RTSP)、实时传输协议(RTP)和实时传输控制协议(RTCP)。由互联网工程任务组(IETF)开发的且在1998年被创建为征评定要求(RFC) 23 的实时流协议(RTSP)是供在流媒体系统中使用的协议，它允许客户机远程地控制流媒体服务器，发起诸如“播放” 和“暂停”等的VCR型的命令，且允许对服务器上的文件的基于时间的访问。流数据本身的发送不是RTSP协议的部分。大多数RTSP服务器将基于标准的RTP 用作实际的音频/视频数据的传输协议，这在某种程度上充当了元数据信道。RTP定义了用于在因特网上递送音频和视频的标准化分组格式。RTP是由IETF的音频-视频传输工作组开发的，在1996年被首次发布为RFC 1889，并在2003年被RFC 3550取代。协议在语法和操作方面类似于超文本传输协议(HTTP)，但是RTSP添加了新的要求。尽管HTTP是无态的， 但RTSP是有态协议。在需要时，使用会话ID来跟踪会话。RTSP消息从客户机被发送到服务器，尽管存在其中服务器将向客户机发送消息的一些例外。RTP通常结合RTCP使用。RTP运载媒体流(例如，音频和视频)或带外信令(双音多频(DTMF))，而RTCP被用来监视传送统计数据和服务质量(QoQ信息。RTP仅允许一种类型的消息，即将数据从源运载到目的地的消息。在许多情况中，存在对于用于会话中的其他消息的使用。这些消息控制数据的流和质量，且允许接收者向一个或多个源发送反馈。 RTCP是被设计为用于这一目的的协议。RTCP具有五种类型的消息发送者报告、接收者报告、源描述消息、结束消息和应用程序专用的消息。RTCP为RTP流提供带外控制信息。RTCP 与RTP在多媒体数据的递送和封装中合作，但是本身不传输任何数据。它在流多媒体会话中被周期性地用来将控制分组传送给参与者。RTCP的一种功能是提供对正由RTP提供的服务质量的反馈。RTCP收集关于媒体连接以及诸如所发送的字节、所发送的分组、丢失的分组、抖动、反馈和往返行程时延等的信息的统计数据。应用程序可以使用这一信息来提升服务质量，也许通过限制流或使用不同的编解码器或比特率。现有的媒体流传输体系结构的一个问题是服务器和客户机之间的紧耦合。客户机和服务器之间的有态连接产生了附加的服务器开销，这是因为服务器跟踪每一客户机的当前状态。这也限制了服务器的可伸缩性。另外，客户机不能在不首先与服务器通信并等待服务器适应和响应的前提下快速地对诸如增加的分组丢失、减少的带宽、对不同内容或者修改现有内容(例如，加速或倒带)的用户请求等等的改变的条件作出反应。通常，在客户机报告较低的可用带宽(例如，通过RTCP)时，服务器不会足够快速地适应，因未接收到超出了可用带宽的分组且未及时从服务器发送新的较低比特率的分组，而导致客户机上的用户注意到媒体中断。为了避免这些问题，客户机常常缓冲数据，但是缓冲引入了等待时间， 这对实况事件来说是不可接受的。另外，因特网包含许多类型的可下载的媒体内容项，包括音频、视频、文档等等。这些内容项常常是非常大的，例如数百兆字节的视频。用户常常通过web浏览器使用HTTP在因特网上检索文档。因特网已经组成包括路由器和代理服务器的、有效为HTTP缓存数据的大型基础设施。服务器可以以较少的延迟且通过使用比向原始源重新请求内容少的资源来向客户机提供所缓存的数据。例如，纽约的用户可以下载从日本的主机提供服务的内容项， 且通过加利福尼亚的路由器接收该内容项。如果新泽西的用户请求相同的文件，则加利福尼亚的路由器可以可以提供该内容项而无需再次向日本的主机请求数据。这降低了可能紧张的路线上的网络流量，且允许新泽西的用户以较少的等待时间接收该内容项。不幸的是，常常不能使用现有的协议来缓存实况媒体，且每一客户向从相同的服务器或一组服务器请求该媒体。另外，在可以缓存流媒体时，常常是由专用的缓存硬件来完成，而不是由现有的且容易获得的基于HTTP的因特网缓存基础设施来完成。缓存的缺乏限制了服务器可以应对的并行观众和请求的数量，且限制了实况事件的出席人数。世界正越来越多地使用因特网来消费最新的实况信息，例如大量用户经由因特网观看诸如2008年奥运会开幕式等的实况事件。当前的技术的限制正在减慢因特网作为消费这一类型的媒体内容的介质的采用。概述在此描述在客户机和服务器之间提供无态协议的平滑流传输系统，其中服务器将增量信息嵌入在媒体片段中，这消除了典型的控制信道的使用。另外，服务器提供了对媒体片段请求的统一媒体片段响应，由此允许现有的因特网缓存基础设施缓存流媒体数据。平滑流传输系统从一个或多个编码器接收以片段为单位的媒体数据、创建每一片段的索引并存储各片段。随着事件发展，服务器提供由客户机请求的片段，直到事件结束。每一片段除了由客户机回放的片段的媒体内容之外还包含描述服务器上可用的编码以及该片段的编码的元数据信息。服务器可以提供多种编码的片段，使得客户机可以例如基于网络条件快速地切换到不同的比特率或回放速度的片段。服务器也可以在每一片段内提供允许客户机判断该客户机是否正太快或太慢地请求数据的信息，使得客户机可以使其请求速率适应与服务器接收编码器数据的速率协调的节奏。因而，平滑流传输系统提供更具伸缩性的流媒体服务器而无需跟踪客户机状态，且具有客户机将以较低的等待时间从对客户机来说是本地的缓存服务器接收媒体的增加的可能性。提供本概述以便以简化形式介绍下面在详细描述中进一步描述的概念的选集。本概述不旨在标识所要求保护的本主题的关键特征或必要特征，也不旨在用来限制所要求保护的本主题的范围。附图简述
图1是阐释在一种实施方式中平滑流传输系统的组件的框图。图2是阐释在一种实施方式中使用微软Windows和微软因特网信息服务器(IIS) 的平滑流传输系统的操作环境的框图。图3是阐释在一种实施方式中系统从编码器接收媒体数据的处理的流程图。图4是阐释在一种实施方式中系统应对用于流媒体的客户机连接的处理的流程图。图5是阐释在一种实施方式中从编码器到源服务器再到客户机的媒体片段的流的数据流程图。详细描述
在此描述在客户机和服务器之间提供无态协议的平滑流传输系统，其中服务器将增量信息嵌入在媒体片段(即，块)中，这消除了典型的控制信道的使用。另外，服务器提供了对媒体片段请求的统一媒体片段响应(即，请求相同的片段的客户机获得相同的响应)， 由此允许现有的因特网缓存基础设施缓存流媒体数据。每一片段具有允许由因特网缓存服务器和客户机浏览器缓存两者标识和缓存该片段的特异的统一资源定位符(URL)。缓存减少了服务器上的负载，且允许更多客户机在相同的时间查看相同的内容。平滑流传输系统从一个或多个编码器接收以片段为单位的媒体数据、创建每一片段的索引并存储各片段。 随着事件发展，服务器提供由客户机请求的片段，直到事件结束。每一片段除了由客户机回放的片段的媒体内容之外还包含描述服务器上可用的编码以及该片段的编码的元数据信息。服务器可以提供多种编码的片段，使得客户机可以例如基于网络条件快速地切换到不同的比特率或回放速度的片段。服务器也可以在每一片段内提供允许客户机判断该客户机是否正太快或太慢地请求数据的信息，使得客户机可以使其请求速率适应与服务器接收编码器数据的速率协调的节奏。因而，平滑流传输系统提供更具伸缩性的流媒体服务器而无需跟踪客户机状态，且具有客户机将以较低的等待时间从对客户机来说是本地的缓存服务器接收媒体的增加的可能性。在一些实施方式中，平滑流传输系统在服务器和客户机之间使用特定的数据传输格式。客户机向服务器请求包括媒体的部分的媒体的片段。例如，对于10分钟的文件，客户机可以请求2秒的片段。注意，不同于其中服务器将数据推送到客户机的典型的流传输， 在这一情况中，客户机从服务器拉出媒体片段。在实况流的情况中，服务器可以在运行中创建媒体并产生片段以便响应客户机请求。因而，根据服务器创建片段的快速程度和客户机请求片段的快速程度，客户机可以仅落后于服务器若干片段。每一片段包含元数据和媒体内容。元数据可以描述关于媒体内容的有用信息，例如编码媒体内容的比特率、媒体内容处于较大的媒体元素中的何处(例如，这一片段表示在10分钟的视频剪辑中偏移1 10)、被用来编码媒体内容编解码器等等。客户机使用这一信息来将该片段放置到较大的媒体元素的情节串连图板中并适当地解码和回放媒体内容。图1是阐释在一种实施方式中平滑流传输系统的组件的框图。平滑流传输系统 100包括注册事件组件110、编码器接口组件120、索引片段组件130、片段数据存储140、客户机接口组件150、构建客户机清单组件160以及时钟同步组件170。在此进一步详细描述这些组件中的每一个。注册事件组件110接收关于该系统将对其接收经编码的媒体数据的实况媒体事件或其他媒体事件的信息。该信息可以包括将向服务器供应经编码的媒体数据的编码器中的每一个的网络地址信息或其他标识符。该信息也包括编码器将向其供应经编码的媒体数据且客户机可以在该处访问媒体数据的URL。编码器接口组件120在该系统和提供经编码的媒体数据的一个或多个编码器之间提供接口。编码器可以使用普通网络协议来将数据推送到该系统。例如，各编码器可以使用HTTP POST请求来向系统提供经编码的媒体数据。各编码器中的每一个都可以使用指定作为经编码的媒体数据的源的编码器的特异URL，在媒体事件被注册时服务器可以使得该URL与由注册事件组件110接收的信息相匹配。
编码器接口组件120可以为所接收的经编码的媒体数据指定特定的格式，例如 MP4或其他媒体容器(例如，MKV)。MP4容器格式允许在单个文件中关联多种类型的数据。 构成MP4容器的各个数据被称为盒子，且每一盒子通常具有标识被存储在盒子中的数据的类型的标签。编码器可以将诸如被用来编码经编码的媒体数据的编码类型等的元数据信息以及经编码的媒体数据本身放置在盒子中。索引片段组件130创建和维护从各种编码器接收的片段的索引表。因为系统100 在事件期间从潜在地许多编码器持续不断地接收媒体片段，系统100使用索引表来跟踪已经接收什么媒体片段以及从哪个编码器(或以哪种格式)接收媒体片段。每一编码器可以使用用于标识媒体片段的常用方法(例如，使用同步时钟时间戳)，使得索引片段组件130 可以使得表示实况事件中的相同时期的来自不同编码器的片段相关。以此方式，系统100 可以检测媒体片段何时丢失，且可以向客户机提供关于可用的媒体片段的清单信息。片段数据存储140存储所接收的媒体片段和所创建的各片段的索引表，以便基于所接收的客户机请求来提供给客户机。片段数据存储可以包括数据库、盘驱动器或其他形式的数据存储(例如，存储区网络(SAN)或甚至是基于云的存储服务)。客户机接口组件150接收对媒体片段的客户机请求并将清单数据和媒体片段提供给客户机。在客户机初始连接到系统100时，客户机可以发送对客户机清单的请求。客户机接口组件150调用构建客户机清单组件160来基于索引表创建包括关于从系统100可用的编码以及到当前时间为止由系统100存储的片段的信息的清单。客户机可以使用这一信息来开始请求正在进行的实况片段或在时间上向后跳跃到演示的较早部分。例如，这可用于如果客户机加入已经进行的实况事件且想要赶上该事件的先前的部分。构建客户机清单组件160构建包括关于从系统100可用的编码以及到当前时间为止由系统存储的片段中的每一个的信息的清单以便满足客户机请求。构建客户机清单组件 160也提供与每一媒体片段包括在一起的清单，该清单将关于当前的媒体片段以及潜在地后续片段的信息提供给客户机。通过将初始接收的清单与随每一媒体片段一起提供的后续清单组合起来，客户机可以构建包括从开始直到当前的时间的关于媒体事件的完整信息的最新清单。在媒体事件完成时，客户机具有客户机可以用于媒体事件的按需查看的媒体事件的完整的情节串连图板。在一些实施方式中，客户机接口组件150以鼓励客户机在各媒体片段可用之后的一定时间量作出请求的方式来响应客户机请求。例如，系统100可以不用特定的媒体片段响应，直到系统100已经从各编码器接收一个或多个后续片段。这允许系统100将关于后续片段的清单信息包括在当前的片段响应中。系统100也可以向客户机提供客户机可以对每一媒体片段期望的后续片段的计数。这变成了客户机的计时提示。如果客户机接收带有关于比所提供的计数少的后续片段的信息的媒体片段，那么，客户机可以假设，客户机正在太快地向服务器请求数据。另一方面，如果客户机接收带有关于比所提供的计数多的后续片段的信息的媒体片段，那么，客户机可以假设客户机正在太慢地向服务器请求数据。因而， 响应于任何特定的片段请求，构建清单组件160提供关于与到此刻为止系统100已经接收的一样多后续片段的清单信息。时钟同步组件170同步系统100、客户机和编码器的时钟。尽管绝对时间与系统 100不相关，但能够跨越多个编码器标识特定的片段并向客户机提供请求片段的速率(即节奏)与系统100相关。例如，如果客户机太快地请求数据，则服务器将还没有该数据和将用错误响应(例如，HTTP 404未找到错误响应)来响应，这产生了许多不必要地消费带宽的虚假请求。另一方面，如果客户机太慢地请求数据，那么，客户机可能不能及时地拥有数据以供回放，这在向用户回放的媒体中产生了可察觉的停顿。另外，编码器按照可能显著不同的编码产生媒体片段，且不提供使得在不同编码中表示相同时间周期的两个片段相关的有意义的途径，也不提供各片段位于媒体事件的总时间线中的何处。时钟同步组件170通过允许服务器、编码器和客户机在特定的时间具有相似的时钟值来提供这一信息。各编码器也可以用编码器创建该片段的时间来标记每一媒体片段。以此方式，如果客户机请求特定的片段，则不管客户机选择的编码客户机将获取表示同一时期的片段。在其上实现平滑流传输系统的计算设备可以包括中央处理单元、存储器、输入设备(例如，键盘和指点设备)、输出设备(例如，显示设备)和存储设备(例如，盘驱动器或其他非易失性存储介质)。存储器和存储设备是可以用实现或允许系统的计算机可执行指令(例如，软件)编码的计算机可读存储介质。另外，可经由诸如通信链接上的信号等的数据传输介质存储或传输数据结构和消息结构。可以使用各种通信链接，例如因特网、局域网、广域网、点对点拨号连接、蜂窝式电话网络等等。系统的各实施方式可以在各种操作环境中实现，这些操作环境包括个人计算机、 服务器计算机、手持式或膝上型设备、多处理器系统、基于微处理器的系统、可编程的消费性电子设备、数码相机、网络PC、小型计算机、大型计算机、包括以上的系统或设备中的任何的分布式计算环境等等。计算机系统可以是蜂窝式电话、个人数字助理、智能电话、个人计算机、可编程的消费性电子设备、数码相机等等。可以在诸如由以供或多个计算机或其他设备执行的程序模块等的计算机可执行指令的一般上下文中描述系统。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。通常，在各种实施方式中可以按照期望组合或分布程序模块的功能。如以上所描述地，构建客户机清单组件创建客户机清单。以下是典型的客户机清单的示例。
< xml version=" 1.0" encoding="utf-8" > <!--用表达式编码器版本2.1.1205.0创建--> <SmoothStreamingMedia MajorVersion=" 1" MinorVersion="0"
Duration="6537916781" LookAheadFragmentCount="3“ IsLive="TRUE">〈Streamlndex Type=,'video” Subtype="WVC1" Chunks="327M
Url="QualityLevels( {bitrate} )/Fragments(video= {start time})"> <QualityLevel Bitrate=" 1450000" FourCC=nWVCl" Width="848"
Height="480" CodecPrivateData="..." /> CQualityLevel Bitrate=" 1050000" FourCC=nWVC 1" Width="592"
Height="336" CodecPrivateData="..." /> <c n="0" t=" 12345678" d="20000000" /> <c n="l" t-"32345678" d="20000000" /> <c n="2" t="52345678" d="20000000" /> <c n="3" t="72345678" d="20000000" /> </StreamIndex> </SmoothStreamingMedia>客户机清单列出解码信息以及服务器目前已经归档的所有片段的信息。总的媒体片段数量和持续时间仅是针对直到客户机作出请求时服务器已经归档的媒体片段的 (这允许客户机快速地构建搜索栏)。对于每一媒体片段，“t”意味着绝对时间戳。客户机使用这一值来构成片段URL(例如，“Fragments (video = {start time})(片段(视频 ={开始时间}) ”)。如在此进一步描述，LookAheadFragmentCoimW预期片段计数)指示“TrackFragmentReferenceBox(跟踪片段引用盒子)”将要引用的后续片段的目标数量。 “IsLive (是否实况)”指示实况广播是否仍在进行。在一些实施方式中，在客户机请求特定的媒体片段时，平滑流传输系统提供关于后续媒体片段的信息。例如，服务器可以保留准备好的特定的片段直到一定数量的附加片段(例如，两个片段)可用。然后，服务器可以一起发送该片段与关于接下来的几个片段的清单信息。客户机可以使用这一信息来知道即将到来什么并适当地适应。这允许客户机智能地调整请求率。例如，如果客户机请求一片段且不拥有关于稍后片段的任何信息，那么， 客户机知道它正在太快地请求数据。如果客户机请求一片段且接收到关于太多稍后片段的信息，那么，客户机可能正在太慢地请求信息。因而，客户机可以将超前元数据用作提示来适应。可以使用定制盒子来将关于后续媒体片段的信息存储在MP4容器中。例如，服务器可以借助于以下定义来将“!"rack FragmentReferenceBox”插入到上面示出的‘traf，盒子内盒子类型‘uuid'，{d4807ef2-ca39-4695-8e54-26cb9e46a79f}容器‘traf'强制是数量正好一个
9aligned(8) class TrackFragmentReferenceBox
extends BoxCuuid', {d4807ef2-ca39-4695-8e54-26cb9e46a79f }) {
unsigned int(8) version; bit(24) flags 二 0; unsigned int (8) fragment—count; for(i=l; i * fragment—count; i-H-){ If(Version==I) {
unsigned int(64) fragment_absolute_time; unsigned int(64) fragment—duration; } else {
unsigned int(32) fragment—absolute—time; unsigned int(32) fragment—duration;
}
}
}fragment_COimt (片段计数)指定这一盒子正在引用的同一轨道的后续紧接着的片段的数量。各片段以与它们在MP4流中出现的相同次序列出。这一数量等于或大于1。 fragment_abS0lUte_time(片段绝对时间)指定指示后续片段中的第一样本的绝对时间戳的32位或64位整数。fragment_dUrati0n(片段持续时间)指定指示后续片段的持续时间的 32 位或 64 位整数。(如同在'fragment—count，中)“TrackFragmentReferenceBox，， 盒子中的后续片段的数量是服务器上的可配置的设置。在服务器接收到片段请求时，如果服务器具有如同所配置的值的足够的后续片段来填充“^TrackFragmentReferenceBox”，则服务器可以采用默认的缓存控制设置来遵照正常的响应处理代码路径。如果相反，服务器具有至少一个但没有足够的后续片段来填充 "TrackFragmentReferenceBox",服务器仍然可以用有限的后续片段的信息立即返回该片段响应。服务器可以设置小缓存超时值(取决于片段持续时间)并期待对将来的请求用完整的“ TrackFragmentReferenceBox ”更新响应。对客户机来说，后续片段信息的低量是客户机正在太快地请求数据的提示。如果服务器对于这一轨道不具有任何后续片段，则它可以用指示“片段暂时越界”的特定错误代码来使该请求失败。可在小时间窗口内缓存错误响应。客户机检测到这一错误并在小延迟之后重试相同的请求。一个例外是在实况会话已经停止且服务器正要分发最后的片段时的情况，该情况中将不存在任何后续片段信息，且服务器用最终的流片段响应该请求。图2是阐释在一种实施方式中使用微软Windows和微软因特网信息服务器(IIS) 的平滑流传输系统的操作环境的框图。该环境通常包括源客户机210、内容递送网络240和外部网络270。源客户机是媒体或实况事件的源。源客户机包括媒体源220和一个或多个编码器230。媒体源220可以包括各自提供多个照相机角度的多个照相机、话筒捕捉音频、 幻灯片演示、文本(例如来自隐藏字幕服务)、图像和其他类型的媒体。编码器230以一种或多种编码格式并行地编码来自媒体源220的数据。例如，编码器230可以按照各种比特率产生经编码的媒体。在平滑流传输系统操作的场合，内容递送网络240包括一个或多个摄取服务器 250和一个或多个源服务器沈0。摄取服务器250从编码器230接收按照各种编码格式中的每一种的经编码的媒体，并创建描述经编码的媒体的清单。摄取服务器250可以创建和存储在此描述的媒体片段，或者可以在各片段被请求时在运行中创建片段。摄取服务器250 可以从编码器230例如经由HTTP POST接收推送的数据，或者经由通过请求数据从编码器 230而拉出数据。编码器230和摄取服务器250可以以各种冗余的配置来连接。例如，每一编码器可以将经编码的媒体数据发送给每一摄取服务器250，或者仅发送给一个摄取服务器，直到发生故障。源服务器260是响应对媒体片段的客户机请求的服务器。源服务器 260也可以以各种冗余的配置来配置。在一些实施方式中，摄取服务器250包括致力于摄取编码器媒体流的一个或多个服务器。管理员或内容作者可以创建定义摄取服务器250的客户机可以在其中找到特定媒体元素(例如，实况事件)的URL的发布点。例如，使用IIS，管理员可以发布URL“http:// ingserver/pubpoint. isml”。发布点被编码器230用来将新的媒体数据提供给摄取服务器250，且被源服务器260用来向摄取服务器250请求媒体数据。每一编码器可以使用特异的URL来连接到摄取服务器250，这使得摄取服务器250可以检测相同数据的不同编码。 例如，基于先前的示例中的URL，编码器可以使用URL“http://ingserver/pubpoint. isml/ Streams (streaml) ”来发送HTTP POST以向摄取服务器提供媒体数据。摄取服务器250存储所接收的数据以供摄取服务器250(例如，源服务器沈0)的客户机稍后检索。POST可以包含各种类型的媒体格式，例如MP4容器。MP4容器包含被称为盒子的各种类型的信息，这些盒子通常用四个字母的代码来标记，例如用“ftyp”来描述所使用的编码类型，且用“moov” 来包含视听数据。无论是使用MP4还是其他容器格式，编码器可以向流中添加附加的盒子或信息，例如包含描述媒体元素的清单的“ManifestBox (清单盒子)”。在摄取服务器250接收到对数据的请求时，摄取服务器250提供较早存储的数据。 摄取服务器250可以支持若干类型的请求，包括对标识可用的编码器流的编码器流清单的请求以及对来自具体的流的数据(包括流数据的各部分)的请求。请求的类型可以由请求的URL标识。例如，在摄取服务器250接收到URL "http//ingserver/pubpoint. isml/ StreamManifest"时，摄取服务器250返回包含每一可用的编码器的标识符的编码器清单。 在摄取服务器 250 接收到 URL“http://ingserver/pubpoint. isml/Streams (streaml) ”时， 作为响应，摄取服务器250发送与标识符“Encoderl”相关联的编码器的对应的媒体流。响应可以包括MP4数据，例如以上所描述的所缓存的“ftyp”、“ManifestB0X”和“moov”盒子， 继之以FIFO缓冲器中的媒体片段。摄取服务器250也可以接收形式为“http //ingserver/ pubpoint. isml/Streams (streaml) /StartTime (12345678) ” 的部分数据请求(例如，在故障转移场景期间)，这引起摄取服务器250跳过发送“ftyp”、“ManifestB0X”和“moov”盒子并试图从最接近所指定的时间戳的媒体片段开始。源服务器260从媒体客户机接收对媒体流的请求，并向一个或多个摄取服务器250检索所请求的媒体流。如同摄取服务器250，管理员或内容作者在源服务器上注册发布点，然后将摄取服务器250和/或编码器URL与该发布点关联起来。源服务器260可以首先向摄取服务器250请求(例如，使用HTTP GET请求)描述可用的流的清单。然后，源服务器将对每一编码器流的单独的请求提交给摄取服务器，摄取服务器用从编码器接收的所请求的媒体流来响应。源服务器260可以分开地接收关于媒体流的清单信息和表示正由媒体流提供的较大的媒体元素的各部分的媒体片段。源服务器260基于由每一编码器提供的允许源服务器260使得来自每一编码器的数据相关的时间戳或其他标识符来构建从每一流接收的每一片段的索引。源服务器260可以从所接收的数据构建它们自己的MP4容器或其他存储格式，从中响应媒体客户机请求。通过从实况事件构建已知的格式的文件，源服务器可以在事件之后快速地提供媒体文件的统一下载。在源服务器260接收到媒体客户机请求时，源服务器260通过将服务器已经构建的索引追加到从编码器清单接收到的静态的流信息来生成客户机清单。如果存在多个流， 那么，源服务器260将流清单合并成综合客户机清单。这允许客户机可以选择客户机请求哪种编码类型而无需从源服务器260获得进一步的信息。服务器使用诸如HTTP响应等可以由现有的因特网基础设施缓存的标准响应类型来将清单提供给客户机。因为清单数据可能会随时间改变而改变，服务器可以对清单响应设置短缓存超时值(例如，生存时间(TTL))。外部网络270包括边缘服务器280和其他因特网(或其他网络)基础设施和客户机四0。在客户机作出对媒体片段的请求时，客户机将请求寄送给源服务器沈0。因为网络缓存的设计，如果边缘服务器观0中的一个包含数据，那么，该边缘服务器可以响应客户机而无需传递请求。然而，如果数据在边缘服务器处是不可用的，那么，边缘服务器将请求转发给源服务器沈0中的一个。同样地，如果源服务器沈0中的一个接收到对不可用的数据的请求，则源服务器可以向摄取服务器250中的一个请求数据。图3是阐释在一种实施方式中本发明的系统从编码器接收媒体数据的处理的流程图。在框310开始，系统接收描述系统将对其从一个或多个编码器接收媒体数据的媒体事件的事件注册。例如，事件注册可以包括每一编码器的标识、媒体事件的描述和编码器将向其提供经编码的媒体数据的URL。在框320继续，系统分析传入的流以便获得流清单以及服务器清单，流清单描述系统可以期望的所有编码器流，服务器清单描述流在其中出现的流可用的媒体数据。系统可以使用拉或推模型来操作。例如，系统可以将请求编码器的配置信息的HTTPGET请求发送给编码器，或者系统可以简单地作为流的部分而从编码器接收
““信息。在“推”(例如编码器POST)的情况中，在流的开始将两种清单嵌入在定制盒子中， 因此不需要作出请求，且系统可以解析出清单。在“拉”的情况(例如服务器GET)中，流清单不适用(发布点定义包含等效的信息)，和系统将该信息作为定制盒子而嵌入。流清单被用来指定在将任何数据呈现给下游的服务器和客户机之前服务器从编码器获取的一组流。 在没有流清单时，存在其中服务器已经获取编码器流中的一些但不是全部且下游服务器或客户机获得不完整的景象的竞态条件。在服务器管理员不指定期望什么流的意义上，系统是“自管理的”，因为每一传入的编码器流包含提供这一信息的流清单。在框330继续，系统从每一编码器接收编码器清单。系统将编码器的清单合并在一起，且存储所合并的清单以供对了解该系统可以提供的媒体编码感兴趣的客户机稍后检索。在框340继续，系统从编码器接收媒体片段。媒体片段可以包括时间戳、编码媒体片段的编码器的标识符以及关于媒体片段其他信息。通常不使用编码器标识符，这是因为系统知道该片段在什么流上进来，且具有除流标识符以外的关于哪一编码器生成了流的标识信息。在框350继续，系统索引所接收的媒体片段并将索引信息添加到由系统维护的对来自系统的可用的媒体片段编目的索引表。系统可以使用时间戳与媒体片段相关联的来使得由不同的编码器并行产生的媒体片段相关。在框360继续，系统通过将片段和索引信息存储在数据存储中来归档片段，稍后可以从数据存储中检索片段和索引信息以便满足客户机请求。在框370继续，系统通过将关于所接收的片段的信息添加到服务器清单来构建包括关于媒体片段是其部分的媒体事件的信息的服务器清单。在客户机连接时，服务器将这一清单提供给客户机，以便给予客户机关于当时存在的从系统可用的媒体片段的信息。在事件完成时，服务器清单包含可以被提供给客户机以便用于媒体事件的按需查看的媒体事件的完整描述。在判定框380继续， 如果系统期望来自编码器的更多片段(例如，实况事件仍然在进行)，那么，系统循环到框 340以便接收接下来的编码器片段，否则系统完成。图4是阐释在一种实施方式中本发明的系统操作应对用于流媒体的客户机连接的处理的流程图。在框410开始，系统从客户机接收到清单请求。对于实况事件，许多客户机可以在同一时刻连接，但并不都是在事件的开始时连接。例如，如果媒体片段包含两秒钟的数据，且客户机连接到事件一分钟，则将已经存在可以从系统获得的30个片段。客户机请求初始清单以确定从系统可用的事件的编码(由向系统提供数据的编码器确定)，以及关于当时存在的片段的信息。注意，在服务器和客户机之间的连接是无态的。服务器通常不为具体的客户机贡献任何资源。相反，服务器正在监听任何窜入的请求，每一请求要求具体的片段或其他信息，且服务器响应请求并移到接下来的请求，而不会特别地跟踪对服务器的任何客户机的请求的状态或历史。在框420继续，系统基于所接收的片段和在系统初始请求编码器清单时所接收的编码器信息构建清单以便满足客户机请求。客户机清单包括静态部分和动态部分，静态部分是描述可用的编码的编码器清单中的每一个的并，动态部分描述迄今由服务器从编码器接收的媒体片段。在框430继续，系统响应于客户机请求将所构建的客户机清单提供给客户机。在一些实施方式中，请求是标准HTTP GET请求且响应是HTTP响应(例如，2000K)。 系统可以提供关于响应的缓存寿命，使得在合理的时间量内的后续客户机请求可以由因特网缓存基础设施提供服务。然而，因为清单的动态部分快速地变得陈旧，缓存寿命短到足以避免将给客户机留下太多陈旧清单信息的缓存。基于清单，客户机可以开始以客户机所选择的任何编码来请求片段。例如，客户机可以初始地选择低比特率编码，且对于后续片段选择较高比特率编码，直到网络带宽限制客户机以某一比特率接收片段的能力。在框440继续，系统从客户机接收片段请求。客户机可以通过使用特定的URL来标识该片段。该URL可以标识片段的时间以及编码。例如，该URL可以是“http://server/ event. isml/QualityLevels(1500000)/Fragments(video = 20000000)” 形式的，其中 QualityLevels (质量等级)参数是以每秒比特数来衡量的比特率，video (视频)是正在请求的轨道的名称，且“video =”后面的值是以100纳秒为单位的时间位置(单位的尺度取决于编码演示的方式)。在框450继续，该系统通过从片段数据存储和描述所请求的片段的本地索引表检索清单信息来构建增量清单。系统也可以在此描述的增量清单中包括一个或多个后续片段的清单信息。在框460继续，系统发送包括所请求的媒体片段和所构建的增量清单的对客户机片段请求的响应。基于初始清单和每一增量清单，客户机可以构建包括关于整个媒体事件的信息的本地清单。该清单允许客户机快速地跳过(skip around)和回放媒体事件内的任何位置。在框470继续，系统等待等待接下来的片段请求。在判定框480中继续，如果接收到新的片段请求，那么，系统循环到框440以便处理片段请求，否则系统循环到框470以便继续等待。在框480之后，这些步骤终止。注意，在在此描述的步骤中，平滑流传输不知晓每一客户机的状态且不跟踪客户机的状态。事实上，对于特定的客户机，客户机有可能播放整个媒体事件而从不与系统对话。这是可能的，因为客户机可以从遍布网络的缓存服务器接收每一所请求的清单和媒体片段。客户机基于各种因素，诸如基于客户机观察到的网络条件的期望比特率或基于用户与客户机显示的控件交互的期望位置(例如，快进、查找、倒带等等)等请求它们想要的数据。这允许服务器将资源聚焦在其他任务上，且引人注目地增加可伸缩性。对于有很多人参加的实况事件，这意味着多得多的观众可以观看该事件。图5是阐释在一种实施方式中从编码器到源服务器到客户机的媒体片段的流的数据流程图。编码器505直接地或通过在此描述的摄取服务器来连续地将媒体数据520提供给源服务器510。例如，媒体数据可以包括基于实况事件的MP4流的片段。源服务器510 归档525每一媒体片段，例如归档到本地数据存储。源服务器510接收从客户机515清单请求530。源服务器510基于最新的媒体片段信息生成535客户机清单。源服务器510将客户机清单响应540提供给客户机515。然后，客户机515发送一个或多个媒体片段请求M5， 且源服务器510用所请求的媒体片段和潜在地关于后续媒体片段的信息来响应550。只要媒体事件正在发生且编码器505正在提供新的媒体数据，该图的左边的数据流就继续。只要客户机515正在请求媒体片段(这可以发生在媒体事件期间以及在事件之后在客户机请求媒体事件的按需查看时)，该图右边的数据流就继续。在一些实施方式中，平滑流传输系统为实况媒体流提供类似数字录像机(DVR)的功能。换句话说，用户可以暂停实况流，在实况流内查找等等，而无需为服务器增加工作或状态跟踪。在实况流中，存在系统允许的若干场景，比如错过的景物、暂停以便休息、后来加入事件并打算从开始观看等等，这允许用户以各种顺序和在各种时刻播放媒体片段。基于在此描述的组合的清单，系统提供用于他们如何观看实况流的用户控件。今天这些控件借助于电视机经由数字录像机可用。平滑流传输系统包括响应用户动作和通过查找清单中的各种位置并请求适当的媒体片段来以非实况模式管理实况流的回放的客户机控件。另外， 在回放期间，客户机可以在实况查看和非实况查看之间切换。在一些实施方式中，平滑流传输系统通过向客户机提供web浏览器插件来操作。 例如，系统可以向客户机提供微软Silverlight应用程序。微软Silverlight接收web页面中对被包含在被称为XAP文件的容器中的应用程序的引用。微软Silverlight提取出XAP 文件并调用该应用程序。微软Silverlight向应用程序提供在其中运行的沙箱化的安全环境，使得针对恶意的或错误的应用程序代码保护用户的计算机系统。微软Silverlight提供应用程序编程界面(API)，应用程序可以调用该API来以针对潜在地有害的应用程序动作保护用户的计算机系统和硬件的方式回放媒体。因而，微软Silverlight和其他浏览器插件可以提供平滑流传输系统期望在其中操作的客户机环境的全部功能。在一些实施方式中，平滑流传输系统提供用于同步相关的媒体流的逻辑。例如，实况视听事件可以包括一个或多个视频流(例如，照相机角度)和一个或多个音频流(例如， 语言)。由于客户机分开地下载音频和视频媒体片段，客户机通过对齐与每一媒体片段相关联的时间信息来同步播放音频和视频媒体内容，如再次参考时钟同步所进一步描述的。系统也可以同步其他类型的数据，例如在幻灯片演示中的幻灯片、图像、文本等等。在一些实施方式中，平滑流传输系统将以不同速率播放的流提供给客户机。例如， 服务器可以包括h、5x、0. 5x和其他回放速度。客户机可以切换到不同速率的流以便向用户提供媒体快进(例如，2x)或倒带(例如，0.5x)的外观。为了交换，客户机例如以特异的 URL简单地请求不同的媒体片段。客户机可以通过继续播放所接收到的特定的媒体片段来在以当前速率播放媒体片段和以不同速率播放媒体片段之间平滑切换。这向最终用户提供了提供无缝体验，在用户的请求和媒体回放的改变之间的等待时间很小。由于客户机不下载例如两次数据以便以两倍快速来播放媒体，而是下载以加速速率编码的大小减小的媒体编码，这也节省了网络带宽。在一些实施方式中，平滑流传输系统在元数据中提供突出显示标记。突出显示可以包括任何感兴趣的媒体的片段，例如在运动事件期间在运动员进球的时刻。客户机可以通过播放带有相关联的突出显示标记的媒体的那些媒体片段在事件已经结束之后来播放集锦。如果客户机没有接收到实况事件，则客户机可以请求该媒体的清单，且然后，仅请求对应于突出显示的那些媒体片段。如果用户想要观看突出显示之前和之后的更多的媒体 (例如，如由用户快进或倒带所指示的)，那么，客户机可以请求附加的媒体片段以便播放媒体的所请求的部分。因而，系统可以在清单中为客户机提供突出显示信息。在一些实施方式中，平滑流传输系统支持内嵌广告。对于实况事件，在事件的开始，不知道商业广告片何时将要发生。事件协调员可以在生产期间在广告时间按压一按钮， 这引起系统在媒体流元数据中插入广告标记。在客户机接收到广告标记时，客户机可以请求和接收与先前所标识的广告相关联的媒体片段。例如，系统可以在初始清单中提供潜在的广告的列表。可以类似于其他媒体在媒体片段中提供广告，且可以不将其存储在提供实况事件的同一服务器。一旦遇到广告标记，客户机就暂停主流的回放，检索和显示广告，且然后，恢复主流的回放。在一些实施方式中，平滑流传输系统基于订阅或其他支付模型确定哪些编码可用。例如，内容供应商可以对实况事件的高清晰度(HD)版本收取比事件的标准清晰度(SD) 版本更高的费用。在这一情况中，系统可以基于支付模型的各条件是否已经得到满足(例如，用户的账户是流通的)来启用或禁用切换到特定的比特率。这一信息可以被包括在被提供给客户机的清单中。内容供应商可以免费提供一些编码，例如低的比特率或仅突出显示的媒体，同时对其他收费。在一些实施方式中，平滑流传输系统为系统的各种组件提供故障转移。例如，系统可以包括冗余的编码器、摄取服务器、源服务器等等。在编码器故障转移期间，服务器可以将“MartTime (开始时间)(rmrm) ”追加到编码器URL，其中“rmrm”是服务器成功地接收到的最后的片段的绝对时间戳。故障转移URL的一个示例是“http://enC0der:p0rt/ StartTime (12345678) ”。在使用MP4盒子时，在后备编码器开始流传输时，后备编码器不需要再次发送“ftyp”、“ManifestB0X”和“moov”盒子。如果编码器故障转移引起丢失片段， 如果那些片段被客户机请求，则服务器将返回“404-文件未找到”。 从前述应明白，已经出于阐释的目的在此描述平滑流传输系统具体的实施方式， 但可以在不偏离本发明的精神和范围的前提下做出各种修改。例如，尽管在各示例中使用了视听数据，但可以与系统一起使用的其他类型的数据包括文本(例如，流传输股票报价)、幻灯片(例如，演示)等等。因此，除了所附权利要求之外，本发明不受其他限制。
权利要求
1.一种用于从服务器向客户机提供流媒体的计算机实现方法，所述方法包括从所述客户机接收410清单请求；基于所述服务器已经接收的媒体片段和编码器信息构建420客户机清单以便满足所述客户机请求；响应于所述清单请求，将所构建的客户机清单提供430给所述客户机；从客户机接收440标识特定的媒体片段的片段请求；通过检索描述所请求的媒体片段的清单信息来构建450增量清单；发送460包括所请求的媒体片段和所构建的增量清单的对所述客户机片段请求的响应；其中，所述前述步骤由至少一个处理器执行，且其中所述服务器将媒体片段提供给多个客户机且无需存储关于所述客户机中的每一个的状态信息。
2.如权利要求1所述的方法，其特征在于，所述清单请求确定从所述服务器可用的事件的一种或多种编码以及关于与所述事件相关的现有的媒体片段的信息，其中所述可用编码包括与所述事件相关联的多种比特率的媒体，客户机可以在回放期间在任何时刻在所述多种比特率的媒体之间选择。
3.如权利要求1所述的方法，其特征在于，构建客户机清单包括从每一编码器解析服务器清单并将所接收的编码器清单合并到所述客户机清单。
4.如权利要求1所述的方法，其特征在于，所述客户机清单包括静态部分和动态部分， 静态部分是描述所述可用的编码的多个编码器清单中的每一个的并，动态部分描述到所述请求的时刻为止由所述服务器从多个编码器接收的媒体片段，且其中所述客户机可以通过基于所述客户机清单请求一个或多个具体的媒体片段来开始回放和响应于查找。
5.如权利要求1所述的方法，其特征在于，提供所述客户机清单包括发送可缓存的 HTTP响应，且其中所述可缓存的HTTP响应包括基于服务器提供的所述客户机清单的寿命的缓存寿命。
6.如权利要求1所述的方法，其特征在于，所述客户机可以基于所述客户机清单开始请求多种编码中的一种的片段，且其中所述客户机可以基于一个或多个检测到的条件初始地选择第一低比特率编码并稍后请求以较高比特率的片段。
7.如权利要求1所述的方法，其特征在于，所述片段请求通过包括标识与所述片段相关联的时间以及与所述片段相关联的编码的特异的统一资源定位符(URL)来标识特定的片段。
8.如权利要求1所述的方法，其特征在于，构建增量清单包括包含关于在所请求的媒体片段之后的一个或多个媒体片段的信息。
9.如权利要求1所述的方法，其特征在于，所述初始清单和所述增量清单允许所述客户机构建包括关于完整的媒体事件的信息的本地清单并跳过和回放所述媒体事件内的任何位置。
10.一种用于递送可缓存的流媒体演示的计算机系统，所述系统包括处理器和存储器，其被配置为执行软件指令；注册事件组件110，其被配置为接收关于所述系统将对其接收经编码的媒体数据的实况媒体事件的信息；编码器接口组件120，其被配置为在所述系统和作为媒体片段提供所述经编码的媒体数据的一个或多个编码器之间提供接口；索引片段组件130，其被配置为创建和维护从编码器接收到的媒体片段的索引表；片段数据存储140，其被配置为存储所接收的媒体片段和所创建的片段的索引表以便基于所接收的客户机请求提供给客户机；客户机接口组件150，其被配置为接收对媒体片段的客户机请求并将清单数据和媒体片段提供给客户机；构建客户机清单组件160，其被配置为构建包括关于从所述系统可用的所述编码中的每一种和到所述请求的时间为止由所述系统存储的片段的信息的清单以便满足客户机请求；以及时钟同步组件170，其被配置为同步所述系统、客户机和编码器的时钟。
11.如权利要求10所述的系统，其特征在于，所述注册事件组件还被配置为接收将向所述提供提供经编码的媒体数据的多个编码器中的每一个的标识符。
12.如权利要求10所述的系统，其特征在于，所述编码器接口组件接收包括用于媒体信息和媒体元数据的盒子在内的媒体容器中的经编码的媒体数据。
13.如权利要求10所述的系统，其特征在于，所述客户机接口组件还被配置为从连接到所述系统的客户机接收初始清单请求、调用所述构建客户机清单组件来基于所述索引表创建包括关于从所述系统可用的所述编码和到当前时间为止由所述系统存储的片段的信息的客户机清单、并且将所述客户机清单提供给所述客户机。
14.如权利要求10所述的系统，其特征在于，所述构建客户机清单组件还被配置为提供增量清单以便与每一所请求的媒体片段包括在一起，其中所述增量清单将关于所述当前的媒体片段以及至少一个后续媒体片段的信息提供给所述客户机。
15.如权利要求10所述的系统，其特征在于，所述构建客户机清单组件还被配置为向所述客户机提供所述客户机对每一媒体片段期望的后续片段的计数，作为所述客户机的计时提示。
全文摘要
平滑流传输系统在客户机和服务器之间提供无态协议，其中服务器将增量控制信息嵌入在媒体片段中。服务器提供可由现有的因特网缓存基础设施缓存的对媒体片段请求的统一媒体片段响应。平滑流传输系统从一个或多个编码器接收以片段为单位的媒体数据、创建每一片段的索引并存储各片段。服务器将包含描述服务器上可用的编码和片段的编码的元数据信息的各片段提供给客户机。服务器也可以在每一片段内提供允许客户机判断该客户机是否正在太快地或太慢地请求数据的信息，这使得客户机可以使其请求速率适应与服务器接收编码器数据的速率协调的节奏。
文档编号H04L7/00GK102356622SQ201080012748
公开日2012年2月15日 申请日期2010年3月9日 优先权日2009年3月16日
发明者A·罗伊, C·G·诺尔顿, G(萨姆)·张, J·A·博恰罗夫, J·E·弗里兰德, J·高, K·P·杜格拉居, L·刘, S·西里瓦纳, V·苏德 申请人:微软公司