具体实施方式

本公开的实施例涉及一种流传输远程定位的内容的方法，并且涉及一种被配置为执行该方法的客户端设备。在本文的至少一些实施例中作为MSDAH(多服务器DASH)被提及。

在本公开的实施例中，多个客户端可以并行地共享多于一个服务器。服务器的共享使得实现统一的QoE，并且瓶颈链路或过载的服务器不会对客户端产生局部影响。当前公开的实施例的功能在客户端侧的应用层中以分布式方式实现，并且例如可以是现有DASH客户端侧架构的修改版本。因此，当前公开的实施例不需要对内核或网络功能进行任何修改，该修改包括传输层修改。如下面将详细描述的，已经发现本公开的实施例可以显著地改善流传输性能，包括以下改进：

·与从单个服务器的顺序下载相比，在客户端之间具有小于1％的变化的高于33％的QoE。

·针对服务器瓶颈和可变网络条件的高鲁棒性。目前提出的解决方案没有过度利用可用带宽，并且在大多数情况下，附加数据开销是针对10分钟视频回放的媒体数据的附加片段下载。

·显著优于顺序的单个服务器DASH和基于CDN的负载均衡规则，包括：轮询调度、最少连接、会话持续性和加权。

有利地，本公开的实施例通过首先确定瓶颈或故障服务器来有效地处理瓶颈；停止从所述确定的瓶颈服务器请求未来片段；并且例如通过基于探针的被动或主动测量，来周期性地监测瓶颈服务器的状态以发现任何变化(例如，它可以再次变成健康服务器)。

另外，当前公开的实施例提供了比现有技术方法更公平和更高的QoE，并且通过利用来自具有不同容量的多个服务器的扩展带宽和链路分集来达到最佳比特率。本公开的实施例提供了一种纯客户端驱动的解决方案，其中修改被限制到客户端侧的应用。因此，网络和服务器侧保持不变，使得实施方案不太复杂并且不太容易出错。

在本公开中，使用以下符号和缩写。

表I：关键符号和记号的列表。

本公开的实施例在客户端设备处实现比特率选择过程，该比特率选择过程由客户端设备的回放缓冲器占用率、客户端设备可以从其请求数据片段的一组服务器的估计吞吐量、或者该组服务器的回放缓冲器占用率和估计吞吐量的组合来支配。

图1中示出了用于流传输内容的系统50的一种可能的架构。在计算设备(诸如移动设备102、膝上型计算机104或台式计算机106)上执行的客户端100能够经由诸如因特网140之类的广域网连接到多个服务器以请求数据。在图1所示的示例中，系统50包括六个服务器(分别标记为s₁至s₆)，但是可以设置更少或更多的服务器。在一些实施例中，可以部署数十或者甚至数百个服务器作为系统50的一部分。通常，服务器s_i将是客户端100可以连接到的DASH服务器，并且可以经由HTTP GET请求来请求内容，并且客户端100可以被实现为例如dash.js参考播放器的修改版本。

通常，服务器s_i通常经由因特网140连接来镜像由内容提供商110提供的数据。诸如过顶(OTT)服务120的其它参与方也可以给服务器s_i提供内容以供客户端100进行流传输。

根据当前公开的实施例的客户端100并行请求来自所有可用服务器s_i的至少一个子集，优选地是可用服务器s_i的所有子集的不同片段，以最大化多个服务器的吞吐量。例如，如图1所示，如果来自五个不同服务器的可用吞吐量是2Mbps、1Mbps、1.5Mbps、0.5Mbps和1Mbps，则客户端100应能够在没有任何停顿的情况下播放质量等于6Mbps的视频。

每个客户端100可以被布置为同时从多个服务器请求片段，所述多个服务器可以是地理上分布的。客户端100可以利用现有网络基础设施中的链路分集来提供鲁棒的视频流传输解决方案。

重要的是，可以在DASH服务器或网络中没有任何修改的情况下实施当前公开的实施例。所有修改都在客户端100处执行，因此不需要对内核进行改变。客户端100可以表示支持DASH系统的视频播放器，诸如参考播放器dash.js.

每个客户端100的特征在于在其上执行客户端100的设备102、104或106的能力(诸如显示分辨率、存储器和CPU)，并且可以请求各种内容类型(例如，动画、电影、新闻等)。客户端100可以实现一个或更多个自适应比特率(ABR)过程。

客户端100的示例架构的进一步细节在图2中示出，客户端100可包括以下四个组件。

(i)跟踪回放缓冲器占用率的缓冲器控制器210。缓冲器控制器210可以包括用于检查由ABR控制器220选择的比特率是否导致视频停顿的逻辑，并且如果是这种情况，则选择新的合适的比特率。缓冲器控制器210还可以包括用于将比特率维持在例如在两个预定义的高阈值和低阈值之间的安全级别的逻辑。缓冲器控制器210将关于缓冲器大小的数据提供给ABR控制器220，用于输入到速率适配算法，使得ABR控制器220可以选择适当的比特率。

(ii)吞吐量估计器230，该吞吐量估计器230可预测来自服务器s_i的分段的下载吞吐量，并提供该估计至ABR控制器220，以输入到速率适配算法。吞吐量估计器230可以考虑用于吞吐量预测的两种平滑函数，例如包括最后三个平均吞吐量或最后一个吞吐量。

(iii)ABR控制器220，该ABR控制器220使用一个或更多个ABR规则224，结合来自缓冲器控制器210的缓冲器大小数据和/或来自吞吐量估计器230的吞吐量数据来实现速率适配算法(本文也称为ABR算法)，以决定对于要下载的下一个片段应当选择哪个比特率。例如，ABR规则224可以包括基于缓冲器的比特率选择、基于速率的比特率选择、或组合缓冲器和(基于速率的)吞吐量考虑的混合比特率选择。ABR算法可以选择最佳可能比特率来以最大可能的质量来流传输内容。ABR控制器220将所选择的比特率提供给调度器240以用于将下载调度到缓冲器控制器210。

(iv)调度器240，该调度器240从相应的服务器控制、请求并下载适当的片段。调度器240还可以负责避免多次下载相同的片段以节省带宽，以及避免由于瓶颈服务器而导致的性能下降。

例如，对于每个片段下载t∈[1,...,Z]，其中Z表示下载步骤的总数，客户端100可以使用ABR控制器220来选择适当的比特率r_i，该比特率r_i适应于回放缓冲器占用率和每个源s_i的下载吞吐量，其中i∈[1,...,M]，M表示现有服务器的总数。然后，客户端100可以(经由调度器240)同时从M个服务器s_i请求多个连续的片段。当缓冲器控制器210监测的回放缓冲器达到其最大容量K时，客户端100可(经由缓冲器控制器210)触发停止下载的事件，并将服务器的数量逐渐减少为单个服务器，以避免缓冲器溢出。每当存在容纳片段的空间时，即当没有达到最大缓冲器容量时，可以增加所使用的服务器的数量，直到服务器的数量达到M。

在一些实施例中，系统50可通过用有向或无向图G＝(V,E)表示来建模，其中V＝C∪S是客户端C＝{c₁,...,c_N}和服务器S＝{s₁,...,s_M}的集合。为了建模的目的，可以假设全网状网络，即，胖树(Fat-Tree)拓扑(例如，OSPF网状网络)，其中，每个客户端c_j∈C具有到每个s_i∈S的连通性，其中j＝[1...N]并且i＝[1...M]，并且因此客户端100使用不同的多个链路从现有服务器同时获取连续的片段。

当回放缓冲器变满时，客户端100停止下载片段，并将所使用的服务器的总数逐渐减少到一个。否则，如果在回放缓冲器中有空间，客户端100可以增加服务器的数量，直到它利用所有现有的服务器(全服务器利用)。

由于拥塞和网络可变性，在任何时候，到服务器s_i的链路可能变慢，并且服务器将被认为是瓶颈服务器。在这种情况下，由于来自瓶颈服务器的延迟片段导致客户端回放缓冲器的耗尽，因此客户端100遭受延迟。为了避免这个问题，在某些实施例中，客户端100可以停止从瓶颈服务器获取未来的片段，而是仅从M-H个剩余的服务器获取未来的片段，其中H是瓶颈服务器的总数。每个客户端100可以通过请求具有最低质量的先前片段来跟踪瓶颈服务器的状态，并且一旦瓶颈服务器可以提供服务并且再次满足客户端要求，则恢复瓶颈服务器的使用。

在某些实施例中，在开始流会话之前(即，直播或点播)以及在认证过程之后，每个客户端100可以首先获取MPD文件(通常是包括形成流服务的资源的描述的XML文件)，然后并行地从现有DASH服务器获取视频片段。每个视频v的片段存储在DASH服务器的集合S中，T秒的每个视频被分成Z(＝T/τ)个片段，且每个片段seg_t具有固定的持续时间τ秒，其中t∈[1...Z]，并且以各种比特率级别R_v和分辨率L_v进行编码，表示为η。

在每个步骤t期间，播放器(客户端)c_j使用速率适配(ABR)算法为待下载的下一个片段选择合适的比特率级别r_t+1。所选择的比特率可以适应于来自所有可用服务器的可用吞吐量w_t，并且将缓冲器占用率B_t维持在安全区域内(即，在上溢阈值和下溢阈值之间)。MPD文件中列出的比特率和分辨率的级别可以表示为：

其中，r∈[r¹...r^η]且l∈[l¹...l^η]，η是可用比特率和分辨率级别的总数。由于具有内容分辨率，每个客户端100选择在其设备显示分辨率范围内的合适级别的比特率和分辨率。

本公开的实施例旨在消除缓冲器欠载和溢出问题。可以如下执行回放缓冲器占用率的测量：

其中B_t-1是前一步骤t-1中的缓冲器占用率估计，Size(seg_t,r_t,l_t)是以比特率r_t和分辨率l_t编码的片段t的大小，I是当seg_t被完全下载时缓冲器占用率的增加以及在视频渲染期间的减少。估计缓冲器占用率的其它方法也是可能的。

例如，视频片段到达客户端100可以被建模为有限缓冲器、批到达、M^x/D/1/K队列，其中K是缓冲器容量。图3中示出了客户端100的示例队列模型。该模型可以建立下载吞吐量、可用比特率、缓冲器容量和预期缓冲器占用率之间的关系，从而允许客户端100将视频比特率适配到估计的吞吐量，同时将缓冲器占用率保持在稳态下的缓冲器容量的一半。

如图3所示，来自不同服务器的片段的到达被建模为批处理，并且通过对来自相应服务器s_i的各个到达速率λ_i求和来计算总有效到达速率。每个片段具有τ秒的持续时间。每秒，客户端100中的单个解码器以速率μ＝1/τ片段/秒服务于片段。让来自服务器s_i的下载吞吐量是w_i bps从而下载质量r_i bps的片段。因此，片段以片段/秒的速率到达队列，并且以K秒的容量存储在队列中。为了限制比特率切换的数量，可以以相同的质量下载同一批次中的片段。因此，来自服务器s_i的到达速率是队列处的总到达速率是该批次中的所有到达速率的总和，即λ＝∑_iλ∑_i。因此，队列服务器利用率是ρ＝∑_iλ_i/μ＝w/r，其中w＝∑_iw_i。预期的平均队列长度O_k,ρ和预期的缓冲器松弛因子Bs_K，r，w＝K-O_k，ρ可以使用由Brun和Garcia(J.Appl.Prob.(2000),1092-1098)给出的分析解决方案来计算。

某些实施例的速率适配算法考虑来自不同服务器的总计到达速率。假设给定视频以比特率值R＝{r¹,r²,...,r^η}被编码，其中如果j＜k，则r^j<r^k。该算法选择时间t处的比特率r，使得预期缓冲器松弛因子Bs最接近估计的(或以其它方式获得的)缓冲器占用率B_t，

通过支持较高的比特率来打破平局。与先前已知的方法不同，Bs是来自不同服务器的估计的总计吞吐量，而不是当前比特率和总的缓冲器容量(或大小)的函数。

因为客户端100同时从多于一个服务器下载片段，所以下载调度器240可以在发送片段请求之前跟踪当前缓冲器级别，以避免超过缓冲器容量。例如，具有30秒缓冲器容量和具有24秒的当前缓冲器占用率的客户端100播放具有4秒片段持续时间的视频，并且五个可用服务器可以仅向一个服务器发送请求。如果当前缓冲器占用率下降到10秒以下，则期望下载调度器240向所有服务器s_i发送片段请求。根据某些实施例的下载调度器240可以检查来自服务器s_i的最后吞吐量。在批次中，下载调度器240可以从具有较高吞吐量值的服务器请求需要较早回放的片段，例如，如下面算法1中所示。

某些实施例可以采用瓶颈检测策略来改进性能。由于下载调度器240优选地不向多于一个服务器请求相同的片段以避免资源浪费，所以瓶颈服务器可能通过引起停顿而妨碍回放体验质量(QoE)。为了避免这种情况，客户端100可以识别瓶颈服务器并且不向瓶颈服务器请求新的片段。

如果最后片段的下载吞吐量小于最低可用比特率，则下载调度器240可以将服务器视为瓶颈服务器。调度器240可以从瓶颈服务器请求已经被另一个服务器下载的冗余片段，以跟踪其当前状态。一旦瓶颈服务器的吞吐量增加超过最低可用比特率，调度器240可以继续从瓶颈服务器下载下一个非冗余片段。如前所述，只有当没有正在进行中的其它片段下载时，才可以从服务器请求片段。这避免了阻塞已经过载的服务器以及下载太多的冗余片段，并且还避免了吞吐量过高估计。

为了实施瓶颈检测策略，下载调度器240可以被给予维护下载的时间线的附加责任。参考图4解释了这种情况的一个示例。在没有瓶颈的情况下，客户端c₁和c₂并行获取片段，并且它们分别按照顺序s₁,s₂,s₃,s₂,s₁,s₃从服务器无冗余地到来。在(服务器s₂)存在瓶颈的情况下，两个客户端在下载过程期间检测服务器瓶颈，并且通过以快速吞吐量从s₁重新请求seg₃来快速反应。这引起从瓶颈服务器下载冗余的片段以跟踪其状态。

实施例可以例如通过调度器240实现如下调度策略。下载路径中的不同网络条件造成相关联的吞吐量的变化。尽管迫切地需要的片段是以贪婪方式从具有最高吞吐量的服务器下载的，但是由于动态网络条件和服务器负载，它们可能无序地到达。客户端100不应跳过片段，因此即使后续片段可用，用于回放的下一个片段的不可用性也会造成停顿。例如，在图5中，可以看出seg₄不可用，但是段seg₅和seg₆存在于缓冲器中。当客户端100完成seg₃的回放时，由于现在有效缓冲器占用率为零，因此它将停顿，直到seg₄到达。为了避免这种情况，客户端100的调度器240可以从另一服务器重新请求seg₄。优选地，对片段的重新请求不要太频繁，因为这可能导致大量的冗余片段请求。另一方面，太少的重新请求可能导致停顿。在某些实施例中，当缓冲器的连续部分下降到低于12秒时，调度器240中止正在进行的请求并重新请求丢失的片段。

客户端设备104

图19中示出了客户端设备104的示例架构。如上所述，客户端设备104能够使用标准通信协议通过网络140与系统50的其他组件，包括服务器s_i进行通信。

客户端设备104的组件可以以各种方式来配置。这些组件可以完全由将在标准计算机服务器硬件上执行的软件来实现，该标准计算机服务器硬件可以包括分布在各个位置上的一个硬件单元或不同的计算机硬件单元，标准计算机服务器硬件中的一些可能需要通信网络140来进行通信。许多组件或其部分也可以由专用集成电路(ASIC)或现场可编程门阵列实现。

在图19所示的示例中，客户端设备104可以是基于32位或64位英特尔架构的商业上可用的服务器计算机系统，并且由客户端设备104执行或进行的进程和/或方法以存储在与客户端设备104相关联的非易失性计算机可读存储装置(例如，硬盘)1924上的一个或更多个软件组件或模块1922的编程指令的形式来实现。软件模块1922的至少一些部分可替代地实施为一个或更多个专用硬件组件，例如专用集成电路(ASIC)和/或现场可编程门阵列(FPGA)。

客户设备104包括以下标准的、市售的计算机组件中的至少一个或更多个，所有这些组件都通过总线1935互连：

(a)随机存取存储器(RAM)1926；

(b)至少一个计算机处理器1928，以及

(c)外部计算机接口1930：

(i)通用串行总线(USB)接口1930a(其中至少一个连接到一个或更多个用户接口设备，例如键盘、指向设备(例如，鼠标或触摸板)1932，

(ii)网络接口连接器(NIC)1930b，其将计算机系统104连接到诸如因特网140的数据通信网络；以及

(iii)显示适配器1930c，其连接到诸如液晶显示(LCD)面板设备的显示设备1934。

客户端设备104包括多个标准软件模块，包括操作系统(OS)1936(例如，Linux或Microsoft Windows)、浏览器1938和诸如Javascript库(未示出)的标准库。操作系统1936可以包括标准组件，用于例如根据由客户端应用100从下载服务器s_i接收的数据，使得图形被渲染到显示器1934。

软件模块1922中的模块和组件之间的边界是示例性的，并且替代实施例可以合并模块或施加模块的功能的替代分解。例如，本文所讨论的模块可以被分解成子模块，以作为多个计算机进程来执行，并且可选地在多个计算机上执行。此外，替代实施例可以组合特定模块或子模块的多个实例。此外，根据本发明，操作可以被组合，或者操作的功能可以被分布在附加操作中。或者，这些动作可以在实现这些功能的电路结构中具体化，该电路结构例如复杂指令集计算机(CISC)的微代码、编程到可编程或可擦除/可编程器设备中的固件、现场可编程门阵列(FPGA)的配置、门阵列或全定制专用集成电路(ASIC)的设计等。

客户端设备104的进程的流程图的每个框可以由(软件模块1922的)模块或模块的一部分来执行。该进程可以在用于配置计算机系统以执行该方法的非瞬态机器可读和/或计算机可读介质中具体化。软件模块可以存储在计算机系统存储器内和/或传输到计算机系统存储器，以配置计算机系统来执行模块的功能。

客户设备104通常根据程序(诸如特定应用程序和/或操作系统等内部存储的指令的列表)来处理信息，并经由输入/输出(I/O)设备1930产生结果输出信息。计算机进程通常包括执行(运行)程序或程序的一部分、当前程序值和状态信息、以及操作系统用来管理进程的执行的资源。父进程可以产生其他的子进程来帮助执行父进程的整体功能。因为父进程具体地产生子进程以执行父进程的整体功能的一部分，所以由子进程(和孙子进程等)执行的功能有时可被描述为由父进程执行。

图20和21中示出了描述根据本公开的实施例的某些进程的流程图。

参考图20，在客户端设备104处实现的流处理2000在步骤2010处开始，通过客户端设备104的客户端应用100例如经由调度器240获取MPD文件。进程2000是迭代的，并且继续直到全部期望的内容已经被传送到客户端100。

MPD文件的地址可存储在使用客户端设备104的网络浏览器的用户期望在该处播放内容的网页中。MPD文件可以存储在例如任何一个可用服务器s_i上，并可以从任何一个可用服务器s_i检索。在一些实施例中，MPD文件存储在不同于存储内容的服务器s_i的服务器处。MPD文件包含关于将被流传输的内容中的片段的信息。

在步骤2020，客户端100的ABR控制器220选择将要下载的当前批次的片段的比特率。对于第一次迭代，默认比特率可以被用作起始比特率。有利地，在一些实施例中，最低可用比特率可以被选择为起始比特率，以实现快速下载和低启动延迟。对于随后的迭代，可以根据如上所述的速率适配算法来确定比特率。例如，客户端100还可以根据客户端设备104的显示适配器1930c的能力来确定可用分辨率。ABR控制器220将所选择的比特率以及如果适用的话可用的分辨率传递给调度器240。

在步骤2030，调度器240以所选择的比特率从可用服务器的至少一个子集下载片段。例如如算法1中所示以及如上所述的，下载调度器240可以从具有较高吞吐量值的服务器请求需要较早回放的段片。

在步骤2040，下载调度器240可以基于在步骤2030下载的片段来检测是否有任何服务器是瓶颈服务器。如果检测到一个或更多个瓶颈(框2045)，则在2050，下载调度器240可以从可用服务器列表中移除它们，并且开始监测任何这样的瓶颈服务器。监测可以与批处理片段下载的迭代(未示出)并行地继续。如果在监测过程期间任何瓶颈服务器再次变为可用，则可以将它们恢复到可用服务器的列表以用于后续迭代。

如果没有检测到瓶颈，则在2055，客户端100(例如，经由下载调度器240)检查内容的流传输是否完成。例如，下载调度器240可以检查片段编号是否与MPD文件中的最后片段编号匹配。如果内容没有被完全流传输，则进程2000返回到2020处的比特率选择。否则，进程2000结束。

转向图21，进程2000的比特率选择进程2020包括例如由缓冲器控制器210和/或ABR控制器220确定客户端设备100的回放缓冲器占用率的操作2110。

在操作2120处，吞吐量估计器230基于由调度器240下载的一个或更多个片段来确定估计吞吐量，并且这由ABR控制器220接收。

在操作2130处，ABR控制器220接收缓冲器占用率和估计吞吐量，并且例如通过选择比特率使得预期缓冲器松弛因子Bs最接近估计(或以其他方式获得)的缓冲器占用率B_t来确定可以优化客户端设备104的体验质量的比特率，其中B_t取决于来自不同服务器的总吞吐量。

实验评估

测试根据某些实施例配置的客户端100以评估其相对于已知客户端配置的性能。在以下讨论中，客户端被称为MSDAH。

A.方法论

网络配置文件：为了广泛测试MSDAH，采用了五种不同的服务器配置文件。服务器配置文件的参数如表II所示。从表II可以看出，每个服务器配置文件包括以服务器与服务器之间不同的方式随时间变化的吞吐量值。不同的配置文件P1至P5模拟相应服务器上的异构工作负载。P1和P4遵循上-下-上的模式，而P2和P5遵循下-上-下模式。这些配置文件采用自DASH工业(DASH-IF)论坛指南中。服务器之一被配置为瓶颈服务器，对应于配置文件P3。表II中的变化间(inter-variation)持续时间是关于流会话时间的每个不同吞吐量值的持续时间。

表II：网络配置文件的特性。

视频参数：来自DASH数据集的参考视频样本大雄兔(Big Buck Bunny，BBB)用于测试目的。它是用H.264/MPEG-4解码编码器以九个比特率级别R＝{4.2，3.5，3，2.5，2，1.5，1，0.75，0.35}Mbps以及内容分辨率L＝{240，360，480，720，1080，1920}p编码的，并且包括大约T＝600s的总视频持续时间。这些比特率级别和分辨率值对应于优兔(YouTube)中使用的质量级别。针对30s、60s和120s缓冲容量(或大小)对1s、2s和4s片段进行测试。

比较方案：为了评估性能，将MSDAH与在网络服务器NGINX中实现的四种基于CDN的负载均衡规则方案进行比较，并且可以总结如下：(a)轮询：基于轮询机制来分发对DASH服务器的请求集合。(b)最少连接：将下一个请求分配给具有低负载的DASH服务器。因此，该方案试图不使具有许多请求的繁忙的服务器过载。(c)会话持续性：除了当该服务器停机时，该方案总是将来自同一客户端的请求定向到同一DASH服务器。为了实现这一点，它使用哈希函数来确定选择哪个服务器用于下一请求。(d)加权：该方案为每个DASH服务器分配权重，并且该权重被用于负载均衡器决策。例如，如果用于服务器的权重等于三，则负载均衡器将三个请求定向到该服务器。

实验装置：使用与DASH-IF指南、片段持续时间(即，1s、2s和4s)、QoE度量(即，平均比特率、比特率切换、启动延迟和停顿)、DASH客户端和DASH服务器的数量不同的真实世界网络配置文件(即，吞吐量可变性)，来执行一组真实的跟踪驱动点播(VoD)视频流实验。实验装置包括运行用于DASH客户端、DASH服务器和日志记录的Ubuntu 16.04LTS的七台机器。一台机器是具有30GB RAM、核心i7 CPU和两个GPU GeForce GTX 295的服务器站。服务器站运行五个虚拟机VM，每个VM代表DASH服务器，该DASH服务器托管视频并运行简单的阿帕奇(Apache)HTTP服务器(v2.4)。具有4GB RAM和核芯i7 CPU的五个机器充当DASH客户端，每个机器运行Google Chrome浏览器以托管修改的基于dash.js的播放器(图2中所示的MSDAH播放器)。所有机器经由D链路千兆交换机连接，并且使用tc-NetEm网络仿真器，特别是分层令牌桶(Hierarchical Token Bucket，HTB)连同随机公平队列(Stochastic FairnessQueuing，SFQ)排队，以根据上述网络配置文件形成DASH客户端和服务器之间的链路的总容量。MSDAH考虑来自所有服务器的最后测量的吞吐量的总带宽。最大回放缓冲器容量(K)分别针对1s、2s和4s的段持续时间被设置为30s、60s和120s。下溢预防阈值被设置为8s。

B.实施方案

所提出的方法被实施为对dash.js v2.6.6的修改。特别地，对可扩展超文本传输请求(XMLHttpRequest)、基于URL的选择器(BaseURLSelector)以及如何在调度控制器(SchedulerController)中调度片段进行修改，以便利用多个下载源。上述速率适配算法也作为规则被添加到ABR控制器(ABRController)中。

具体地，参考图6，将以下功能添加到DASH参考播放器dash.js：

(a)调度控制器240：基于由速率适配算法选择的比特率和由基于URL的选择器620给出的下一个可用服务器，来一次控制和生成多个请求。然后，它将该请求置于可扩展超文本传输请求610中，以从相应的服务器请求片段。

(b)基于URL的选择器620：从清单属性(Manifest attribute)630获得现有服务器的URL，根据它们的最后吞吐量来分类，以决定用于下载该片段的下一服务器。

(c)可扩展超文本传输请求610：通过添加HTTP请求(addHttpRequest)和修改请求报头(modifyRequestHeader)的方法以适当的xhr格式准备由调度控制器240给出的请求。然后，它经由HTTPGET(即xhr.send())并行地向不同的DASH服务器发送多个请求，并接收相应片段的响应。

(d)ABR控制器220：实施一组比特率决策规则，以选择将要下载的分别考虑由缓冲器控制器(BufferController)210和吞吐量估计器(ThroughputEstimator)230给出的缓冲器占用率和总吞吐量的下一个并行片段的适当比特率。ABR规则224实现上述速率适配算法，并且负责基于来自服务器的吞吐量来执行ABR决策。然后，它将这样的比特率决策传递给调度控制器240，并且将服务器的排序顺序传递给基于URL的选择器620。ABR控制器220可以包括用于(例如，经由等式(3))确定比特率的获取质量(getQuality)函数222。

性能度量：为了评价性能，使用以下QoE度量。使用DASH客户端播放的平均比特率来测量总体质量。还对表示变化的数量及其大小进行计数。测量回放停顿持续时间和停顿发生的次数。性能度量对QoE的总体影响可以通过以下模型来概括：

这里，DASH客户端所播放的Z片段的QoE是它们的总计比特率f(R_t)、以及相邻的播放片段f(R_t+1)-f(R_t)之间的差的大小、启动延迟T_s和总回放停顿T_stall的函数。f是恒等函数，λ＝1，α和α_s是最大表示比特率。

C.结果和分析

下面描述的实验结果包括一组轨迹驱动和真实世界的测试用例。测试用例被分成如下所示的五个场景。实验结果表明，MSDAH可以显著提高观看者的QoE，并且在所有考虑的场景中传递高质量视频。

场景1(单个服务器DASH相对MSDAH)：在第一测试中，一个客户端从单个服务器请求针对五个不同网络配置文件P1至P5的视频片段。这与五个不同客户端从所有五个服务器s₁至s₅请求具有相应网络配置文件P1至P5的视频片段的情况进行比较。该思想是将五个客户端的一对一客户端-服务器关系的性能与所有客户端通过使用所提出的MSDAH解决方案来使用所有服务器时的性能进行比较。

图7示出了在整个会话期间播放的平均比特率。当一个客户端仅向一个服务器请求视频片段时，客户端在具有不同缓冲器大小的配置文件P1至P5下经历2.9Mbps至4Mbps的平均比特率。配置文件P4下的性能优于所有其它配置文件，因为它具有最高吞吐量并以最高值开始。连接到具有配置文件P4的服务器的客户端针对缓冲器大小30s、60s和120s分别经历平均比特率3.8、3.9和4.1Mb。然而，对于所有客户端共享具有这五个不同网络配置文件的五个服务器的MSDAH，客户端针对缓冲器大小30s、60s和120s分别平均经历4.0、4.0、3.9Mbps的平均比特率。

类似地，如图8所示，在一对一客户端-服务器架构下，针对不同的缓冲器容量，表示变化的数量从3变化到37。针对30s和60s缓冲器，对于配置文件P3，客户端经历了表示变化的最少数量(即15和7)。对于P4，针对120s缓冲器容量，表示变化的最少数量是3。针对相应缓冲器容量(30s、60s和120s)，MSDAH优于所有它们(所有5个客户端)平均经历13.8、3.4和3的表示变化。

即使具有配置文件P3的服务器具有瓶颈，MSDAH也能没有停顿地更好地执行。如图9所示，仅向具有配置文件P3的服务器请求的客户端针对30s和60s缓冲容量经历10s和64s停顿，并分别停顿两次和三次。

图7中的小误差条示出了MSDAH在客户端之间关于播放的平均比特率方面非常公平。尽管对于MSDAH，针对30s缓冲器容量的表示变化的数量的误差条相对较大，但是表示变化的平均数量仍然小于一对一客户端-服务器架构中的客户端的表示变化的平均数量，如图8所示。

为一对一服务器架构中的客户端计算如上所述的QoE分数，该客户端连接到具有配置文件P1到P5的服务器，并且为运行MSDAH的客户端计算QoE分数。结果如图10所示。可以看出，具有MSDAH的客户端具有2.35至2.41(×100)的QoE评分。针对30s的缓冲容量，MSDAH比一对一客户端-服务器架构中的MSDAH好至少3％且高达40％；并且针对60s的缓冲容量，MSDAH比一对一客户端-服务器架构中的MSDAH要好至少3.4％且高达40％。针对120s缓冲容量，QoE与P4的最近值相当，以及比P2的最小值好23％。

场景2(基于CDN的负载均衡规则相对MSDAH)：为了检查MSDAH在真实世界网络环境中的鲁棒性，将MSDAH与目前实现的基于CDN的负载均衡规则方案进行比较。运行具有五个不同网络配置文件(P1至P5)的五个服务器，并且由五个并存客户端共享。每个配置文件用于节制DASH服务器和该组客户端之间的总容量。

图11描绘596s的视频流会话期间播放的平均比特率。在所有缓冲器大小配置中，可以看出，与其它基于CDN的负载均衡规则方案相比，MSDAH对于所有五个客户端实现了范围从3.7Mbps到4Mbps(对于所有缓冲器容量配置，平均3.9Mbps)的最佳和最稳定的平均比特率，并且表示变化最少，如图12所示。而且，分别针对30s、60s和120s，MSDASH确保平均比特率在所有客户端之间以0.2Mbps、0.15Mbps和0.3Mbps的变化公平分布。此外，两个重要的观察是(i)CDN最少连接方案在MSDAH之后实现平均比特率的第二最佳结果，以及(ii)CDN持久性方案与其他方案相比得到最差的结果。这是因为CDN最少连接方案应用了有效的请求策略，该策略根据DASH服务器的容量在DASH服务器上分配DASH客户端请求。这种策略将请求发送到更快地执行请求的功能强大的服务器，并且减轻了瓶颈服务器的负面影响。然而，CDN持久性方案在客户端和服务器之间创建固定关联(哈希值)，其中来自给定哈希值的所有请求总是被转发到同一服务器。因此，连接到瓶颈服务器的客户端将总是接收低比特率，并且这影响所有客户端的平均结果。与基于CDN的负载均衡规则相反，MSDAH利用所有现有DASH服务器，并从所有DASH服务器并行下载。它通过智能瓶颈检测策略(参见上文)成功地检测瓶颈服务器，并且因此它避免了从这个服务器请求。

类似地，如图12、13和14所示，在所有缓冲器容量配置中，MSDAH与基于CDN的负载均衡规则方案相比，实现了具有零停顿(并且因此零停顿持续时间)的、表示非常低的平均变化数量和启动延迟的最佳平均QoE(使用等式(4)计算)。与经历了对于所有缓冲器容量配置而言平均1.4到1.9的范围的QoE的CDN最少连接方案、经历了对于所有缓冲器容量配置而言平均0.43到0.73的范围的QoE的CDN持久性方案、经历了对于所有缓冲器容量配置而言平均1.05到1.14的范围的QoE的CDN轮询方案和经历了对于所有缓冲器容量配置而言平均1.11到1.56的范围的QoE的CDN加权方案相比，MSDAH中的客户端经历了对于所有缓冲器容量配置而言平均2.35到2.41(×100)范围的高QoE。对于基于CDN的规则，除了获得零停顿的CDN持久性方案之外，表示改变的平均数量、停顿和停顿持续时间是高的。

基于CDN的方案经历了低平均QoE。值得注意的是，CDN轮询方案遭受具有长持续时间的许多停顿，因为该方案使用轮询机制来分发请求。因此，(由于轮询方案不可避免地要从瓶颈服务器下载)在瓶颈服务器的轮次期间，客户端需要花费长时间来下载片段，从而导致视频停顿。

场景3(因特网数据集测试)：通过在真实世界的因特网上进行一组实验来研究MSDAH的性能。使用分布式DASH数据集；分布式DASH数据集由位于不同地理区域(法国、澳大利亚和意大利)的三个服务器处镜像的数据组成。以17个比特率级别R＝{0.1,0.15,0.2,0.25,0.3,0.4,0.5,0.7,0.9,1.2,1.5,2,2.5,3,4,5,6}Mpbs进行编码的6分钟视频以2s和4s的片段持续时间进行流传输。五个客户端在两种测试场景中运行：(i)所有客户端并行地开始视频会话，以及(ii)客户端在彼此之后以Δt＝60秒的间隔递增地开始。图15表示针对在两个测试中运行五个客户端的2s和4s片段持续时间的比特率变化的数量来绘图的、由MSDAH选择的平均比特率。它示出了大多数时间客户端通过从2或3个服务器并行下载视频片段来选择最高6Mbps的比特率。同样，在两个测试中，表示变化的数量是5-10。从这种场景可以得到两个重要的观察结果。首先，当服务器的数量增加时，客户端实现更好的性能。与使用两个服务器的客户端相比，一起利用三个服务器的五个客户端实现了所选择的比特率的大约10％的改进，并且需要少25％的比特率变化。第二，当客户端在不同时间开始和结束时，则与它们一起运行时相比，它们获得更公平的带宽份额，并且因此在第二测试中实现更好的性能。

场景4(MSDAH的公平性)：为了比较MSDAH客户端与单个服务器客户端的公平性，运行两个测试用例，如图16所示：(a)同时运行两个客户端、一个MSDAH客户端(利用配置文件P1-P5共享五个服务器)和一个单个DASH客户端(利用配置文件P4连接到服务器)，(b)利用配置文件P4共享服务器的两个单个DASH客户端。可以看出，当MSDAH客户端与单个DASH客户端一起运行时是友好的，并且它与单个DASH客户端同等地共享可用带宽(TCP公平共享)。在流会话期间，MSDAH客户端以最高和最稳定的可能可用比特率(3.9-4.2Mbps)播放视频，表示变化较少(对于所有缓冲器容量配置为平均5次变化)并且没有任何停顿。这是因为MSDAH受益于所有现有服务器，因此MSDAH的缓冲器占用率在所有(切换到OFF状态，见图16(c)和16(d))缓冲器配置中都经常达到最大容量。与图16(b)中的客户端(2.7-4Mbps)相比，这为单个DASH客户端提供了更公平的共享带宽，以改进其比特率选择(3.7-4Mbps)，如图16(a)所示。

场景5(大规模部署MSDAH)：为了评价MSDAH的可扩展性，在https://ncl.sg的NCL测试台中进行三个真实世界测试用例实验。这些实验包括100个客户端(通过GoogleChrome渲染视频)、4个具有不同配置文件的DASH服务器、以及单个瓶颈链路的各种总的最后一英里带宽组成。为了模拟真实世界的网络环境，使用NCL测试台提供的现实网络拓扑，并且将MSDAH的性能与基于CDN的负载均衡规则方案(轮询、最少连接、持久性连接和加权)进行比较。测试用例的配置定义如下：(a)共享总带宽为300Mbps的瓶颈网络的100个客户端和四个具有网络配置文件(60，70，80和90Mbps)的服务器{s₁,...,s₄}(图18(a))；(b)100个客户共享总带宽为350Mbps的瓶颈网络和四个具有网络配置文件(60，70，80和140Mbps)的服务器{s₁,...,s₄}(图18(b))；(c)100个客户共享总带宽为400Mbps的瓶颈网络和四个具有网络配置文件(60，70，80和190)Mbps的服务器{s₁,...,s₄}(图18(c))。在加权负载均衡规则的情况下，四个服务器{s₁,...,s₄}分别被分配权重1、2、3和4。结果表明，对于不同的缓冲器配置，MSDAH客户端选择具有高公平性(参见图18中的误差条)、最高QoE和最少表示变化的最佳和最稳定的可能比特率。加权负载均衡规则在平均比特率方面对于120s缓冲器容量具有与MSDAH相当的性能，因为向具有最高吞吐量的服务器分配了更高的权重。对于导致整体QoE降低的加权负载均衡规则，表示变化也较高。MSDAH的小误差条也表示对大量客户端的公平性更高。100个客户端以它们之间的0.5秒的间隔(第一和最后之间的50秒的总间隔)顺序地开始，因此在用于MSDAH的一些情况下的平均比特率和加权负载均衡规则略高于三种测试情况下的300Mbps、350Mbps和400Mbps的全容量。

本公开的实施例在鲁棒性方面具有优于现有技术方法的若干优点。例如，本实施例是高度容错的。在如现有技术的单个服务器DASH传送系统中，严重故障模式是当客户端由于诸如服务器瓶颈、不可靠的链路、故障服务器或网络条件的突然波动而不再能够与DASH服务器通信的时候。在这种情况下，基于CDN的解决方案可能有帮助，但是它们已经被示出引入了延迟(即DNS重定向)，这可能损害播放器缓冲器占用率并且负面地影响最终用户QoE。然而，本发明的实施例通过利用多个服务器且由于上文详述的稳健且智能的瓶颈检测策略而避免受影响的链路或服务器来解决这些问题。如果客户端不能到达服务器，则客户端将自动忽略从服务器下载下一个片段，而只使用其余服务器。此外，客户端通过尝试再次与下行服务器连接或者如果服务器被认为是瓶颈则下载已经播放的片段来周期性地保持跟踪下行服务器的状态。

在一些情况下，诸如当多个客户端开始竞争共享网络环境(例如，最后一英里网络)中的可用带宽时，可能发生客户端侧瓶颈。针对最后一英里瓶颈的情况测试MSDAH和基于CDN的负载均衡规则的性能，其中在所有五个服务器处不存在业务整形，但所有五个服务器和客户端共享15Mbps的共同链路。在这种情况下，所有五个客户端对于MSDAH以及对于所有基于CDN的负载均衡规则都平均以3Mbps播放视频。

在存在瓶颈服务器的情况下，单个服务器DASH客户端将遭受停顿和频繁的比特率变化，这导致了差的观看者QoE。相反，本公开的实施例使用多个服务器，并且能够基于简单个的启发法(例如，如果下载吞吐量小于最低可用比特率，则实施例可以将服务器视为瓶颈)来有效地检测可能影响观看者QoE的服务器瓶颈，例如如上所述。

但是应当理解，对所述实施例的各个方面的许多进一步的修改和置换是可能的。因此，所描述的方面旨在涵盖落入所附权利要求书的精神和范围内的所有此类变更、修改和变化。

在整个说明书和随后的权利要求书中，除非上下文另有要求，词语“包括”及其变体如“包含”和“含有”应理解为暗示包括所述的整体或步骤或整体或步骤的组，但不排除任何其它整体或步骤或整体或步骤的组。

本说明书中对任何现有出版物(或从其衍生的信息)或任何已知内容的引用不是并且不应被认为是对现有出版物(或从其衍生的信息)或已知内容形成本说明书所涉及的领域中的公知常识的一部分的承认或认可或任何形式的建议。