CN112690005A - 用于流传输内容的方法和设备 - Google Patents

用于流传输内容的方法和设备 Download PDF

Info

Publication number
CN112690005A
CN112690005A CN201980060169.7A CN201980060169A CN112690005A CN 112690005 A CN112690005 A CN 112690005A CN 201980060169 A CN201980060169 A CN 201980060169A CN 112690005 A CN112690005 A CN 112690005A
Authority
CN
China
Prior art keywords
servers
download
bottleneck
server
segments
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN201980060169.7A
Other languages
English (en)
Inventor
阿卜杜勒哈克·班他列
普拉文·库玛·亚达夫
罗杰·齐默尔曼
黄玮璨
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
National University of Singapore
Original Assignee
National University of Singapore
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by National University of Singapore filed Critical National University of Singapore
Publication of CN112690005A publication Critical patent/CN112690005A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
    • H04N21/4622—Retrieving content or additional data from different sources, e.g. from a broadcast channel and the Internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/23439—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements for generating different versions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26258—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists for generating a list of items to be played back in a given order, e.g. playlist, or scheduling item distribution according to such list
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/437—Interfacing the upstream path of the transmission network, e.g. for transmitting client requests to a VOD server
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/44004—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving video buffer management, e.g. video decoder buffer or video display buffer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
    • H04N21/44209—Monitoring of downstream path of the transmission network originating from a server, e.g. bandwidth variations of a wireless network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Databases & Information Systems (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

一种在客户端设备处执行的流传输远程定位的内容的方法，包括：与多个服务器通信，该多个服务器中的每一个托管该内容的多个副本，该副本以不同的相应比特率被编码并且每一个该副本被划分成根据时间序列布置的多个片段；以及从至少是该多个服务器的子集的一组下载服务器请求并行下载片段集合，其中，从该组下载服务器的不同服务器下载该集合中的相应片段，该片段在该时间序列中是连续的。

Description

用于流传输内容的方法和设备
技术领域
本公开涉及用于流传输内容的方法和设备。
背景技术
随着高速和高带宽因特网连接的可用性的提高，如今流服务几乎无处不在。例如，超文本传输协议(HTTP)自适应输(HAS)由于其经由传统HTTP服务器传送高质量流的能力而被许多这样的流服务使用。据认为，到2021年，HAS系统将主导因特网流量。
视频网络流量的增加对维持用户体验的质量产生了挑战。提出的一种解决这个问题的方法是在HTTP动态自适应流(DASH)框架中实现的。利用DASH，客户端通常一次访问一个服务器，并且如果出现网络瓶颈(bottleneck)，则仅经由DNS重定向来重定向到另一服务器。可用的媒体比特率级别和分辨率是离散的。共享过载的服务器或瓶颈链路的客户端将其自身限制到低比特率级别以避免回放停顿。相反，碰巧能够访问较少负载的服务器的客户端可以实现高得多的视频质量，使得体验质量(QoE)可以在客户端之间广泛地变化。
DASH由于其自适应比特率(ABR)方案而动态地适应于网络条件，该自适应比特率(ABR)方案基于如吞吐量测量、回放缓冲器占用率或二者的组合的启发法。此外，由于DASH使用HTTP，所以它使得内容提供商能够使用现有的内容分发网络(CDN)基础设施，并且简化了通过网络中间盒(middleboxes)的遍历。最后，它是高度可扩展的，并且DASH客户端可以请求和获取视频片段，使用无状态DASH服务器以分散的方式独立地维持它们的本地回放状态。
DASH系统包括两个主要实体：DASH服务器和DASH客户端。DASH服务器存储被分成小的固定片段(2-15秒)的视频，并且以各种比特率级别和分辨率编码每个片段。然后，在媒体呈现描述(MPD)中列出每个视频的片段，媒体呈现描述还包括片段持续时间、编解码器/加密细节和音轨对应关系(音频和字幕)的元数据信息。在认证阶段之后，客户端首先获取要观看的视频的MPD文件，然后基于其ABR控制器决策来顺序地请求片段。DASH服务器通过经由HTTP发送所请求的片段来响应。ABR控制器实施各种启发法以决定为下一个片段选择的比特率。因此，在网络吞吐量变化和缓冲器占用率改变的情况下，它在可用的比特率之间切换。
在DASH传送系统中，每个DASH客户端通过做出可以适应基础网络条件而不引入停顿的最佳比特率决策来努力改进其QoE。比特率决策是使用ABR逻辑来执行的，ABR逻辑依赖于吞吐量估计和缓冲器占用率测量。然而，在使用DASH的现有网络基础设施中选择正确的决策是困难的，这至少是由于两个原因：
·带宽不足：DASH流量的渐增的数量和用户对更高视频质量的需求的不断增长已经导致了带宽的爆炸性消耗。在标准DASH中，由于频繁拥塞，在现有带宽受限网络上实现高QoE是非常具有挑战性的。由于DASH客户端竞争可用带宽而发生拥塞。这种竞争导致视频不稳定、停顿、长启动延迟以及质量的许多变化，并且因此显著影响用户体验。视频内容的高流量负载通常基于某种重定向策略(基于CDN的负载均衡规则)在CDN之间共享。在这种系统中，DASH客户端每次仅使用一个节点，并且如果基于由内容提供商决定的策略检测到瓶颈，则连接到新节点。连接到更多过载节点的客户端获得较低的吞吐量份额，从而导致不公平性。
·服务器侧瓶颈：在标准DASH解决方案中，通常仅考虑一个服务器用于由给定基本URL确定的顺序片段传送(即，仅在当前片段完全下载时才可下载下一个片段)。这种一次一个片段的机制代表在服务器侧存在瓶颈的情况下的弱点。如果经编码的分段的最小比特率高于瓶颈链路的吞吐量，则该问题恶化。服务器瓶颈问题导致增加的停顿、视频不稳定性、比特率的频繁改变以及不公平性。先前提出的系统试图使用简单的网络度量(例如，时延、下载时间、吞吐量)来识别瓶颈，然后基于网络度量来选择适当的服务器。然而，这些提议：(i)不适应于现有的DASH传送系统，或(ii)需要在网络侧进行修改，或(iii)不可扩展(即，每个客户端需要向网络控制器报告其状态)。
即使在存在基于CDN的重定向策略的情况下，上述因素也会对DASH的观看者的QoE产生负面影响，并且在存在瓶颈的情况下，问题会恶化。
对服务器的客户端请求可以是基于顺序的或基于并行的。
在基于顺序的方法中，调度器在顺序的基础上一个接一个地请求视频片段，并且直到所请求的一个片段被完全下载，下一个片段才能被下载。客户端的ABR控制器可以使用基于速率的、基于缓冲器的或基于混合的启发法来用于调度目的。
在基于并行的方法中，调度器同时从不同的视频服务器并行地请求和下载多个片段。在大多数情况下，这需要在应用层和传输层中进行内核或网络功能修改。例如，一些提议包括利用客户端中采用的多个网络接口(例如，WiFi和蜂窝)和MPTCP协议来从不同的接入网络下载。Queyreix等人(IEEE CCNC，第580-581页，2017)已经提出了另一种基于并行的实施方案，并且该实施方案被称为MS-流(HTTP上的多源流)。MS-流是用于DASH的实用地演变的基于HAS的流解决方案，基于HAS的流解决方案使用多个定制的服务器来改善终端用户QoE。尽管MS-流在传送高质量视频方面显示出良好的性能，但是所提出的解决方案具有一些限制：(i)它使用多描述编码(MDC)来编码视频，现在这是不标准的；(ii)该实施方案需要在每个服务器处的特定API，该特定API不符合DASH标准；(iii)存在在播放之前组合内容的时间开销，这对于标准QoS和QoE可能是不可接受的；(iv)因特网上现有的DASH存储服务器和CDN架构需要修改，该修改可能是重大的；以及(v)下载的所有内容都是不可播放的，并且存在显著的开销，使得来自多个服务器的总吞吐量没有被完全利用。
本公开的实施例试图克服或减轻一个或更多个上述困难，或至少提供有用的替代方案。
发明内容
本公开提供了一种在客户端设备处执行的流传输远程定位的内容的方法，包括：
与多个服务器通信，该多个服务器中的每一个托管内容的多个副本，所述副本以不同的相应比特率被编码并且每一个该副本被划分成根据时间序列布置的多个片段；以及
从至少是多个服务器的子集的一组下载服务器请求并行下载片段集合，
其中从该组下载服务器中的不同服务器下载该集合中的相应片段，所述片段在时间序列中是连续的。
该方法还可以包括监测客户端设备的回放缓冲器占用率。在某些实施例中，该方法包括基于客户端设备的回放缓冲器占用率和/或该组下载服务器的估计吞吐量来选择下载片段的比特率。
该方法可以包括识别多个服务器中的一个或更多个瓶颈服务器；以及从该组下载服务器中临时移除一个或更多个瓶颈服务器。一些实施例还可以包括通过从一个或更多个瓶颈服务器请求下载已经从该组下载服务器中的服务器下载的片段，来监测一个或更多个瓶颈服务器的吞吐量状态。该方法可以包括响应于瓶颈服务器吞吐量状态超过比特率阈值，将瓶颈服务器恢复到该组下载服务器。
服务器可以是DASH服务器。
本公开还提供了一种用于流传输远程定位的内容的客户端设备，包括：
至少一个处理器，该至少一个处理器与计算机可读存储装置通信，该计算机可读存储装置上存储有指令，该指令在由该至少一个处理器执行时使该客户端设备：
与多个服务器通信，多个服务器中的每一个托管该内容的多个副本，所述副本以不同的相应比特率被编码并且每一个被划分成根据时间序列布置的多个片段；以及
从至少是多个服务器的子集的一组下载服务器请求并行下载片段集合；
其中从该组下载服务器中的不同服务器下载该集合中的相应片段，所述片段在该时间序列中是连续的。
指令可进一步包括当由至少一个处理器执行时使得客户端设备监测客户端设备的回放缓冲器占用率的指令。该指令还可以包括当由至少一个处理器执行时使得客户端设备基于客户端设备的回放缓冲器占用率和/或该组下载服务器的估计吞吐量来选择下载片段的比特率的指令。
指令可进一步包括在由至少一个处理器执行时使客户端设备进行以下操作的指令：识别多个服务器中的一个或更多个瓶颈服务器；以及从该组下载服务器中临时移除一个或更多个瓶颈服务器。
指令可进一步包括在由至少一个处理器执行时使客户端设备进行以下操作的指令：通过从一个或更多个瓶颈服务器请求下载已经从该组下载服务器中的服务器下载的片段，来监测一个或更多个瓶颈服务器的吞吐量状态。指令可进一步包括当由所述至少一个处理器执行时，使客户端设备响应于瓶颈服务器的吞吐量状态超过比特率阈值，将瓶颈服务器恢复到该组下载服务器的指令。
本公开还提供了一种非易失性计算机可读存储介质，该非易失性计算机可读存储介质上存储有指令，该指令在由客户端设备的至少一个处理器执行时，使客户端设备执行如本文所公开的方法。
本公开还提供了一种用于从多个服务器流传输远程定位的内容的计算设备，多个服务器中的每一个托管内容的多个副本，所述副本以不同的相应比特率被编码并且每一个被划分成根据时间序列布置的多个片段，客户端设备包括：
下载调度器，该下载调度器被配置为从至少是多个服务器的子集的一组下载服务器请求并行下载片段集合，
其中，下载调度器被配置为从该组下载服务器中的不同服务器下载该集合中的相应片段，所述片段在时间序列中是连续的。
实施例还可以包括缓冲器控制器，该缓冲器控制器被配置为监测计算设备的回放缓冲器占用率。
实施例还可以包括自适应比特率控制器，该自适应比特率控制器被配置为：与缓冲器控制器通信以接收回放缓冲器占用率；以及基于计算设备的回放缓冲器占用率和/或该组下载服务器的估计吞吐量来选择下载片段的比特率。
某些实施例可以包括用于确定该组下载服务器的估计吞吐量的吞吐量估计器。
下载调度器可以被配置为：识别多个服务器中的一个或更多个瓶颈服务器；以及从该组下载服务器中临时移除一个或更多个瓶颈服务器。下载调度器还可以被配置为：通过从一个或更多个瓶颈服务器请求下载已经从该组下载服务器中的服务器下载的片段，来监测一个或更多个瓶颈服务器的吞吐量状态。在一些实施例中，下载调度器被配置为响应于瓶颈服务器的吞吐量状态超过比特率阈值，将瓶颈服务器恢复到该组下载服务器。
附图说明
现在将参考附图仅通过非限制性示例的方式描述本公开的实施例，在附图中：
图1示出了用于流传输内容的系统的示例架构的概述；
图2示出了流客户端的实施例的详细架构；
图3示出了用于流客户端的实施例的队列模型的示例；
图4示意性地描述了具有和不具有瓶颈的片段调度；
图5示意性地描绘了在无序片段到达的情况下的调度策略；
图6示出了基于dash.js的播放器的示例架构；
图7是当客户端连接到具有不同配置文件(P1-P5)的服务器时并且当所有客户端共享用于不同缓冲器容量配置(30、60和120)s的所有服务器时客户端的平均比特率的条形图；
图8是当客户端连接到具有不同配置文件(P1-P5)的服务器时并且当所有客户端共享用于不同缓冲容量配置(30、60和120)s时的所有服务器(MSDAH)时表示变化(changesin representation)的平均数量的条形图；
图9示出了当客户端连接到具有不同配置文件(P1-P5)的服务器时以及当所有客户端共享用于不同缓冲容量配置(30、60和120)s的所有服务器(MSDAH)时的停顿持续时间和停顿数量；
图10示出了当客户端连接到具有不同带宽(P1-P5)的服务器时以及当所有客户端共享具有用于不同缓冲器容量配置的不同带宽的所有服务器(MSDAH)时的平均QoE；
图11示出了与基于CDN的负载均衡规则相比，本公开的实施例的平均比特率；
图12示出了与基于CDN的负载均衡规则相比，本公开的实施例的表示变化的平均次数；
图13示出了与基于CDN的负载均衡规则相比，本公开的实施例的平均QoE；
图14示出了与基于CDN的负载均衡规则相比，本公开的实施例的停顿持续时间和停顿数量；
图15示出了对于5个客户端一起开始并且具有60s的间隔的2秒和4秒的片段持续时间的平均比特率和质量变化；
图16示出了根据本公开的实施例的客户端与单个服务器客户端的比特率公平性比较。(a)一个MSDAH客户端和一个单个服务器客户端；(b)共享同一服务器的两个单个服务器客户端；(c)单个服务器DASH(左)和MSDAH(右)的随时间的比特率；(d)单个服务器客户端1(左)和客户端2(右)的随时间的比特率；
图17示出了具有用于30秒缓冲器容量的不同片段持续时间的本发明的实施例的性能比较；
图18示出了与使用基于CDN的负载均衡规则的客户端相比，对于本公开的实施例的具有不同的总带宽(300、350和400Mbps)和缓冲器容量配置(30、60和120)的100个客户端的平均比特率、表示变化和QoE。(a)共享具有300Mbps的总带宽的瓶颈网络的100个客户端和具有固定网络配置文件(60、70、80和90Mbps)的4个服务器；(b)共享具有350Mbps的总带宽的瓶颈网络的100个客户端和具有固定网络配置文件(60、70、80和140Mbps)的4个服务器；(c)共享具有400Mbps的总带宽的瓶颈网络的100个客户端和具有固定网络配置文件(60、70、80和190Mbps)的4个服务器；
图19示出了客户端设备的示例架构；
图20是根据某些实施例的流处理的示例的流程图；以及
图21是比特率选择过程的示例的流程图。
具体实施方式
本公开的实施例涉及一种流传输远程定位的内容的方法，并且涉及一种被配置为执行该方法的客户端设备。在本文的至少一些实施例中作为MSDAH(多服务器DASH)被提及。
在本公开的实施例中，多个客户端可以并行地共享多于一个服务器。服务器的共享使得实现统一的QoE，并且瓶颈链路或过载的服务器不会对客户端产生局部影响。当前公开的实施例的功能在客户端侧的应用层中以分布式方式实现，并且例如可以是现有DASH客户端侧架构的修改版本。因此，当前公开的实施例不需要对内核或网络功能进行任何修改，该修改包括传输层修改。如下面将详细描述的，已经发现本公开的实施例可以显著地改善流传输性能，包括以下改进：
·与从单个服务器的顺序下载相比，在客户端之间具有小于1％的变化的高于33％的QoE。
·针对服务器瓶颈和可变网络条件的高鲁棒性。目前提出的解决方案没有过度利用可用带宽，并且在大多数情况下，附加数据开销是针对10分钟视频回放的媒体数据的附加片段下载。
·显著优于顺序的单个服务器DASH和基于CDN的负载均衡规则，包括：轮询调度、最少连接、会话持续性和加权。
有利地，本公开的实施例通过首先确定瓶颈或故障服务器来有效地处理瓶颈；停止从所述确定的瓶颈服务器请求未来片段；并且例如通过基于探针的被动或主动测量，来周期性地监测瓶颈服务器的状态以发现任何变化(例如，它可以再次变成健康服务器)。
另外，当前公开的实施例提供了比现有技术方法更公平和更高的QoE，并且通过利用来自具有不同容量的多个服务器的扩展带宽和链路分集来达到最佳比特率。本公开的实施例提供了一种纯客户端驱动的解决方案，其中修改被限制到客户端侧的应用。因此，网络和服务器侧保持不变，使得实施方案不太复杂并且不太容易出错。
在本公开中，使用以下符号和缩写。
表I：关键符号和记号的列表。
Figure BDA0002975778620000081
Figure BDA0002975778620000091
本公开的实施例在客户端设备处实现比特率选择过程，该比特率选择过程由客户端设备的回放缓冲器占用率、客户端设备可以从其请求数据片段的一组服务器的估计吞吐量、或者该组服务器的回放缓冲器占用率和估计吞吐量的组合来支配。
图1中示出了用于流传输内容的系统50的一种可能的架构。在计算设备(诸如移动设备102、膝上型计算机104或台式计算机106)上执行的客户端100能够经由诸如因特网140之类的广域网连接到多个服务器以请求数据。在图1所示的示例中，系统50包括六个服务器(分别标记为s1至s6)，但是可以设置更少或更多的服务器。在一些实施例中，可以部署数十或者甚至数百个服务器作为系统50的一部分。通常，服务器si将是客户端100可以连接到的DASH服务器，并且可以经由HTTP GET请求来请求内容，并且客户端100可以被实现为例如dash.js参考播放器的修改版本。
通常，服务器si通常经由因特网140连接来镜像由内容提供商110提供的数据。诸如过顶(OTT)服务120的其它参与方也可以给服务器si提供内容以供客户端100进行流传输。
根据当前公开的实施例的客户端100并行请求来自所有可用服务器si的至少一个子集，优选地是可用服务器si的所有子集的不同片段，以最大化多个服务器的吞吐量。例如，如图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可预测来自服务器si的分段的下载吞吐量，并提供该估计至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来选择适当的比特率ri，该比特率ri适应于回放缓冲器占用率和每个源si的下载吞吐量，其中i∈[1,...,M]，M表示现有服务器的总数。然后，客户端100可以(经由调度器240)同时从M个服务器si请求多个连续的片段。当缓冲器控制器210监测的回放缓冲器达到其最大容量K时，客户端100可(经由缓冲器控制器210)触发停止下载的事件，并将服务器的数量逐渐减少为单个服务器，以避免缓冲器溢出。每当存在容纳片段的空间时，即当没有达到最大缓冲器容量时，可以增加所使用的服务器的数量，直到服务器的数量达到M。
在一些实施例中，系统50可通过用有向或无向图G＝(V,E)表示来建模，其中V＝C∪S是客户端C＝{c1,...,cN}和服务器S＝{s1,...,sM}的集合。为了建模的目的，可以假设全网状网络，即，胖树(Fat-Tree)拓扑(例如，OSPF网状网络)，其中，每个客户端cj∈C具有到每个si∈S的连通性，其中j＝[1...N]并且i＝[1...M]，并且因此客户端100使用不同的多个链路从现有服务器同时获取连续的片段。
当回放缓冲器变满时，客户端100停止下载片段，并将所使用的服务器的总数逐渐减少到一个。否则，如果在回放缓冲器中有空间，客户端100可以增加服务器的数量，直到它利用所有现有的服务器(全服务器利用)。
由于拥塞和网络可变性，在任何时候，到服务器si的链路可能变慢，并且服务器将被认为是瓶颈服务器。在这种情况下，由于来自瓶颈服务器的延迟片段导致客户端回放缓冲器的耗尽，因此客户端100遭受延迟。为了避免这个问题，在某些实施例中，客户端100可以停止从瓶颈服务器获取未来的片段，而是仅从M-H个剩余的服务器获取未来的片段，其中H是瓶颈服务器的总数。每个客户端100可以通过请求具有最低质量的先前片段来跟踪瓶颈服务器的状态，并且一旦瓶颈服务器可以提供服务并且再次满足客户端要求，则恢复瓶颈服务器的使用。
在某些实施例中，在开始流会话之前(即，直播或点播)以及在认证过程之后，每个客户端100可以首先获取MPD文件(通常是包括形成流服务的资源的描述的XML文件)，然后并行地从现有DASH服务器获取视频片段。每个视频v的片段存储在DASH服务器的集合S中，T秒的每个视频被分成Z(＝T/τ)个片段，且每个片段segt具有固定的持续时间τ秒，其中t∈[1...Z]，并且以各种比特率级别Rv和分辨率Lv进行编码，表示为η。
在每个步骤t期间，播放器(客户端)cj使用速率适配(ABR)算法为待下载的下一个片段选择合适的比特率级别rt+1。所选择的比特率可以适应于来自所有可用服务器的可用吞吐量wt，并且将缓冲器占用率Bt维持在安全区域内(即，在上溢阈值和下溢阈值之间)。MPD文件中列出的比特率和分辨率的级别可以表示为：
Figure BDA0002975778620000121
其中，r∈[r1...rη]且l∈[l1...lη]，η是可用比特率和分辨率级别的总数。由于具有内容分辨率，每个客户端100选择在其设备显示分辨率范围内的合适级别的比特率和分辨率。
本公开的实施例旨在消除缓冲器欠载和溢出问题。可以如下执行回放缓冲器占用率的测量：
Figure BDA0002975778620000131
其中Bt-1是前一步骤t-1中的缓冲器占用率估计，Size(segt,rt,lt)是以比特率rt和分辨率lt编码的片段t的大小，I是当segt被完全下载时缓冲器占用率的增加以及在视频渲染期间的减少。估计缓冲器占用率的其它方法也是可能的。
例如，视频片段到达客户端100可以被建模为有限缓冲器、批到达、Mx/D/1/K队列，其中K是缓冲器容量。图3中示出了客户端100的示例队列模型。该模型可以建立下载吞吐量、可用比特率、缓冲器容量和预期缓冲器占用率之间的关系，从而允许客户端100将视频比特率适配到估计的吞吐量，同时将缓冲器占用率保持在稳态下的缓冲器容量的一半。
如图3所示，来自不同服务器的片段的到达被建模为批处理，并且通过对来自相应服务器si的各个到达速率λi求和来计算总有效到达速率。每个片段具有τ秒的持续时间。每秒，客户端100中的单个解码器以速率μ＝1/τ片段/秒服务于片段。让来自服务器si的下载吞吐量是wi bps从而下载质量ri bps的片段。因此，片段以
Figure BDA0002975778620000132
片段/秒的速率到达队列，并且以K秒的容量存储在队列中。为了限制比特率切换的数量，可以以相同的质量下载同一批次中的片段。因此，来自服务器si的到达速率是
Figure BDA0002975778620000133
队列处的总到达速率是该批次中的所有到达速率的总和，即λ＝∑iλ∑i。因此，队列服务器利用率是ρ＝∑iλi/μ＝w/r，其中w＝∑iwi。预期的平均队列长度Ok,ρ和预期的缓冲器松弛因子BsK，r，w＝K-Ok，ρ可以使用由Brun和Garcia(J.Appl.Prob.(2000),1092-1098)给出的分析解决方案来计算。
某些实施例的速率适配算法考虑来自不同服务器的总计到达速率。假设给定视频以比特率值R＝{r1,r2,...,rη}被编码，其中如果j＜k，则rj<rk。该算法选择时间t处的比特率r，使得预期缓冲器松弛因子Bs最接近估计的(或以其它方式获得的)缓冲器占用率Bt，
Figure BDA0002975778620000141
通过支持较高的比特率来打破平局。与先前已知的方法不同，Bs是来自不同服务器的估计的总计吞吐量，而不是当前比特率和总的缓冲器容量(或大小)的函数。
因为客户端100同时从多于一个服务器下载片段，所以下载调度器240可以在发送片段请求之前跟踪当前缓冲器级别，以避免超过缓冲器容量。例如，具有30秒缓冲器容量和具有24秒的当前缓冲器占用率的客户端100播放具有4秒片段持续时间的视频，并且五个可用服务器可以仅向一个服务器发送请求。如果当前缓冲器占用率下降到10秒以下，则期望下载调度器240向所有服务器si发送片段请求。根据某些实施例的下载调度器240可以检查来自服务器si的最后吞吐量。在批次中，下载调度器240可以从具有较高吞吐量值的服务器请求需要较早回放的片段，例如，如下面算法1中所示。
Figure BDA0002975778620000151
某些实施例可以采用瓶颈检测策略来改进性能。由于下载调度器240优选地不向多于一个服务器请求相同的片段以避免资源浪费，所以瓶颈服务器可能通过引起停顿而妨碍回放体验质量(QoE)。为了避免这种情况，客户端100可以识别瓶颈服务器并且不向瓶颈服务器请求新的片段。
如果最后片段的下载吞吐量小于最低可用比特率，则下载调度器240可以将服务器视为瓶颈服务器。调度器240可以从瓶颈服务器请求已经被另一个服务器下载的冗余片段，以跟踪其当前状态。一旦瓶颈服务器的吞吐量增加超过最低可用比特率，调度器240可以继续从瓶颈服务器下载下一个非冗余片段。如前所述，只有当没有正在进行中的其它片段下载时，才可以从服务器请求片段。这避免了阻塞已经过载的服务器以及下载太多的冗余片段，并且还避免了吞吐量过高估计。
为了实施瓶颈检测策略，下载调度器240可以被给予维护下载的时间线的附加责任。参考图4解释了这种情况的一个示例。在没有瓶颈的情况下，客户端c1和c2并行获取片段，并且它们分别按照顺序s1,s2,s3,s2,s1,s3从服务器无冗余地到来。在(服务器s2)存在瓶颈的情况下，两个客户端在下载过程期间检测服务器瓶颈，并且通过以快速吞吐量从s1重新请求seg3来快速反应。这引起从瓶颈服务器下载冗余的片段以跟踪其状态。
实施例可以例如通过调度器240实现如下调度策略。下载路径中的不同网络条件造成相关联的吞吐量的变化。尽管迫切地需要的片段是以贪婪方式从具有最高吞吐量的服务器下载的，但是由于动态网络条件和服务器负载，它们可能无序地到达。客户端100不应跳过片段，因此即使后续片段可用，用于回放的下一个片段的不可用性也会造成停顿。例如，在图5中，可以看出seg4不可用，但是段seg5和seg6存在于缓冲器中。当客户端100完成seg3的回放时，由于现在有效缓冲器占用率为零，因此它将停顿，直到seg4到达。为了避免这种情况，客户端100的调度器240可以从另一服务器重新请求seg4。优选地，对片段的重新请求不要太频繁，因为这可能导致大量的冗余片段请求。另一方面，太少的重新请求可能导致停顿。在某些实施例中，当缓冲器的连续部分下降到低于12秒时，调度器240中止正在进行的请求并重新请求丢失的片段。
客户端设备104
图19中示出了客户端设备104的示例架构。如上所述，客户端设备104能够使用标准通信协议通过网络140与系统50的其他组件，包括服务器si进行通信。
客户端设备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从下载服务器si接收的数据，使得图形被渲染到显示器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文件可以存储在例如任何一个可用服务器si上，并可以从任何一个可用服务器si检索。在一些实施例中，MPD文件存储在不同于存储内容的服务器si的服务器处。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最接近估计(或以其他方式获得)的缓冲器占用率Bt来确定可以优化客户端设备104的体验质量的比特率，其中Bt取决于来自不同服务器的总吞吐量。
实验评估
测试根据某些实施例配置的客户端100以评估其相对于已知客户端配置的性能。在以下讨论中，客户端被称为MSDAH。
A.方法论
网络配置文件：为了广泛测试MSDAH，采用了五种不同的服务器配置文件。服务器配置文件的参数如表II所示。从表II可以看出，每个服务器配置文件包括以服务器与服务器之间不同的方式随时间变化的吞吐量值。不同的配置文件P1至P5模拟相应服务器上的异构工作负载。P1和P4遵循上-下-上的模式，而P2和P5遵循下-上-下模式。这些配置文件采用自DASH工业(DASH-IF)论坛指南中。服务器之一被配置为瓶颈服务器，对应于配置文件P3。表II中的变化间(inter-variation)持续时间是关于流会话时间的每个不同吞吐量值的持续时间。
表II：网络配置文件的特性。
Figure BDA0002975778620000201
视频参数：来自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的总体影响可以通过以下模型来概括：
Figure BDA0002975778620000221
这里，DASH客户端所播放的Z片段的QoE是它们的总计比特率f(Rt)、以及相邻的播放片段f(Rt+1)-f(Rt)之间的差的大小、启动延迟Ts和总回放停顿Tstall的函数。f是恒等函数，λ＝1，α和αs是最大表示比特率。
C.结果和分析
下面描述的实验结果包括一组轨迹驱动和真实世界的测试用例。测试用例被分成如下所示的五个场景。实验结果表明，MSDAH可以显著提高观看者的QoE，并且在所有考虑的场景中传递高质量视频。
场景1(单个服务器DASH相对MSDAH)：在第一测试中，一个客户端从单个服务器请求针对五个不同网络配置文件P1至P5的视频片段。这与五个不同客户端从所有五个服务器s1至s5请求具有相应网络配置文件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)的服务器{s1,...,s4}(图18(a))；(b)100个客户共享总带宽为350Mbps的瓶颈网络和四个具有网络配置文件(60，70，80和140Mbps)的服务器{s1,...,s4}(图18(b))；(c)100个客户共享总带宽为400Mbps的瓶颈网络和四个具有网络配置文件(60，70，80和190)Mbps的服务器{s1,...,s4}(图18(c))。在加权负载均衡规则的情况下，四个服务器{s1,...,s4}分别被分配权重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的服务器瓶颈，例如如上所述。
但是应当理解，对所述实施例的各个方面的许多进一步的修改和置换是可能的。因此，所描述的方面旨在涵盖落入所附权利要求书的精神和范围内的所有此类变更、修改和变化。
在整个说明书和随后的权利要求书中，除非上下文另有要求，词语“包括”及其变体如“包含”和“含有”应理解为暗示包括所述的整体或步骤或整体或步骤的组，但不排除任何其它整体或步骤或整体或步骤的组。
本说明书中对任何现有出版物(或从其衍生的信息)或任何已知内容的引用不是并且不应被认为是对现有出版物(或从其衍生的信息)或已知内容形成本说明书所涉及的领域中的公知常识的一部分的承认或认可或任何形式的建议。

Claims (22)

1.一种在客户端设备处执行的流传输远程定位的内容的方法，包括：
与多个服务器通信，所述多个服务器中的每一个托管所述内容的多个副本，所述副本以不同的相应比特率被编码并且每一个所述副本被划分成根据时间序列布置的多个片段；以及
从至少是所述多个服务器的子集的一组下载服务器请求并行下载片段集合，
其中，从所述一组下载服务器中的不同服务器下载所述集合中的相应片段，所述片段在所述时间序列中是连续的。
2.根据权利要求1所述的方法，还包括监测所述客户端设备的回放缓冲器占用率。
3.根据权利要求2所述的方法，还包括基于所述客户端设备的所述回放缓冲器占用率和/或所述一组下载服务器的估计吞吐量来选择下载片段的比特率。
4.根据前述权利要求中任一项所述的方法，还包括：
识别所述多个服务器中的一个或更多个瓶颈服务器；以及
从所述一组下载服务器中临时移除所述一个或更多个瓶颈服务器。
5.根据权利要求4所述的方法，还包括：
通过从所述一个或更多个瓶颈服务器请求下载已经从所述一组下载服务器中的服务器下载的片段，来监测所述一个或更多个瓶颈服务器的吞吐量状态。
6.根据权利要求5的方法，还包括，响应于瓶颈服务器的吞吐量状态超过比特率阈值，将所述瓶颈服务器恢复到所述一组下载服务器。
7.根据前述权利要求中任一项所述的方法，其中，所述服务器是DASH服务器。
8.一种用于流传输远程定位的内容的客户端设备，包括：
至少一个处理器，所述至少一个处理器与计算机可读存储装置通信，所述计算机可读存储装置上存储有指令，所述指令在由所述至少一个处理器执行时使所述客户端设备：
与多个服务器通信，所述多个服务器中的每一个托管所述内容的多个副本，所述副本以不同的相应比特率被编码并且每一个所述副本被划分成根据时间序列布置的多个片段；以及
从至少是所述多个服务器的子集的一组下载服务器请求并行下载片段集合，
其中，从所述一组下载服务器中的不同服务器下载所述集合中的相应片段，所述片段在所述时间序列中是连续的。
9.根据权利要求8所述的客户端设备，其中，所述指令还包括当由所述至少一个处理器执行时使所述客户端设备监测所述客户端设备的回放缓冲器占用率的指令。
10.根据权利要求9所述的客户端设备，其中，所述指令还包括当由所述至少一个处理器执行时使得所述客户端设备基于所述客户端设备的所述回放缓冲器占用率和/或所述一组下载服务器的估计吞吐量来选择下载片段的比特率的指令。
11.根据权利要求8至10中任一项所述的客户端设备，其中，所述指令还包括当由所述至少一个处理器执行时使所述客户端设备执行以下操作的指令：
识别所述多个服务器中的一个或更多个瓶颈服务器；以及
从所述一组下载服务器中临时移除所述一个或更多个瓶颈服务器。
12.根据权利要求11所述的客户端设备，其中，所述指令还包括当由所述至少一个处理器执行时使所述客户端设备执行以下操作的指令：
通过从所述一个或更多个瓶颈服务器请求下载已经从所述一组下载服务器中的服务器下载的片段，来监测所述一个或更多个瓶颈服务器的吞吐量状态。
13.根据权利要求12所述的客户端设备，其中所述指令还包括当由所述至少一个处理器执行时使所述客户端设备响应于瓶颈服务器的吞吐量状态超过比特率阈值，将所述瓶颈服务器恢复到所述一组下载服务器的指令。
14.根据权利要求8至13中任一项所述的客户端设备，所述客户端设备被配置成与作为DASH服务器的服务器通信。
15.一种非易失性计算机可读存储介质，所述非易失性计算机可读存储介质上存储有指令，所述指令在由客户端设备的至少一个处理器执行时，使所述客户端设备执行根据权利要求1至7中任一项所述的方法。
16.一种用于从多个服务器流传输远程定位的内容的计算设备，所述多个服务器中的每一个托管所述内容的多个副本，所述副本以不同的相应比特率被编码并且每一个所述副本被划分成根据时间序列布置的多个片段，所述客户端设备包括：
下载调度器，所述下载调度器被配置为从至少是所述多个服务器的子集的一组下载服务器请求并行下载片段集合，
其中，所述下载调度器被配置为从所述一组下载服务器中的不同服务器下载所述集合中的相应片段，所述片段在所述时间序列中是连续的。
17.根据权利要求16所述的计算设备，还包括缓冲器控制器，所述缓冲器控制器被配置为监测所述计算设备的回放缓冲器占用率。
18.根据权利要求17所述的计算设备，还包括自适应比特率控制器，所述自适应比特率控制器被配置为：
与所述缓冲器控制器通信以接收所述回放缓冲器占用率；以及
基于所述计算设备的所述回放缓冲器占用率和/或所述一组下载服务器的估计吞吐量来选择下载片段的比特率。
19.根据权利要求18所述的计算设备，包括吞吐量估计器，所述吞吐量估计器用于确定所述一组下载服务器的估计吞吐量。
20.根据权利要求16至19中任一项所述的计算设备，其中，所述下载调度器被配置为：
识别所述多个服务器中的一个或更多个瓶颈服务器；以及
从所述一组下载服务器中临时移除所述一个或更多个瓶颈服务器。
21.根据权利要求20所述的计算设备，其中所述下载调度器被配置为：
通过从所述一个或更多个瓶颈服务器请求下载已经从所述一组下载服务器中的服务器下载的片段，来监测所述一个或更多个瓶颈服务器的吞吐量状态。
22.根据权利要求21所述的计算设备，其中所述下载调度器被配置为响应于瓶颈服务器的吞吐量状态超过比特率阈值，将所述瓶颈服务器恢复到所述一组下载服务器。
CN201980060169.7A 2018-09-14 2019-09-13 用于流传输内容的方法和设备 Pending CN112690005A (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
SG10201807988R 2018-09-14
SG10201807988R 2018-09-14
PCT/SG2019/050461 WO2020055333A1 (en) 2018-09-14 2019-09-13 Method and device for streaming content

Publications (1)

Publication Number Publication Date
CN112690005A true CN112690005A (zh) 2021-04-20

Family

ID=69779243

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201980060169.7A Pending CN112690005A (zh) 2018-09-14 2019-09-13 用于流传输内容的方法和设备

Country Status (4)

Country Link
US (1) US20220030308A1 (zh)
EP (1) EP3850857A4 (zh)
CN (1) CN112690005A (zh)
WO (1) WO2020055333A1 (zh)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10182038B2 (en) 2013-07-29 2019-01-15 Mobitv, Inc. Efficient common storage of partially encrypted content
CN113994644A (zh) * 2019-04-12 2022-01-28 华为技术有限公司 一种用于传输视频数据流的通信实体和方法
US11611898B2 (en) * 2020-01-17 2023-03-21 Parallel Wireless, Inc. Slow eNodeB/HNB identification and impact mitigation
US11570496B2 (en) 2020-12-03 2023-01-31 Hulu, LLC Concurrent downloading of video
US11425048B2 (en) * 2020-12-15 2022-08-23 Cisco Technology, Inc. Using throughput mode distribution as a proxy for quality of experience and path selection in the internet
US11910032B1 (en) 2022-08-02 2024-02-20 Rovi Guides, Inc. Systems and methods for distributed media streaming
US11956293B1 (en) 2023-03-29 2024-04-09 Adeia Guides Inc. Selection of CDN and access network on the user device from among multiple access networks and CDNs

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102158344A (zh) * 2011-05-20 2011-08-17 苏州安源汇信软件有限公司 并行组播网络文件系统
CN103179107A (zh) * 2011-12-22 2013-06-26 汤姆森特许公司 多径环境自适应流传输系统及方法
CN104079622A (zh) * 2013-03-25 2014-10-01 索尼公司 用于媒体分发的设备、方法及系统
US20150039782A1 (en) * 2004-04-30 2015-02-05 Echostar Technologies L.L.C. Apparatus, system, and method for adaptive-rate shifting of streaming content
CN105144738A (zh) * 2013-06-06 2015-12-09 英特尔公司 用于dash媒体流传输的管理器
US20160197985A1 (en) * 2012-11-21 2016-07-07 Netflix, Inc. Multi-cdn digital content streaming
US20160337426A1 (en) * 2015-05-14 2016-11-17 Hola Networks Ltd. System and Method for Streaming Content from Multiple Servers

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10271112B2 (en) * 2015-03-26 2019-04-23 Carnegie Mellon University System and method for dynamic adaptive video streaming using model predictive control

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150039782A1 (en) * 2004-04-30 2015-02-05 Echostar Technologies L.L.C. Apparatus, system, and method for adaptive-rate shifting of streaming content
CN102158344A (zh) * 2011-05-20 2011-08-17 苏州安源汇信软件有限公司 并行组播网络文件系统
CN103179107A (zh) * 2011-12-22 2013-06-26 汤姆森特许公司 多径环境自适应流传输系统及方法
US20160197985A1 (en) * 2012-11-21 2016-07-07 Netflix, Inc. Multi-cdn digital content streaming
CN104079622A (zh) * 2013-03-25 2014-10-01 索尼公司 用于媒体分发的设备、方法及系统
CN105144738A (zh) * 2013-06-06 2015-12-09 英特尔公司 用于dash媒体流传输的管理器
US20160337426A1 (en) * 2015-05-14 2016-11-17 Hola Networks Ltd. System and Method for Streaming Content from Multiple Servers

Also Published As

Publication number Publication date
US20220030308A1 (en) 2022-01-27
EP3850857A1 (en) 2021-07-21
EP3850857A4 (en) 2022-10-05
WO2020055333A1 (en) 2020-03-19

Similar Documents

Publication Publication Date Title
CN112690005A (zh) 用于流传输内容的方法和设备
US8832292B2 (en) Source-selection based internet backbone traffic shaping
US10374928B1 (en) Efficient bandwidth estimation
US7818445B2 (en) Methods and devices for obtaining a broadcast-like streaming content
DK2545459T3 (en) Parallel streaming
EP2859696B1 (en) Preventing overestimation of available bandwidth in adaptive bitrate streaming clients
US20160142510A1 (en) Cache-aware content-based rate adaptation mechanism for adaptive video streaming
Bentaleb et al. DQ-DASH: A queuing theory approach to distributed adaptive video streaming
Bae et al. Why is http adaptive streaming so hard?
Wang et al. Design and analysis of QoE-aware quality adaptation for DASH: A spectrum-based approach
CN110771122A (zh) 使内容传送网络能够处理非预期流量激增的方法和网络节点
Zhang et al. Presto: Towards fair and efficient HTTP adaptive streaming from multiple servers
Yousef et al. Enabling adaptive bitrate algorithms in hybrid CDN/P2P networks
Bruneau-Queyreix et al. QOE enhancement through cost-effective adaptation decision process for multiple-server streaming over HTTP
Wei et al. Performance analysis of adaptive bitrate algorithms for multi-user DASH video streaming
Khan et al. What happens when stochastic adaptive video streaming players share a bottleneck link?
Hayes et al. Adaptive bitrate video delivery using HTTP/2 over MPTCP architecture
Khan et al. Bandwidth Estimation Techniques for Relative'Fair'Sharing in DASH
Wang et al. On the Feasibility of DASH Streaming in the Cloud
Younus et al. A model for a practical evaluation of a DASH-based rate adaptive algorithm over HTTP
Bruneau-Queyreix Multi-criteria optimization of content delivery within the future media internet
Ozcan et al. Multipath transmission aware ABR algorithm for SVC HAS
Yin et al. Nefis: A network coding based flexible device-to-device video streaming scheme
Song et al. Towards user-oriented live video streaming
Yun et al. HTTP adaptive streaming scheme for improving the quality of experience in multi-server environments

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
WD01 Invention patent application deemed withdrawn after publication

Application publication date: 20210420

WD01 Invention patent application deemed withdrawn after publication