平滑、无状态的客户端媒体流式传输的制作方法

专利名称：平滑、无状态的客户端媒体流式传输的制作方法
平滑、无状态的客户端媒体流式传输
背景技术：
流媒体是在被(使用服务器的)流式传输提供者递送时持续地由(使用客户端的)最终用户接收并且通常被呈现给最终用户的多媒体。存在若干用于流媒体的协议，包括实时流式传输协议(RTSP)、实时传输协议(RTP)、以及实时传输控制协议(RTCP)，这些流式传输应用常常一起使用。由因特网工程任务组(IETF)于1998年作为评定要求文件 (RFC) 2326开发并创建的实时流式传输协议(RTSP)是供用在流媒体系统中的协议，该协议允许客户端远程控制流媒体服务器，发出诸如“播放”和“暂停”之类的类似于VCR的命令并且允许对服务器上的文件进行基于时间的访问。流数据本身的发送不是RTSP协议的一部分。大多数RTSP服务器都将基于标准的 RTP用作用于实际音频/视频数据的传输协议，其从某种程度上而言充当元数据通道。RTP 定义标准化的分组格式以用于通过因特网递送音频和视频。RTP是由IETF的音频视频传输工作组开发并于1996年作为RFC 1889首次发布的，并且于2003年被RFC 3550取代。 该协议在句法和操作方面类似于超文本传输协议(HTTP)，但是RTSP添加了新的请求。尽管HTTP是无状态的，但是RTSP是有状态的协议。RTSP在需要时使用会话ID来跟踪会话。 RTSP消息被从客户端发送给服务器，但是在服务器将把消息发送给客户端的情况下存在一些例外。流式传输应用常常结合RTCP使用RTP。RTP运送媒体流(例如音频和视频)或者带外信令(双音多频(DTMF))，而流式传输应用使用RTCP来监控传输统计数据和服务质量 (QoS)信息。RTP仅仅允许一种类型的消息、即将数据从源运送到目的地的消息。在许多情况下，在会话中需要其他消息。这些消息控制数据的流量和质量并且允许接收者向一个或多个源发送反馈。RTCP是为该目的设计的协议。RTCP具有五种类型的消息发送方报告、 接收方报告、源描述消息、bye (再见)消息以及应用专用消息。RTCP在对多媒体数据进行递送和打包时为RTP流以及RTP的伙伴提供带外控制信息，但是不传输任何数据本身。流式传输应用使用RTCP周期性地在流媒体会话中将控制分组传输给参与者。RTCP的一个功能是提供对RTP所提供的服务的质量的反馈。RTCP收集诸如发送的字节、发送的分组、丢失的分组、抖动、反馈以及往返延迟之类的关于媒体连接和信息的统计数据。应用可以使用该信息来提高服务质量(可能通过限制流量或者使用不同的编解码器或比特率)。现有媒体流式传输架构的一个问题是服务器与客户端之间的紧密耦合。客户端与服务器之间的有状态的连接造成了附加的服务器开销，因为服务器跟踪每个客户端的当前状态。这还限制了服务器的伸缩性。另外，客户端不能快速地对诸如下列改变的条件作出反应增加的分组丢失；减少的带宽；用户请求不同的内容或者修改现有内容(例如加速或倒带)等等，而不是首先与服务器通信并且等待服务器进行调整和响应。常常在客户端(例如通过RTCP)报告较低的可用带宽时，服务器不够快速地进行调整，从而在超过可用带宽的分组不被接收并且新的较低比特率分组未及时地从服务器发送时导致客户端上的用户注意到媒体的中断。为了避免这些问题，客户端常常缓冲数据，但是缓冲引入了等待时间， 等待时间对于实况事件而言可能是不可接受的。
4
另外，因特网包含许多类型的可下载的媒体内容项目，包括音频、视频、文档等等。 这些内容项目常常非常大，比如几百兆字节的视频。用户常常通过web浏览器使用HTTP在因特网上检索文档。因特网已经建立了路由器和代理的大的基础结构，这些路由器和代理有效地对数据进行高速缓存以用于HTTP。服务器可以以较少的延迟并且通过使用与从原始来源重新请求内容相比更少的资源来向客户端提供经高速缓存的数据。例如，纽约的用户可以下载从日本的主机所服务的内容项目，并且通过加利福尼亚的路由器接收该内容项目。如果新泽西的用户请求相同的文件，则加利福尼亚的路由器可能能够提供该内容项目， 而不必再次从日本的主机请求该数据。这减少了可能通过紧张的路由的网络通信量，并且允许新泽西的用户以较少的延迟接收该内容项目。遗憾的是，实况媒体常常不能使用现有协议来高速缓存，并且每个客户端都从相同的服务器或服务器组请求媒体。另外，当流媒体可以被高速缓存时，常常涉及专用高速缓存硬件，而不是现有和易于获得的基于HTTP的因特网高速缓存基础结构。高速缓存的缺乏限制了并发观众的数目、以及服务器能够处理的请求的数目，并且限制了实况事件的出席。 世界上越来越多使用因特网来消费最新的实况信息，比如通过因特网观看诸如2008奥林匹克运动会开幕式之类的实况事件的创纪录的用户数目。当前技术的局限性正在减缓将因特网用作用于消费这种类型的媒体内容的介质。

发明内容
在此描述了一种自适应流式传输系统，其提供客户端与服务器之间的用于流媒体回放的无状态连接，其中数据被格式化为使得允许客户端作出在传统上由服务器进行的决策，并且因此更快速地对改变的网络条件作出反应。客户端向包括媒体的一部分的服务器请求统一的媒体块。自适应流式传输系统以小尺寸块来请求媒体文件或实况流式传输事件的部分，所述小尺寸块每个都具有相区别的URL。这允许现有因特网高速缓存基础结构对流媒体进行高速缓存，由此允许更多客户端在大致相同的时间观看相同内容。随着事件进展， 客户端继续请求块，直到事件或媒体结束。每个块都包含描述该块的编码的元数据信息以及供客户端回放的媒体内容。服务器可以提供多种编码的块，使得客户端可以快速地切换到不同比特率或回放速度的块。因此，自适应流式传输系统向用户提供以下改善的体验在流媒体回放中更少的中断，以及客户端将以更低的等待时间从更加本地的高速缓存服务器接收媒体的增加的可能性。提供本概述以便以简化形式介绍在以下详细描述中进一步描述的一些概念。本发明内容并不旨在标识所要求保护主题的关键特征或必要特征，也不旨在用于限制所要求保护主题的范围。


图1是示出在一个实施例中的自适应流式传输系统的各组件的框图。图2是示出在一个实施例中的使用Microsoft Windows和IIS的平滑流式传输系统的操作环境的框图。图3是示出一个实施例中的在客户端上回放媒体的自适应流式传输系统的处理的流程图。
图4是示出一个实施例中的处理单个媒体块的自适应流式传输系统的处理的流程图。
具体实施例方式在此描述了一种自适应流式传输系统，其提供客户端与服务器之间的用于流媒体回放的无状态连接，其中数据被格式化为使得允许客户端作出在过去的协议中常常留给服务器作出的决策，并且因此更快速地对改变的网络条件作出反应。另外，自适应流式传输系统以允许现有因特网缓存基础结构高速缓存流媒体数据的方式运行，由此允许更多的客户端在大致相同的时间观看相同内容。自适应流式传输系统以小尺寸块来请求媒体文件或实况流式传输事件的部分，所述小尺寸块每个都具有相区别的URL。每个块可以自身是媒体文件，或者可以是整个媒体文件的一部分。随着事件进展，客户端继续请求块，直到事件结束。每个块都包含描述该块的编码的元数据信息以及供客户端回放的媒体内容。服务器可以提供多种编码的块，使得客户端例如可以快速地切换到不同比特率或回放速度的块。由于块依附于万维网联盟(W3C)HTTP标准，因此块小得足以被高速缓存，并且系统以相同方式向每个客户端提供块，所述块自然地由被现有因特网基础结构来高速缓存而不必进行修改。因此，自适应流式传输系统向用户提供以下改善的体验在流媒体回放中更少的中断， 以及客户端将以更低的等待时间从更加本地的高速缓存服务器接收媒体的增加的可能性。 由于客户端与服务器之间的连接是无状态的，因此在长事件的持续时间内不必连接相同的客户端和服务器。在此所述的无状态系统不具有服务器亲和力，从而允许客户端拼凑来自已经在不同时间开始的服务器的清单，并且还允许服务器管理员按照负载规定开启或关闭原始服务器。在一些实施例中，自适应流式传输系统在服务器与客户端之间使用新的数据传输格式。客户端向包括媒体的一部分的服务器请求媒体块。例如，对于10分钟的文件而言，客户端可以请求2秒的块。注意，不同于服务器将数据推送给客户端的典型流式传输，在这种情况下，客户端从服务器拉取媒体块。在实况流的情况下，服务器可以在进行中创建媒体， 并且产生块来响应客户端请求。因此，根据服务器多快地创建块以及客户端多快地请求块， 客户端可以仅仅落后于服务器若干块。每个块都包含元数据和媒体内容。元数据可以描述诸如下列关于媒体内容的有用信息媒体内容的比特率；媒体内容被放入到较大的媒体元素中的何处(例如该块表示10 分钟的视频剪辑中的偏移量1 10)；用于对媒体内容进行编码的编解码器等等。客户端使用该信息将块放置到较大的媒体元素的故事板中并且合适地对媒体内容进行解码和回放。图1是示出在一个实施例中的自适应流式传输系统的各组件的框图。自适应流式传输系统100包括块请求组件110、块解析组件120、清单组装组件130、媒体回放组件140、 QoS监控组件150、以及时钟同步组件160。此处更详细地描述了这些组件中的每一个。在此所述的自适应流式传输系统100主要在客户端计算机系统处运行。然而，本领域的普通技术人员能够认识到，该系统的各个组件可以放置在内容网络环境内的各个位置处以提供特定的积极结果。块请求组件110作出客户端对来自服务器的各个媒体块的请求。如图2所示，客户端的请求可以首先经过边缘服务器(例如因特网高速缓存)，然后经过原始服务器，并且然后经过摄取服务器。在每个阶段，如果所请求的数据被找到，则请求不进行到下一等级。 例如，如果边缘服务器具有所请求的数据，则客户端从边缘服务器接收该数据，并且原始服务器不接收该请求。每个块都具有个别化地标识出该块的统一资源定位符(URL)。因特网高速缓存服务器擅长于高速缓存对特定URL请求(例如HTTP GET)的服务器响应。因此， 当第一客户端接通到服务器以获取块时，边缘服务器高速缓存该块，并且请求该同一块的后续客户端可以从边缘服务器接收该块(基于高速缓存的寿命和服务器存活时间(TTL)设定)。块请求组件110接收块并且将其传递给块解析组件120以用于解释。块解析组件120解释由块请求组件110接收的媒体块的格式，并且将块分成其组分部分。通常，块包括含有元数据的报头部分、以及含有媒体内容的数据部分。块解析组件将元数据提供给清单组装组件130，并且将媒体内容提供给媒体回放组件140。清单组装组件130构建描述所接收的媒体内容所属的媒体元素的清单。由客户端整体下载(例如未流式传输)的大媒体文件常常包括清单，该清单描述整个文件、用于对文件的各个部分进行编码的编解码器和比特率、关于文件内的有意义的部分的标记等等。在尤其时流式传输实况内容期间，服务器不能提供完整的清单，因为事件还在继续进行。因此，服务器通过媒体块中的元数据提供其所能提供的清单那样多的清单。服务器还可以提供诸如预定义URL之类的应用编程接口(API)以供客户端请求直到媒体流中的当前点的清单。这在客户端在事件已经进展以后加入实况流式传输事件时可能是有用的。清单允许客户端请求媒体元素的之前被流式传输的部分(例如通过倒带)，并且客户端通过被流式传输的媒体块的元数据继续接收清单的新的部分。清单组装组件130构建与对完整媒体文件可用的清单类似的清单。因此，随着事件进行，如果用户想要在媒体中向后跳转(例如倒带或跳转到特定的位置)，然后再次向前跳转，则用户可以这样做并且客户端使用经组装的清单来找出合适的一个块或多个块以向用户回放。当用户暂停时，系统100可以继续接收媒体块(或者基于相区别的请求URL仅仅接收块的元数据部分)，使得清单组装组件130可以继续构建清单并且在用户结束暂停以后为任何用户请求做好准备(例如跳转到当前的实况位置或者从暂停位置播放)。客户端侧经组装的清单允许客户端在媒体事件一结束就将该事件作为点播内容进行回放，以及在媒体事件进行时在媒体事件的范围内跳转。媒体回放组件140使用客户端硬件来回放所接收的媒体内容。媒体回放组件140 可以调用一个或多个编解码器来解释在其内部的媒体内容被传输的容器并且将媒体内容从经压缩的格式解压缩或以其他方式解码成原始格式(例如YV12、RGBA或者PCM音频采样)。媒体回放组件140然后可以将原始格式媒体内容提供给操作系统API (例如Microsoft DirectX)以供在诸如显示器和扬声器之类的本地计算机系统声音和视频硬件上回放。QoS监控组件150分析从服务器接收分组的成功，并且基于一组当前网络和其他条件调整客户端的请求。例如，如果客户端按照惯例延迟地接收媒体块，则组件150可以确定客户端与服务器之间的带宽对于当前的比特率而言不够，并且客户端可以开始请求较低比特率的媒体块。QoS监控可以包括其他试探法的测量，比如呈现帧速、窗口大小、缓冲器大小、重新缓冲的频率等等。每种比特率的媒体块都可以具有相区别的URL，使得各种比特率的块都由因特网高速缓存基础结构来高速缓存。注意，服务器不跟踪客户端状态并且不知道任何特定客户端当前正在以何种比特率播放。服务器可以简单地提供各种比特率的相同的媒体元素以满足在一定范围的条件下的潜在客户请求。另外，客户端所接收的初始清单和/或元数据可以包括关于从服务器可用的比特率和其他编码性质的信息，使得客户端可以选择将提供良好的客户端体验的编码。注意，当切换比特率时，客户端可以简单地开始请求新的比特率并且在客户端接收到块时回放新的比特率块。客户端不必向服务器发送控制信息并且等待服务器调整流。 客户端的请求甚至可以由于客户端与服务器之间的满足该请求的高速缓存而不到达服务器。因此，客户端比常规媒体流式传输系统中的客户端快得多地作出反应，并且服务器上具有在各种当前条件下所连接的不同客户端的负担显著减小。另外，由于当前条件往往是局部化的，因此可能的是，处于特定地理区域中或者特定因特网服务提供商(ISP)上的许多客户端将体验类似的条件并且将请求类似的媒体编码(例如比特率)。由于高速缓存往往也是局部化的，因此可能的是特定情况下的客户端将感到它们附近的高速缓存“新鲜地”具有他们各自请求的数据，使得由每个客户端体验到的等待时间将是少的。时钟同步组件160同步服务器和客户端的时钟。尽管绝对时间与客户端和服务器在大体上是不相关的，但是能够标识出特定的块以及知道请求块的速率(例如节奏)是与客户端相关的。例如，如果客户端过快地请求数据，则服务器将还不具有该数据，并且将以错误响应作出响应(例如HTTP 404未找到错误响应)，从而造成许多不必要地消耗带宽的虚假请求。另一方面，如果客户端过慢地请求数据，则客户端不能及时地具有数据以供回放，从而造成向用户回放的媒体中的可察觉的中断。因此，在客户端知道服务器产生新块的速率并且知道当前块被放入到总体时间线中的何处时，客户端和服务器良好地工作。时钟同步组件160通过允许服务器和客户端在特定时间具有相似时钟值来提供该信息。服务器还可以用服务器创建每个媒体块的时间来标记每个媒体块。时钟同步还给予服务器跨每个编码器的公共参考。例如，服务器可以同时以多种比特率并且使用多种编解码器对数据进行编码。每个编码器都可以以不同方式引用经编码数据，但是时间戳可以以跨所有编码器被设置为通用。通过这种方式，如果客户端请求特定的块，则无论客户端选择何种编码，该客户端都将获得表示相同时间段的媒体。在其上面实现了系统的计算设备可包括中央处理单元、存储器、输入设备(例如， 键盘和指示设备)、输出设备(例如，显示设备)，以及存储设备(例如，磁盘驱动器或其他非易失性存储介质)。存储器和存储设备是可以编码有实现或启用系统的计算机可执行指令(例如，软件)的计算机可读的存储介质。另外，数据结构和消息结构可以被存储或通过诸如通信链路上的信号之类的数据传输介质传输。可以使用各种通信链路，如因特网、局域网、广域网、点对点拨号连接、蜂窝电话网络等等。系统的各实施例可以在各种操作环境中实现，操作环境包括个人计算机、服务器计算机、手持式或膝上型设备、多处理器系统、基于微处理器的系统、可编程消费电子产品、 数码相机、网络PC、小型计算机、大型计算机、包括上述系统或设备中的任一个的分布式计算机环境等。计算机系统可以是蜂窝电话、个人数字助理、智能电话、个人计算机、可编程消费电子产品、数码相机等等。可以在由一台或多台计算机或其他设备执行的诸如程序模块之类的计算机可执行的指令的一般上下文中来描述本系统。一般而言，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。通常，程序模块的功能可以按需在各个实施例中进行组合或分布。图2是示出在一个实施例中的使用Microsoft Windows和IIS的平滑流式传输系统的操作环境的框图。该环境通常包括源客户端210、内容递送网络M0、以及外部网络 270。源客户端是媒体或实况事件的源。源客户端包括媒体源220和一个或多个编码器230。 媒体源220可以包括相机，这些相机每个都提供多个相机角度；麦克风捕获音频；幻灯片呈现；文本(比如来自隐藏字幕服务)；图像；以及其他类型的媒体。编码器230并行地以一种或多种编码格式对来自媒体源220的数据进行编码。例如，编码器230可以产生多种比特率的经编码的媒体。内容递送网络240包括一个或多个摄取服务器250和一个或多个原始服务器260。 摄取服务器250从编码器230接收每种编码格式的经编码媒体，并且创建描述经编码媒体的清单。摄取服务器250可以创建和存储在此所述的媒体块，或可以在块被请求时在进行中创建块。摄取服务器250可以比如通过HTTP POST从编码器230、或者经由拉取通过请求数据从编码器230接收推送的数据。编码器230和摄取服务器250可以以多种冗余配置来连接。例如，每个编码器都可以将经编码媒体数据发送给每个摄取服务器250或者仅仅发送给一个摄取服务器直到发生故障。原始服务器260是响应于对媒体块的客户端请求的服务器。原始服务器260也可以以多种冗余配置来配置。外部网络270包括边缘服务器280和其他因特网(或者其他网络)基础结构和客户端四0。当客户端作出对媒体块的请求时，客户端向原始服务器260提出该请求。由于网络高速缓存的设计，如果边缘服务器280之一包含该数据，则该边缘服务器可以响应于客户端而不必传递该请求。然而，如果数据在边缘服务器处不可用，则边缘服务器将该请求转发给原始服务器260之一。同样，如果原始服务器260之一接收到对不可用数据的请求，则该原始服务器可以向摄取服务器250之一请求该数据。图3是示出一个实施例中的在客户端上回放媒体的自适应流式传输系统的处理的流程图。始于框310，该系统选择以此从服务器请求经编码媒体的初始编码。例如，系统可以最初选择最低可用的比特率。该系统可能之前已经向服务器发送了请求以发现可用的比特率以及其他可用编码。在框320继续，系统请求和播放特定的媒体块，这将参考图4予以进一步描述。在框330中继续，该系统基于所请求的块确定服务质量度量。例如，块可能包括针对服务器当前存储的块那样多的附加块的元数据，这些块可以被客户端用于确定客户端相对于服务器多快地产生块而言多快地请求块。该过程在此处更详细地描述。在决策框340中继续，如果系统确定当前QoS度量过低并且到服务器的客户端连接不能处理当前编码，则系统在框350继续，否则系统循环到框320以处理下一块。在框350中继续，系统选择媒体的不同编码，其中系统通过从不同URL请求数据来为来自服务器的随后的块选择不同的编码。例如，系统可以选择消耗当前编码的一半带宽的编码。同样，系统可以确定QoS度量指示客户端可以处理更高比特率编码，并且客户端可以为随后的块请求更高的比特率。通过这种方式，客户端基于当前条件向上和向下调节比特率。尽管图3将QoS确定示为发生在每个块之后，但是本领域的普通技术人员将认识到，其他QoS实施方式是普遍的，比如等待固定数目的分组或块(例如每10个分组)以作出QoS确定。在框350之后，系统在有块可用的情况下循环到320以处理下一块，或者在没有另外的媒体可用的情况下结束(未示出)。
图4是示出一个实施例中的处理单个媒体块的自适应流式传输系统的处理的流程图。在框410中继续，系统基于所选的初始比特率通过网络将对块的请求从客户端发送给服务器。例如，系统可以基于所选编码选择请求数据的特定URL (例如http //server/ a. isml/quality/bitrate)。在框420中继续，系统在客户端处接收所请求的块。系统可以从服务器或者从网络上的处于服务器与客户端之间的高速缓存接收块。在框430中继续， 系统将块解析成元数据部分和媒体数据部分。例如，每个块都可以包含描述块的编码的元数据以及适于使用编解码器和合适硬件进行回放的媒体数据。在框440中继续，系统将块元数据添加到正在进行的媒体清单中，该清单描述关于每个媒体数据块所属的较大的媒体元素的信息。例如，系统可以在存储器中存储包含来自每个媒体文件块的元数据的清单。在框450中继续，系统使用由块元数据和客户端的硬件所标识出的编解码器来播放媒体数据。媒体数据可以包括视频、音频、以及系统在包括显示器、扬声器等等在内的硬件上回放的其他类型的数据。可替代地或附加地，该数据可以包括与回放不同的方式被消费的非视听数据(例如文本)，在这种情况下，该系统基于数据的类型作用于数据。在框450之后，这些步骤结束。在一些实施例中，自适应流式传输系统为实况媒体流提供类似于数字录像机 (DVR)的功能。换言之，用户可以暂停实况流，在实况流内查找等等，而不必给服务器增添工作或状态跟踪。在实况流中，存在诸如错过画面、暂停以中断、在后期加入事件、打算从开始观看等等的若干情景，这些情景由该系统来实现，从而允许用户以各种顺序以及在各个时间播放块。基于在此所述的经组装的清单，系统向用户提供对他们如何观看实况流的控制。如今，这些控制在电视的情况下通过DVR可用。自适应流式传输系统包括客户端控制来在非实况模式下通过尝试清单中的各个位置而响应于用户动作以及管理实况流的回放。 另外，客户端可以在回放期间在实况与非实况观看之间切换。在一些实施例中，自适应流式传输系统在web浏览器插件内运行。例如，该系统可以包括在Microsoft Silverlight应用中。Microsoft Silverlight接收网页中对包含在称为XAP文件的容器中的应用的引用。Microsoft Silverlight提取XAP文件并且调用该应用。Microsoft Silverlight给应用提供沙箱中(sandboxed)的安全环境以在其中运行， 使得用户的计算机系统被保护免受恶意或错误应用代码损害。Microsoft Silverlight提供如下的API 所述API可以由应用以保护用户的计算机和硬件免受潜在有害的应用动作损害的方式来调用来回放媒体。因此，Microsoft Silverlight和其他浏览器插件可以提供自适应流式传输系统预期运行在其内的环境的所有功能。在一些实施例中，自适应流式传输系统在当前块中接收之后的块的元数据。例如， 服务器可以保持准备好的特定块直到一定数目的附加块(例如两个块)可用。然后，服务器可以将该块与关于接下来几个块的元数据信息一起发送。客户端可以使用这些信息来得知什么将要到来并且合适地进行调整。这允许客户端智能地调节请求速率。例如，如果客户端请求块并且其不具有关于之后的块的任何信息，则该客户端知道它请求数据过快。如果客户端请求块，并且接收到关于过多之后的块的信息，则客户端可能请求信息过慢。因此， 客户端使用提前元数据作为提示来进行调整。在一些实施例中，自适应流式传输系统提供用于试探法的插件模型以确定在特定时间使用媒体的何种编码。例如，系统可以允许管理员在用于基于特定的条件(例如减小的带宽或增加的分组丢失)来确定请求媒体块的速率的若干策略中选择。另外，内容提供商可以包括其自己的试探法以用于确定要使用的编码，并且可以在应用包(例如 Microsoft Silverlight XAP)文件中提供试探法作为应用模块或应用依赖性模块，该应用包由客户端在播放期间从内容提供商下载。在一些实施例中，自适应流式传输系统存储在此所述的经组装的清单以供之后使用，比如在实况事件的次日回放。在实况事件期间，客户端可能已经基于网络条件请求了各种编码的块。客户端浏览器也可以在浏览器的高速缓存中包含这些块。如果用户请求之后回放媒体，则尝试从本地高速缓存回放媒体是最高效的，这通常意味着客户端请求原来播放的恰好相同的块。通过存储具有来自实际上已接收的每个块的元数据的清单，客户端可以使用之前已请求过的相同编码连续地回放媒体。这可以使得用户能够在到原始服务器的连通性不可用的情况下在诸如飞机之类的情景中观看媒体。在一些实施例中，自适应流式传输系统提供用于同步相关媒体流的逻辑。例如，实况视听事件可以包括一个或多个视频流(例如相机角度)以及一个或多个音频流(例如语言)。当客户端分开地下载音频和视频块时，系统通过将与每个块相关联的时间信息对齐来同步地播放音频和视频媒体内容，这将在此参考时钟同步予以进一步描述。该系统还可以同步其他类型的数据，比如幻灯片呈现中的幻灯片、图像、文本等等。在一些实施例中，自适应流式传输系统提供用于切换到由服务器提供的不同播放速率流(例如特效播放)的客户端侧逻辑。例如，服务器可以包括2X、5X、0.5X或其他回放速度。客户端可以切换到不同速率的流以向用户提供媒体在快进(例如2X)或倒带(例如 0. 5X)的表现。为了进行切换，客户端简单地请求例如处于不同URL处的不同媒体块。客户端可以通过继续播放所接收的特定块来平滑地在以当前速率播放块与以不同速率播放块之间切换。这向最终用户提供无缝的体验，其中在用户的请求与媒体回放的改变之间几乎没有等待时间。这也节省了网络带宽，因为客户端没有为了快1倍播放媒体而2次下载数据，而是下载该媒体的大小降低的编码，其中该编码是以加速的速率编码的。在一些实施例中，自适应流式传输系统接收元数据中的精彩场面标记。精彩场面可以包括媒体的任何感兴趣的片段，比如运动事件期间运动员进球得分的时刻。客户端可以在事件已经结束以后通过播放与精彩场面标记相关联的那些媒体块来播放精彩场面卷。 如果客户端未曾接收实况事件，则客户端可以请求媒体的清单并且然后仅仅请求与精彩场面相对应的那些块。如果用户想要观看精彩场面之前或之后的更多媒体(例如由用户快进或倒带来指示)，则客户端可以请求附加的块来播放所请求的媒体部分。在一些实施例中，自适应流式传输系统支持内联广告和其他非视听数据(例如字幕、评论等等)。对于实况事件而言，可能在事件开始时不知道何时将出现广告中断。事件协调员可以在制片期间在该播广告的时间按下按钮，从而导致系统在媒体流元数据中插入广告标记。当客户端接收到广告标记时，客户端可以请求和接收与之前标识出的广告相关联的块。例如，服务器可以在初始清单中提供潜在广告的列表。广告可以配备在与其他媒体类似的块内，并且可以不存储在提供实况事件的相同服务器处。在遇到广告标记时，客户端暂停主流的回放，检索和显示广告，并且然后恢复主流的回放。在一些实施例中，自适应流式传输系统基于订阅或其他支付模型来确定哪些编码可用。例如，内容提供商可以针对实时事件的高清(HD)版本收取比该事件的标清(SD)版本更多的费用。在这种情况下，客户端可以基于是否已经满足支付模型的条件(例如用户的账户为当前的)来启用或停用到特定比特率的切换。内容提供商可以免费提供一些编码， 比如低比特率或仅限精彩场面的媒体，而对其他编码收费。自适应流式传输系统可以请求和接收多种编码的媒体内容。在一些实施例中，自适应流式传输系统使用定制MP4盒(boxes)。运动图像专家组(MPEG)版本4标准提供可以包含定制数据的格式内的盒。MP4扩展是通常与该版本的内容相关联的文件格式。该系统可以充分利用盒来包括定制元数据和媒体内容块。其他媒体格式在容器内提供类似的内容定制，并且可以供该系统使用。在一些实施例中，自适应流式传输系统符合用于分布式超媒体系统的软件架构的代表性状态转移(REST)风格的方针。REST中的一个观点是应用可以通过仅仅知道资源的标识符(例如URI)以及所请求的动作来与资源交互，而不必知道是否存在高速缓存、代理、 网关、防火墙、隧道、或者处于应用与服务器之间的实际上保持该信息的任何其他东西。遵循REST方针将允许系统受益于现有因特网基础结构和诸如高速缓存之类的预先存在的资源节省技术。一些由系统在一些实施例中实现的与REST有关的示例性原理包括每个URI 都标识出恰好一个响应，每个URI都指向无状态和可高速缓存的服务器资源，并且每个URI 都是直观的并且使用名词(动词是HTTP动词)。具体而言，该系统可以避免作出使用查询串的请求并且可以将基本上唯一的密钥用于通过URL所请求的起始时间。从前面的描述中可以看出，能够理解，此处描述的自适应流式传输系统的特定实施例只是为了说明的目的，但是在不偏离本发明的精神和范围的情况下，可以进行各种修改。相应地，本发明不受限制，只受所附的权利要求书的限制。
权利要求
1.一种计算机实现的用于在客户端上平滑地播放媒体的方法，该方法包括通过网络将对媒体块的请求从该客户端发送410给服务器，其中该块包括从该服务器到多个客户端可用的媒体的统一部分； 在该客户端处接收420所请求的块； 将该块解析430成元数据部分和媒体数据部分；将块元数据添加440到正在进行的媒体清单中，该媒体清单描述关于该媒体块所属的较大媒体元素的信息；以及使用由该块元数据和该客户端的硬件所标识出的编解码器来播放450该媒体数据， 其中以上步骤由至少一个处理器来执行。
2.如权利要求1所述的方法，其特征在于，在该客户端处接收所请求的块包括在该请求到达服务器之前从因特网高速缓存接收该块并且将该块存储在客户端高速缓存中。
3.如权利要求1所述的方法，其特征在于，解析进一步包括标识描述块的编码的元数据以及适于使用编解码器和合适硬件进行回放的媒体数据。
4.如权利要求1所述的方法，其特征在于，该客户端在存储器中存储包含来自每个媒体文件块的元数据的清单。
5.如权利要求1所述的方法，其特征在于，该块元数据部分包括关于至少一个从该服务器可用的随后的块的信息。
6.如权利要求1所述的方法，其特征在于，进一步包括确定要请求的随后块的比特率，其中所确定的比特率基于该块元数据部分中的关于随后的块的计数信息。
7.一种用于平滑地处理来自实况事件的媒体的计算机系统，该系统包括 处理器和存储器，该处理器和存储器被配置为执行软件指令；块请求组件110，该块请求组件110被配置为从客户端作出对来自原始服务器的各个媒体块的请求，其中所述块表示个别化地从该服务器可用的媒体文件的部分；块解析组件120，该块解析组件120被配置为解释由该块请求组件接收的每个媒体块的格式并且将该块分成其组分部分；清单组装组件130，该清单组装组件130被配置为构建描述所接收媒体内容块所属的媒体元素的清单；媒体回放组件140，该媒体回放组件140被配置为使用客户端硬件来回放所接收的媒体内容块；QoS监控组件150，该QoS监控组件150被配置为分析从该服务器接收分组的结果并且基于当前网络条件的集合来调整客户端请求；以及时钟同步组件160，该时钟同步组件160被配置为同步该服务器和该客户端的时钟，使得该服务器和该客户端能够基于时间标识出特定的块。
8.如权利要求7所述的系统，其特征在于，该块请求组件使用HTTPGET请求来请求块。
9.如权利要求7所述的系统，其特征在于，该块请求组件确定与该请求相关联的用户， 并且基于该用户的订阅等级请求块。
10.如权利要求7所述的系统，其特征在于，该客户端和该原始服务器不具有彼此之间的基于状态的连接。
11.如权利要求7所述的系统，其特征在于，该块请求组件通过个别化地标识出块的统一资源定位符(URL)来标识出每个块。
12.如权利要求7所述的系统，其特征在于，该块解析组件将该块分成包含元数据的报头部分以及包含媒体内容的数据部分，并且其中该块解析组件将该元数据提供给该清单组装组件并且将该媒体内容提供给该媒体回放组件，并且如果该块包含非视听数据，则解析该块并且消费该非视听数据。
13.如权利要求7所述的系统，其特征在于，该媒体回放组件被进一步配置为调用一个或多个编解码器来解释在其内部的媒体内容被传输的容器并且从每个媒体块中所包含的经压缩的格式中对媒体内容进行解压缩。
14.如权利要求7所述的系统，其特征在于，该QoS监控组件被进一步配置为通过向不同的服务器URL请求块来切换所请求的块的比特率。
15.如权利要求7所述的系统，其特征在于，该时钟同步组件被进一步配置为维持客户端向服务器请求随后的媒体块的节奏。
全文摘要
在此描述了一种自适应流式传输系统，其提供客户端与服务器之间的用于流媒体回放的无状态连接，其中数据被格式化为使得允许客户端作出决策并且更快速地对改变的网络条件作出反应。客户端向包括媒体的一部分的服务器请求统一的媒体块。自适应流式传输系统以小尺寸块来请求媒体文件或实况流式传输事件的部分，所述小尺寸块每个都具有相区别的URL。这允许由现有因特网高速缓存基础结构来高速缓存流媒体数据。每个块都包含描述该块的编码的元数据信息以及供客户端回放的媒体内容。服务器可以提供多种编码的块，使得客户端可以快速地切换到不同比特率或回放速度的块。
文档编号G11B27/031GK102356605SQ201080012702
公开日2012年2月15日 申请日期2010年3月9日 优先权日2009年3月16日
发明者A·罗伊, G(萨姆)·张, J·A·博恰罗夫, J·E·弗里兰德, K·杜格拉居, L·刘, S·西里瓦纳, V·苏德 申请人:微软公司