CN103179107A - 多径环境自适应流传输系统及方法 - Google Patents

Abstract

本发明涉及一种在多径环境中自适应流传输的系统，所述多径环境包括多个各自能够在RTP/RTSP环境中通过各自的数据路径（20，22，24）发送多媒体内容到客户端（12）的服务器（14，16，18），其中所述客户端（12）包括能够探测每个所述数据路径（20，22，24）以确定与每个所述数据路径（20，22，24）相关联的各自带宽并根据各自带宽请求从每个所述服务器（14，16，18）获得所述多媒体内容的块的控制器部件（40）。另外，本发明还涉及一种在多径环境中自适应流传输的方法。

Description

多径环境自适应流传输系统及方法

技术领域

本发明涉及一种用于多径环境中自适应流传输的系统。更具体地，本发明涉及一种用于在网络带宽条件没有保证并因此波动的多径环境中自适应流传输以改善音频/视频流传输的系统。并且，本发明涉及一种用于多径环境中自适应流传输的方法。

背景技术

流传输是以小片形式将客户端消费的内容发送到客户端的过程，这与下载相反，下载是在播放之前将完整的多媒体文件传输给客户端。已有的流传输协议包括实时传输协议（RTP）或根据用户数据报协议的MPEG传输流（MPEG TS/UDP）。另一方面，下载通常使用超文本传输协议（HTTP协议）进行。

在娱乐和通信系统中，RTSP（实时流传输）协议被提供为控制流传输媒体服务器的网络控制协议。RTSP服务器发送流传输数据是通过实时传输协议（RTP）进行的。RTSP定义了在控制流传输数据回放时有用的控制序列。该控制序列被因特网工程任务推动小组（IETF）定义在RFC 2326标准中。

客户端启动向流传输服务器的流传输会话。流传输服务器通过单播链接向客户端传送被请求的视频。流传输会话的建立涉及客户端和流传输服务器之间的若干RTSP消息，通常涉及内容的选择和如屏幕大小、比特率或最大缓冲器大小的客户端特性的指示。最后使用先前协商好的参数单播RTP流传输会话。流传输会话参数通常保持不变，直到客户端选择其它的内容或终止流传输会话。明显地，这种类型的环境并不能良好地适应变化的网络特性。一些运营商简单地选择限制具有除了实际所需带宽以外的足够的多余带宽的客户端获取某些服务来避免出现问题。

通过因特网发送TV频道（IPTV）的实时流传输已经变得越来越流行。然而，必须要提供能够处理多媒体提供商和客户端之间变化的带宽速率的装置。否则，可能会发生多媒体流的“冻结”，这通常被视为是让消费者感到讨厌的事情。

已经做出各种与解决上述变化的带宽速率问题有关的努力。

在WO 2002/073441 A1中，单个文件被划分成多个随后被分发并被存储在一个或多个服务器上的子文件。可以同时并行地从一个或多个服务器发送子文件，这将提高数据传送的速率。并且，至少一个子文件可以被存储在不止一个的服务器上，以提供冗余性。如果某个服务器不可用，或者如果发送链路较慢或不可用，那么可以从另一个服务器流传输子文件。

在US 2009/0259762 A1中，展示了包括多个控制器和多个服务器的分布式和可分级的内容流传输架构。控制器可用于设置与若干单个装置的实时流传输协议（RTSP）会话。控制器选择服务器以便将被请求的媒体流提供给装置。服务器可以基于其与该装置的邻近性、带宽的可用性或潜伏特性进行选择。可以在系统中添加其它的服务器而不干扰系统工作。

WO 2010/111261 A1展示了一种流传输媒体系统，它使用动态速率自适应。这包括与传统的HTTP基础设施兼容以通过持久连接传送媒体的文件格式。传统的客户端媒体播放器能够动态地改变持久连接上已编码媒体的传送速率。

在US 2010/0094955 A1中，展示了一种分布式存储，其中对每一个由至少一个组装装置组成的群，都根据至少一个评判标准选择出一个局部存储CDN服务器子群。对多个组装装置的群，选择出多个服务器的子群。只要用于传送每个部分的聚合带宽不超过存储从该部分生成的若干片段的服务器的聚合带宽，组装装置就从服务器子群获取与内容的多个部分相关联的擦除编码片段，直到用于获取片段的聚合带宽接近被包括在子群中的服务器的聚合带宽。

US 2006/0215596 A1展示了装置（例如多媒体服务器）的传输速率调节。这些速率调节基于多媒体服务器确定来自两个其它的网路节点之间的无线链接的各种服务质量参数，这两个其它的网路节点可以分别包括接入点和视频播放器。

US6405256B1公开了一种使用通过具有一个或多个高速缓存服务器的通信网络与客户端装置连接的网络服务器进行的数据流传输发送。网络服务器具有数据流传输应用和用于存储数据的存储器。高速缓存服务器在源网络和客户端设备之间的路径上形成一系列连接，每个连接都使用数据流传输构成。每个高速缓存服务器都可以通过在下游连接中使用用于存储流传输数据的额外部分的可扩展缓冲器和改变发送数据速率吸收在其下游连接中的网络拥塞。

并且，第三代合作伙伴计划（3GPP）已经标准化包括能够存储同一内容的多个版本（应该具有不同的编码比特率）的存储器格式的传送架构，该传送架构与流传输服务器侧的智能控制逻辑相关联，并能够应付网络条件的变化。然而，3GPP还没有对该控制逻辑进行规定。

HTTP流传输是最近苹果公司以其iPhone、微软公司以Smoothstreaming、或3GPP以其HTTP自适应流传输宣传的一项技术。

近期的技术使用HTTP协议周期性地提供从客户端到服务器的有关当前网络状况的反馈。自适应内容（固定持续时间但具有变化的比特率的小块多媒体内容）在根据网络状况的同时总是适应网络状况地被供应给客户端。

一个明显的缺陷是客户感知到的质量随着带宽变化可能会严重降低。并且，这些技术不利用（leverage）已有的依靠RTP/RTSP协议的IPTV设备。

因此，目前在本技术领域中存在提供一种分别克服——至少部分地——与现有技术的系统相关联的若干问题的在多径环境中自适应流传输的系统和方法的必要。

发明内容

根据本发明，提供了一种在包括多个能够各自在RTP/RTSP环境中通过各自的数据路径发送多媒体内容到客户端的服务器的多径环境中自适应流传输的系统，其中所述客户端包括能够探测每个所述数据路径以确定与每个所述数据路径分别相关联的带宽并根据各自带宽请求从每个所述服务器获得所述多媒体内容的块的控制器部件。

根据本发明的一个实施例，控制器部件包括用于路径速率估计的部件，它能够对每个各自服务器和数据路径进行服务器速度控制、带宽测量和带宽估计。

根据本发明另外一个实施例，控制器部件包括用于块调度的部件，它能够对将由各自服务器传送的下一个块进行比特率选择。

根据本发明另外一个实施例，控制器部件包括用于库（bin）分配的部件，它能够将一个服务器中特定的块链接到根据链接列表分配的库以获得正确的消费顺序。

根据本发明另外一个实施例，控制器部件包括用于RTP重新编号和重印时间戳的部件，它能够更新RTP时间戳和序列号，以使得编码器不能够区分从多个服务器接收到的流和从单个服务器接收到的流。

在本发明的另外一个方面，提供了一种在多径环境中自适应流传输的方法，包括提供客户端和提供多个各自能够在RTP/RTSP环境中通过各自的数据路径发送多媒体内容到客户端的服务器，其中所述客户端包括能够探测每个所述数据路径以确定与每个所述数据路径分别相关联的带宽并根据相应的带宽请求从每个所述服务器获得所述多媒体内容的块的控制器部件。

根据本发明的一个实施例，控制器部件包括用于路径速率估计的部件，路径速率估计能够对在多径流传输会话中使用的每个服务器并行进行服务器速度控制、带宽测量和带宽估计。

根据本发明的一个实施例，路径速率估计是周期性重复进行的。

根据本发明的一个实施例，路径速率估计通过将速度RTS标准属性添加到播放请求以确定各自数据路径是否会以高于当前速率的速率维持发送来控制每个服务器的速度。

根据本发明的一个实施例，每个服务器的当前速率随后被用于平滑算法以通过迭代确定估计值，以便根据在之前若干次迭代过程中测量到的比特率推算出可达到的比特率。

根据本发明的一个实施例，对每个服务器都计算当前速率的变化。

根据本发明的一个实施例，控制器部件包括用于块调度的部件，它能够对将由各自服务器传送的下一个块进行比特率选择。

根据本发明的一个实施例，将所有服务器的单个比特率估计值相加以获得累积比特率，块的播放速率被选择为稍低于累积比特率的编码比特率。

根据本发明的一个实施例，控制器部件包括用于库分配的部件，它能够将一个服务器中特定的块链接到根据链接列表分配的库以获得正确的消费顺序。

根据本发明另外一个实施例，控制器部件包括用于RTP重新编号和重印时间戳的部件，它能够更新RTP时间戳和序列号，以使得编码器不能够区分从多个服务器接收到的流和从单个服务器接收到的流。

本发明提出了一种在利用现有的使用RTSP/RTP协议的IPTV基础设施的同时提供对流传输到客户端的速率进行即时控制的机制。RTSP（RFC 2326）是建立和控制媒体流传输的协议。它自身不涵盖数据传输协议（通常是RTP）。并且，它通过同时使用多个通信路径并因此平滑整体接收速率和相关用户体验来补偿网络波动。

本发明提出了一种文件格式，它允许在不同比特率的版本之间进行无缝切换，与HTTP自适应流传输类似。

一种巧妙的使用RTSP协议允许客户端在不修改已有的服务器基础设施的情况下同时利用多径通信来探测网络状态和控制流速率。取代传统的IPTV请求获得整个流，客户端从多个服务器接收流的独立的片段以从多径通信中获益。对每个服务器的发送速率单独进行调整，以最小化网络拥塞的风险。

并且，客户端周期性地请求服务器以高于额定速率的速率流传输流的较小的片段以评估在其自身和服务器之间的网络的容量以传送更大份额的内容。当所有网络路径的累积容量对更高的比特率流来说足够时，客户端发送不同的请求到所有的服务器以选择流的更高比特率的版本。当流接收速率相对于当前播放速率太低时，客户端请求服务器选择内容的较低比特率的版本。本发明可以在通过与相关联的基于RTSP/RTP的协议套件完全兼容而不要求更换设备的情况下增加容量来适应在所谓IPTV（管理）环境中的网络变化。并且，它倾向于通过将通信分配到多个网络路径上来平滑单个网络路径的较快的带宽变化。

附图说明

下面将参照附图以示例方式更加详细地描述本发明，附图中：

图1示出了根据本发明的实施例的在多径环境中进行自适应流传输的系统的示意图；

图2示出了根据本发明的实施例的在多径环境中进行自适应流传输的系统的另外一个示意图；

图3示出了根据本发明的实施例的客户端-服务器通信的示意图；

图4示出了根据本发明的实施例的客户端-服务器通信的另外一个示意图；

图5示出了根据本发明的实施例的客户端-服务器通信的另外一个示意图；

图6示出了根据本发明的实施例的客户端-服务器通信的另外一个示意图；以及

图7示出了根据本发明的实施例的客户端的更进一步的示意图；

在附图中，除非另有说明，相似的参考标号是指相似的部分。

具体实施方式

现在参照图1进行说明，本发明在此实施例中包括用于在包括客户端12和多个各自能够在RTP/RTSP环境中通过各自的数据路径将多媒体内容发送到客户端12的服务器的多径环境中自适应流传输的系统10。客户端12被描述为机顶盒和显示器。图1中，第一服务器14、第二服务器16和第三服务器18仅作为例子示出，它们分别通过第一路径20、第二路径22和第三路径24与客户端连接。

与大部分自适应流传输技术相似的是，必须对内容进行多比特率预编码以支持自适应传送。并且，流的不同版本是“GOP对准”的，这意味着对所有不同的比特率的流来说，允许在流内随机存取的参考帧的位置位于相同时刻。这个性质允许解码器在一些精确的位置处（参考帧）在不同的流之间切换而不引起任何视觉伪像。然后，允许客户端12请求获得/下载这些流版本中任何一个版本的块，其中块是一组GOP，具有恒定的持续时间，例如2秒。

然后，多比特率的内容和列出可用比特率的描述文件一起被分发给服务器14、16和18。该描述文件与典型的自适应流传输实施方式中使用的清单文件类似。在此实施例中，描述文件被实施为SDP文件。

图2描述了内容的准备：编码器32对多媒体内容30进行在所有参考帧出现在每个已编码流的相同时刻的附加限制下的多比特率编码。考虑到从某一比特率转变成另一比特率的发生频率可能低于每个GOP（转变一次），可以要求进行在周期性基础上几十毫秒一次的参考帧的对准（本示例中2秒）。在该实施例中，使用H.264和AAC CODECS对内容进行编码，参考帧每2秒出现一次，然后将内容封装成MPEG传输流。用于描述实施例的示例内容被以下面一组总比特率进行编码：500kbps、1000kbps、1500kbps和2000kbps。流描述可以使用SDP协议表达。

在此实例中，发送4个MPEG TS轨道，使用SDP协议中的b=TIAS属性公告它们的比特率。另外，“X-altservers”属性为客户端提供了备选位置的列表，可以从这些位置接收内容30。可以使用这些备选位置来取代主要位置，因为它们持有的内容完全相同。

图3描述了常规的RTSP控制流传输会话的操作。第一消息允许客户端12了解流的性质。被称为建立（SETUP）的第二消息为流传输会话作准备，最后播放（PLAY）消息使得服务器14开始发送多媒体流。

在本发明中，客户端在流传输会话期间从一个流切换到另外一个。在此实施例中，为了清楚起见，客户端在流传输会话开始时发出若干建立消息。对每个可用轨道发出一个建立。然而，明显地，每个轨道的建立消息也可以在客户端真正需要接收该轨道之前由客户端发出。

图4示出了多轨道设置阶段。作为优化，客户端12也可以通过发出会话的URL的建立消息替换会话的单个轨道的单个建立消息一次设置所有的轨道。为了支持多个服务器工作，客户端12对在X-altservers属性中列出的每个服务器执行该初始化过程。

如图5所示，一旦所有的轨道都已经被建立好，客户端12就通过发出请求获得期望轨道中期望的时间间隔的播放请求来请求多媒体内容的较小的块。

使用在SDP中找到的trackID选择轨道。使用范围（range）：首标（header）向服务器指示时间间隔。例如，为了选择2-4秒的时间间隔，客户端将在其播放请求中添加下列首标：

PLAY rtsp://multimedia.example.com/stream/trackID=1 RTSP/1.0 Range:npt=2-4

为了避免在流的块之间出现播放中断，客户端发出新的RTSP播放请求以提前请求下一个块以保持播出（playout）缓冲器中有足够多的数据。在我们的实施例中，播出缓冲器包含预先下载的2秒钟的多媒体流。

对多径、多服务器操作，如图6所示，客户端12请求从每个服务器14、16和18以与客户端对该网络路径容量的估计对应的速率并行流传输过来的不同的块。

图7示出了适用于客户端12的多径和多服务器操作的控制器40的示意图。控制器40包括用于路径速率估计的部件42，它能够对每个服务器和数据路径分别进行服务器速度控制、带宽测量和带宽估计。并且，控制器40包括用于块调度的部件44，它能够为将由各自服务器传送的下一个块进行比特率选择。控制器40进一步包括用于库分配的部件46，它能够将一个服务器的特定的块链接到根据链接列表分配的库以获得正确的消费顺序。控制器40包括用于RTP重新编号和重印时间戳的部件48。还存在消费单元50，它允许显示接收到的流。

客户端12以这样的方式将这些接收到的流积聚成单个流以使得它与假设从单个服务器接收到的流完全一样，即，序列号和RTP时间戳单调递增。这个任务涉及对接收自不同的服务器的RTP分组的缓冲和重新编号。这通过图7所示的库分配和RTP重新编号步骤得以解决。最后，将该积聚的流注入客户端的解码缓冲器。

通过对每个服务器14、16和18以及相关联的网络路径20、22和24独立地使用路径速率估计部件42来估计路径速率（路径的可用比特率）。因此，对每个在多径流传输会话中使用的服务器而言，下面描述的过程是并行进行的。

带宽估计过程由下面几个步骤组成。首先，进行服务器速度控制。于是，客户端12管理服务器14、16和18的发送速度，以测量网络路径20、22和24实际可用的比特率。第二，进行带宽测量。于是，确定当前块的当前网络比特率的客户端12接收到的流较之服务器14、16和18的发送速度的特性被确定。第三，进行带宽估计。对单个带宽测量进行平滑处理以产生可用于选择下面的块的准确值。

因此，服务器的发送速度由客户端管理，以测量网络实际可用的比特率。

带宽测量主要在于确定客户端接收到的流的较之服务器发送速度的特性，以确定与当前块对应的当前网络比特率。

带宽估计主要在于对单个带宽估计进行平滑处理，以产生可用于选择下面的块的准确值。

周期性地重复整个带宽估计过程，但在网络条件变化缓慢的情况下，不必对每个块这样做。

有利地，因而，使用最慢的路径获得将要在“较远”的时间呈现的块，以及使用最快的路径获得将要“马上”呈现的块是可能的。

可以通过将已有的标准属性“Speed”添加到播放请求来控制服务器14、16和18的速度。修改服务器速度背后的想法是确定网络是否可能以高于当前速率的速率维持发送。在图6和图7的实施例中，客户端12周期性地探测网络容量，通过请求服务器以当前速度的1.2倍发送块，从而将发送速率提升20%。

一个示例性RTSP请求可以是：

PLAY rtsp://multimedia.example.com/stream/trackID=1 RTSP/1.0

CSeq:833

Range:npt=2-4

Speed:1.2

服务器对上述请求可能做出如下相应：

RTSP/1.0 200 OK

CSeq:834

Range:npt=2-4

RTP

Info:url=rtsp://multimedia.example.com/stream/trackID=1;seq=45102;rtptime=12345678

被称为rtptime的参数表示与选择的npt范围的开始对应的RTP时间戳。在给定的时钟速率下，客户端确定与被请求的块对应的rtptime范围。为了计算当前比特率B_i，客户端12将在上述rtptime间隔内接收到的RTP分组的比特相加。其除以这些字节的发送持续时间（在接收到的第一个字节和接收到的最后一个字节之间测量）：

B_i=Bytes·8/发送持续时间

然后，该当前比特率被平滑算法利用以确定可靠的估计值。在本实施例中，使用的算法是一个迭代算法，并试图根据在之前的迭代过程中测量到的比特率推算出可达到的比特率。

下一个迭代过程的平均比特率被计算为当前比特率的均值和当前测量值的加权平均，如下面公式所示：

avg_i+1＝(1-α)·avg_i+α·B_i

其中，B_i是测量的比特率，avg_i是计算的当前迭代过程的平均比特率，α是赋给当前比特率测量值的权重。在一个实例中，该权重被选为α=1/16。

除了平均比特率，该算法还估计比特率的变化。使用与比特率相同的方式对该变化进行平滑处理，如下所示：

Δ_i=|B_i-avg_i|

var_i+1=(1-β)·var_i+β·Δ_i

其中，Δ_i是测量的比特率与平均比特率之间的差值，对当前迭代过程，var_i是计算的当前估计值的变化，β是赋给当前变化的测量值的权重。在一个典型实施例中，β被选为α=1/8。

对每一次迭代，当前估计值（或可达到的比特率）的计算如下：

${\hat{B}}_i={\mathrm{avg}}_i-4\·{\mathrm{var}}_i$

这意味着，如果变化较大，那么客户端12使用的带宽要比平均带宽少得多。另一方面，当带宽稳定，变化较小时，客户端12趋向于使用链接上的全部可用带宽。

考虑两种估计重置的异常情形：当变化太大时（例如，大于平均比特率的一半）或者当RTP序列号中存在不连续时（这意味着丢失了RTP分组）。

在上述情形中，平均值和变化估计被重置如下：

${\mathrm{avg}}_{i+1}=\frac{{\mathrm{avg}}_i+B_i}{2}$

var_i+1=avg_i+1÷10

RTP不连续的事件可以触发对相关路径/服务器的新的比特率估计和/或对所有之前调度过的块的重新调度。

服务器和块的调度可以通过使用服务器和块调度部件44进行。每次当客户端12完成接收来自给定服务器的被请求的块（服务器变为闲置）时，它都更新该服务器的带宽估计，并再次使用该连接获取另外一个块。根据所有服务器路径的可用性和相对比特率，服务器连接可以被用来获取将要播放的下一块或者将被稍后播放的块，即，这叫做块调度。下面描述调度算法。

首先，服务器和块调度部件44选择下一个块的比特率。为此，由于所有的服务器是并行使用的，所以服务器和块调度部件44将所有服务器14、16和18的若干单个比特率估计值相加（参见下面）以获得累积比特率（aggregatebit rate）。选择的块的播出速率是稍低于（immediately inferior to）累积比特率的编码比特率。

在时间t_e，当编码器缓冲器腾空时，首先使用当前播出和流传输参数计算与每个服务器14、16和18对应的块到达时间：a_k是路径k变成闲置状态的时间（完成接收最后一个块或被调度的块），d是块持续时间，B是播出比特率，B_k是服务器/路径k的当前比特率估计。从服务器k下载下一个块要花费的时间表示为D_k，D_k＝d·B/B_k。如果使用服务器k，那么块的到达时间变成：R_k=a_k+D_k。

该算法选择产生最小的R_k的服务器。并且，块的到达时间必须早于解码器缓冲器腾空的时间（t_e），即必须满足R_k<t_e。如果不满足，那么缓冲器将会干枯，播出中也会出现可视的中断。在此情形下，播出比特率将会被降低为下一个较低的比特率。如果满足到达时间的条件，那么在服务器k上对该块的获取进行调度。发送速率必须被调整为匹配对服务器/路径k进行的当前比特率估计。这使用速度完成：RTSP PLAY请求的首标中Speed=B_k/B。

例如，假设播出速率B是1Mbps（正在播放trackID 1），当前比特率估计B_k是400kbps，我们可能得到Speed=0.4。值得注意的一方面是，如果触发了对当前块的周期性的带宽估计过程，要将得到的速度乘以1.2。

下面是相应的将被发送给服务器k的请求（假设对当前块未进行任何带宽估计）：

PLAY rtsp://multimedia.example.com/stream/trackID=1 RTSP/1.0

CSeq:838

Range:npt=40-42

Speed:0.4

如果当前服务器是闲置的，那么马上发出接下来的RTSP请求。否则，如果服务器仍处于使用中，那么延迟RTSP请求，直到服务器变为闲置。

最后，新的块被推进缓冲器，因此值t_e增加块的持续时间（d）：t_e=t_e+d。如果服务器中的任何一个闲置，那么重复之前的步骤，直到所有的服务器14、16和18都处于繁忙中。否则，服务器和块调度部件44等待服务器再次变为闲置。

库分配通过使用库分配部件46进行。每次当向服务器14、16和18发送请求获得给定块的请求时，响应都会被链接到根据链接列表分配的库上，该链接列表保证正确的消费顺序。即，列表的头部是包含下一次将被供应给解码器的分组的库。列表的尾部是包含将被最后解码的分组的库。

RTP重新编号和重印时间戳通过使用RTP重新编号和重印时间戳部件48进行。标准化最后被传送到视频解码器/多路分解器的RTP流是必要的。对每个发送到给定的服务器14、16和18的请求，都分配一个具有正确的消费顺序的接收的库。一旦已经接收到与该请求对应的所有的RTP分组，就更新RTP时间戳和序列号，以使得编码器不能够区分从多个服务器接收到的流和从单个服务器接收到的流。

在实践中，所有分组的序列号和RTP时间都被重新编号为以用于馈入解码缓冲器的最后一个序列号和RTP时间戳开始。

因此，本发明允许适用于RTSP/RTP协议套件的多径自适应流传输。巧妙的使用RTSP协议中的Speed参数允许并行使用多径服务器和探测网络状态。客户端并行使用多径RTSP服务器允许对变化的网络状况较快地做出反应，并最优化用户体验。本发明适用于现有的在IPTV基础设施中使用的RTSP/RTP。

换言之，与本发明优选实施例对应的系统是在包括多个服务器14、16和18的网络环境中使用多径自适应流传输技术发送视听内容的系统；每个服务器都被配置用于基于遵守RTSP/RTP的通信协议通过各自的数据路径20、22和24向客户端12发送多媒体内容，其中客户端12包括能够探测所述每个数据路径20、22和24以确定与每个数据路径20、22和24分别相关联的带宽并根据确定的相应的带宽请求从每个服务器14、16和18获得所述多媒体内容的块的控制器40。

控制器40包括用于估计分别处于每个服务器14、16和18与客户端12之间的每个数据路径20、22和24的可用比特率的部件42，并且被配置为进行服务器14、16和18侧的服务器速度控制。

控制器40还包括用于根据可用比特率进行块选择的部件44，用于选择将由相应的服务器14、16和18传送的下一个块。

控制器40进一步包括用于库分配的部件46，被配置为将一个服务器14、16和18中的特定块链接到根据链接列表分配的库，以在客户端（接收器）侧获得正确的消费顺序。

与继续构建（形成）单个连贯的流相关，控制器40包括用于RTP重新编号和重印时间戳的部件48，用于更新RTP时间戳和序列号。这允许在客户端侧形成单个连贯的流，就如同它原本被接收的那样，例如，从单个服务器。

因此，根据本发明优选实施例使用的方法是一种用于在多径环境中自适应流传输的方法，所述多径环境包括：

-提供客户端；以及

-提供多个服务器14、16和18，各自被配置为在RTP/RTSP环境中通过各自的数据路径20、22和24发送多媒体内容到客户端，其中客户端12包括用于探测每个数据路径20、22和24以确定与每个所述数据路径20、22和24分别相关联的带宽并根据确定的各自带宽请求从任何服务器14、16和18获得多媒体内容的块的控制器40。

控制器包括用于估计路径比特率的部件42，它进行服务器14、16和18侧的服务器速度控制，对每个服务器14、16和18并行进行带宽测量和带宽估计，并在多径流传输会话中使用。

根据优选实施例，路径比特率估计周期性地反复进行。

路径比特率估计42包括通过在播放请求中添加速度RTS标准属性控制相应的服务器14、16和18的速度的步骤。

对每个服务器14、16和18，当前速率随后被用于平滑算法迭代确定估计值以根据在之前若干次迭代过程中测量到的比特率推算出可达到的比特率。

对每个服务器14、16和18，计算当前速率的变化。

控制器40包括用于块调度的部件44（或块选择），用于对将由相应的服务器14、16和18传送的下一个块的比特率进行选择。

将所有服务器14、16和18的单个比特率估计值相加（参见下面）以获得累积比特率，块的播出速率被选择为稍低于累积比特率的编码比特率。

本发明的关键元素是：标准RTSP协议（与HTTP流传输相对），并因此重复使用现有的生态系统；使用标准SDP发信号通知内容的多个版本，使用新的属性示出多个服务器上的内容的可获得性；通过RTSP发信号通知基于RTSP协议持续估计单个网络路径上的可用带宽同时操作多个服务器/多个网络路径；以及基于期望传送方案持续平衡多个路径上的数据速率。

尽管在此已经描述了本发明的仅仅某些实施例，但是本领域的任何一个技术人员应该理解的是，本发明的其它修改、变化和可能性也是可能的。因此，这些修改、变化和可能性被视为落入本发明的精神和范围内，从而构成在本说明书中描述和/或示例的发明的一部分。

本发明已经被描述为其优选实施例，显然地，在本领域的技术人员的能力范围内，并且不用实践创新能力，它可以容易地变化为多种修改例和实施例。因此，本发明的范围由所附权利要求的范围限定。

本说明书中引用的所有的例子和条件性语言都旨在用作教导目的，以帮助阅读理解本发明的原理和发明人贡献的促进本技术领域发展的概念，并应该被解读为不限制这些被详细引用的例子和条件。

并且，本说明书中所有引用原理、本发明原理的方面和实施例以及其特定例子的陈述都旨在包括其结构和功能的等同体。并且，这些等同体旨在包括当前已知的等同体和将在未来开发的等同体，即任何被开发出来执行相同功能而不论其结构如何的元件。

因此，例如，本领域的技术人员将会理解的是，本说明书中出现的框图表示实施本发明原理的示例性电路系统的概念图。类似地，将会理解的是，任何流程表、流程图、状态转换图、伪码等表示可在计算机可读媒体中被实质性表示并由计算机或处理器执行的各种过程，不论这些计算机或处理器是否明显地显示出来。

图中所示的各种元件的功能可以通过使用专用硬件和能够联合合适的软件执行软件的硬件提供。当由处理器提供时，该功能可以由单个专用的处理器或单个共用的处理器或其中有一些可以共用的多个独立的处理器提供。并且，明确的使用术语“编码器”、“控制器”、“调度器”、“估计器”或其各自的执行相应功能的等同部件不应该被解读为排他性地专指能够执行软件的硬件，而应该被解读为没有限制地、隐含地包括数字信号处理器（DSP）硬件、用于存储软件的只读存储器（ROM）、随机存储器（RAM）和非易失性存储器。

还可以包括其它传统和/或常规的硬件。相似地，说明书的引用的任何切换都可以通过执行程序逻辑、专用逻辑、程序控制和专用逻辑交互进行，可由实施者选择的特定技术可以在上下文中被理解得更加详细。

在本说明书的权利要求中，任何被表达为执行特定功能的部件的元件都旨在包括执行该功能的任何方式，该功能包括例如a）执行该功能的电路元件的组合或b）包括与合适的用于执行软件以完成该功能的电路组合在一起的固件、微码等的任何形式的软件。这些权利要求限定的本发明原理在于下列事实：各个被列举部件提供的功能以权利要求要求保护的方式组合并放置在一起。因此，任何可以提供这些功能的部件被视为与那些在本说明书中示出的是等同的。

本说明书中引用的本发明原理的“一个实施例”或“实施例”以及其它变型是指与实施例联系在一起描述的特定特征、结构或特性等被包括在本发明原理的至少一个实施例内。因此，出现在说明书中各个位置的词语“在一个实施例中”或“在实施例中”以及其它变型并不一定都是指同一个实施例。

应该理解的是，本发明可以被实施成硬件、软件、固件、专用处理器或其组合的各种形式。优选地，本发明的原理可以被实施为硬件和软件的组合。并且，软件优选地被实施为有形地实施在程序存储装置上的应用程序。应用程序可以被上载到或者由包括任何合适的体系结构的机器执行。优选地，机器可以被实施在具有硬件诸如一个或多个中央处理单元（CPU）、随机存取存储器（RAM）和输入/输出（I/O）接口的计算机平台上。计算机平台还包括操作系统和微指令代码。本说明书中描述的各个过程和功能可以要么是微指令代码的一部分，要么是应用程序（或它们的组合）的一部分，应用程序通过操作系统执行。另外，可以将各种其它的外围装置连接到计算机平台上，诸如附加的数据存储装置和打印装置。

还应该理解的是，由于附图中描述的一些组成系统组件和方法步骤优选地被实施为软件，因此系统组件（或过程步骤）之间的实际连接可能根据本发明原理被编程的方式而有所不同。考虑本说明书中的教导，相关领域的一个普通技术人员能够设想出本发明原理的这些以及类似的实施方式或轮廓。

Claims (15)

1.一种在包括多个服务器（14，16，18）的网络环境中使用多径自适应流传输技术发送视听内容的系统，每个所述服务器都适用于基于遵守RTP/RTSP的通信协议通过各自的数据路径（20，22，24）向客户端（12）发送所述多媒体内容，其特征在于，客户端（12）包括能够探测所述每个数据路径（20，22，24）以确定与每个所述数据路径（20，22，24）相关联的各自带宽并根据确定的各自带宽请求从每个所述服务器（14，16，18）获得所述多媒体内容的块的控制器（40）。

2.如权利要求1所述的系统，其特征在于，控制器（40）包括用于估计分别处于所述每个服务器（14，16，18）与所述客户端（12）之间的所述每个数据路径（20，22，24）的可用比特率的部件（42），并且被配置为进行服务器（14，16，18）速度控制。

3.如权利要求1或2所述的系统，其特征在于，控制器（40）包括用于根据可用比特率进行块选择的部件（44），用于选择将由相应的服务器（14，16，18）传送的下一个块。

4.如权利要求1所述的系统，其特征在于，控制器（40）包括用于库分配的部件（46），被配置为将一个服务器（14，16，18）中的特定块链接到根据链接列表分配的库，以获得正确的消费顺序。

5.如权利要求1所述的系统，其特征在于，控制器（40）包括用于RTP重新编号和重印时间戳的部件（48），用于更新RTP时间戳和序列号以形成单个连贯的流。

6.一种用于在多径环境中自适应流传输的方法，所述多径环境包括：

-提供客户端；以及

-提供多个服务器（14，16，18），各自被配置为在RTP/RTSP环境中通过各自的数据路径（20，22，24）发送多媒体内容到客户端，其特征在于，客户端（12）包括用于探测所述每个数据路径（20，22，24）以确定与每个所述数据路径（20、22、24）相关联的各自带宽并根据确定的各自带宽请求从任何所述的服务器（14，16，18）获得所述多媒体内容的块的控制器（40）。

7.如权利要求6所述的方法，其特征在于，所述控制器包括用于估计路径比特率以对在多径流传输会话中使用的每个服务器（14，16，18）并行进行服务器（14，16，18）速度控制、带宽测量和带宽估计的部件（42）。

8.如权利要求7所述的方法，其特征在于，所述路径比特率估计周期性地反复进行。

9.如权利要求7或8所述的方法，其特征在于，路径比特率估计（42）通过在播放请求中添加速度RTS标准属性控制相应的服务器（14，16，18）的速度。

10.如权利要求9所述的方法，其特征在于，对每个服务器（14，16，18），当前速率随后被用于平滑算法以迭代确定估计值，以便根据在之前若干次迭代过程中测量到的比特率推算出可达到的比特率。

11.如权利要求9所述的方法，其特征在于，对每个服务器（14，16，18），计算当前速率的变化。

12.如权利要求6-7中任何一项所述的方法，其特征在于，控制器（40）包括用于块调度的部件（44），它能够对将由相应的服务器（14，16，18）传送的下一个块的比特率进行选择。

13.如权利要求12所述的方法，其特征在于，将所有服务器（14，16，18）的单个比特率估计值相加以获得累积比特率，并且块的播出速率被选择为稍低于累积比特率的编码比特率。

14.如权利要求6-7中任何一项所述的方法，其特征在于，控制器（40）包括用于库分配的部件（46），用于将一个服务器（14，16，18）中的特定块链接到根据链接列表分配的库，以获得正确的消费顺序。

15.如权利要求6-7中任何一项所述的方法，其特征在于，控制器（40）包括用于RTP重新编号和重印时间戳的部件（48），它能够更新RTP时间戳和序列号以形成单个连贯的流。

Images