阅读说明：本技术 用于流传输内容的方法和设备 (Method and apparatus for streaming content ) 是由 阿卜杜勒哈克·班他列 普拉文·库玛·亚达夫 罗杰·齐默尔曼 黄玮璨 于 2019-09-13 设计创作，主要内容包括：一种在客户端设备处执行的流传输远程定位的内容的方法,包括：与多个服务器通信,该多个服务器中的每一个托管该内容的多个副本,该副本以不同的相应比特率被编码并且每一个该副本被划分成根据时间序列布置的多个片段；以及从至少是该多个服务器的子集的一组下载服务器请求并行下载片段集合,其中,从该组下载服务器的不同服务器下载该集合中的相应片段,该片段在该时间序列中是连续的。(A method of streaming remotely located content performed at a client device, comprising: communicating with a plurality of servers, each of the plurality of servers hosting multiple copies of the content, the copies being encoded at different respective bitrates and each of the copies being divided into a plurality of segments arranged according to a time sequence; and requesting a set of parallel download segments from a set of download servers that is at least a subset of the plurality of servers, wherein respective segments in the set are downloaded from different servers of the set of download servers, the segments being consecutive in the time sequence.)

1. A method of streaming remotely located content performed at a client device, comprising:

communicating with a plurality of servers, each of the plurality of servers hosting a plurality of copies of the content, the copies being encoded at different respective bitrates and each of the copies being divided into a plurality of segments arranged according to a time sequence; and

requesting a set of parallel download segments from a set of download servers that is at least a subset of the plurality of servers,

wherein respective segments in the collection are downloaded from different servers in the set of download servers, the segments being consecutive in the time series.

2. The method of claim 1, further comprising monitoring a playback buffer occupancy of the client device.

3. The method of claim 2, further comprising selecting a bit rate for download segments based on the playback buffer occupancy of the client device and/or an estimated throughput of the group of download servers.

4. The method of any preceding claim, further comprising:

identifying one or more bottleneck servers of the plurality of servers; and

temporarily removing the one or more bottleneck servers from the set of download servers.

5. The method of claim 4, further comprising:

monitoring a throughput status of the one or more bottleneck servers by requesting from the one or more bottleneck servers to download segments that have been downloaded from servers in the set of download servers.

6. The method of claim 5, further comprising, in response to a throughput state of a bottleneck server exceeding a bit rate threshold, restoring the bottleneck server to the set of download servers.

7. The method of any preceding claim, wherein the server is a DASH server.

8. A client device for streaming remotely located content, comprising:

at least one processor in communication with a computer-readable storage device having instructions stored thereon that, when executed by the at least one processor, cause the client device to:

communicating with a plurality of servers, each of the plurality of servers hosting a plurality of copies of the content, the copies being encoded at different respective bitrates and each of the copies being divided into a plurality of segments arranged according to a time sequence; and

requesting a set of parallel download segments from a set of download servers that is at least a subset of the plurality of servers,

wherein respective segments in the collection are downloaded from different servers in the set of download servers, the segments being consecutive in the time series.

9. The client device of claim 8, wherein the instructions further comprise instructions that when executed by the at least one processor cause the client device to monitor a playback buffer occupancy of the client device.

10. The client device of claim 9, wherein the instructions further comprise instructions that when executed by the at least one processor cause the client device to select a bit rate for download segments based on the playback buffer occupancy of the client device and/or the estimated throughput of the group of download servers.

11. The client device of any of claims 8-10, wherein the instructions further comprise instructions that, when executed by the at least one processor, cause the client device to:

identifying one or more bottleneck servers of the plurality of servers; and

temporarily removing the one or more bottleneck servers from the set of download servers.

12. The client device of claim 11, wherein the instructions further comprise instructions that when executed by the at least one processor cause the client device to:

monitoring a throughput status of the one or more bottleneck servers by requesting from the one or more bottleneck servers to download segments that have been downloaded from servers in the set of download servers.

13. The client device of claim 12, wherein the instructions further comprise instructions that when executed by the at least one processor cause the client device to restore a bottleneck server to the set of download servers in response to a throughput state of the bottleneck server exceeding a bitrate threshold.

14. The client device of any of claims 8 to 13, configured to communicate with a server that is a DASH server.

15. A non-transitory computer-readable storage medium having instructions stored thereon, which, when executed by at least one processor of a client device, cause the client device to perform the method of any of claims 1-7.

16. A computing device for streaming remotely located content from a plurality of servers, each of the plurality of servers hosting multiple copies of the content, the copies being encoded at different respective bitrates and each of the copies being divided into a plurality of segments arranged according to a time sequence, the client device comprising:

a download scheduler configured to request a set of parallel download segments from a set of download servers that is at least a subset of the plurality of servers,

wherein the download scheduler is configured to download respective segments of the set from different servers of the set of download servers, the segments being consecutive in the time series.

17. The computing device of claim 16, further comprising a buffer controller configured to monitor a playback buffer occupancy of the computing device.

18. The computing device of claim 17, further comprising an adaptive bitrate controller configured to:

communicating with the buffer controller to receive the playback buffer occupancy; and

selecting a bit rate for download segments based on the playback buffer occupancy of the computing device and/or an estimated throughput of the set of download servers.

19. The computing device of claim 18, comprising a throughput estimator to determine an estimated throughput for the set of download servers.

20. The computing device of any of claims 16 to 19, wherein the download scheduler is configured to:

identifying one or more bottleneck servers of the plurality of servers; and

temporarily removing the one or more bottleneck servers from the set of download servers.

21. The computing device of claim 20, wherein the download scheduler is configured to:

monitoring a throughput status of the one or more bottleneck servers by requesting from the one or more bottleneck servers to download segments that have been downloaded from servers in the set of download servers.

22. The computing device of claim 21, wherein the download scheduler is configured to restore a bottleneck server to the set of download servers in response to a throughput state of the bottleneck server exceeding a bit rate threshold.

Technical Field

The present disclosure relates to a method and apparatus for streaming content.

Background

With the increased availability of high speed and high bandwidth internet connections, streaming services are almost ubiquitous today. For example, hypertext transfer protocol (HTTP) adaptive transport (HAS) is used by many such streaming services due to its ability to deliver high quality streams via traditional HTTP servers. It is believed that by 2021, the HAS system will dominate internet traffic.

The increase in video network traffic creates challenges for maintaining the quality of the user experience. One proposed approach to solving this problem is implemented in the dynamic adaptive streaming over HTTP (DASH) framework. With DASH, clients typically access one server at a time and are redirected to another server only via DNS redirection if a network bottleneck (bottleeck) occurs. The available media bit rate levels and resolutions are discrete. Clients sharing an overloaded server or bottleneck link limit themselves to low bit rate levels to avoid playback stalls. Conversely, clients that happen to be able to access a less loaded server can achieve much higher video quality, so that the quality of experience (QoE) can vary widely between clients.

DASH dynamically adapts to network conditions due to its Adaptive Bitrate (ABR) scheme, which is based on heuristics such as throughput measurements, playback buffer occupancy, or a combination of both. Furthermore, since DASH uses HTTP, it enables content providers to use the existing Content Distribution Network (CDN) infrastructure and simplifies traversal through network middleboxes (midlineboxes). Finally, it is highly scalable and DASH clients can request and retrieve video segments, independently maintaining their local playback state in a decentralized manner using stateless DASH servers.

DASH systems include two main entities: DASH servers and DASH clients. DASH servers store video that is divided into small fixed segments (2-15 seconds) and encode each segment at various bit rate levels and resolutions. Then, the segments of each video are listed in a Media Presentation Description (MPD) which also includes metadata information for segment duration, codec/encryption details, and track correspondence (audio and subtitles). After the authentication phase, the client first retrieves the MPD file for the video to be viewed, and then sequentially requests segments based on its ABR controller decision. The DASH server responds by sending the requested segment via HTTP. The ABR controller implements various heuristics to determine the bit rate to select for the next segment. Thus, in the event of network throughput variations and buffer occupancy changes, it switches between the available bit rates.

In DASH delivery systems, each DASH client strives to improve its QoE by making an optimal bit rate decision that can adapt to underlying network conditions without introducing stalls. The bit rate decision is performed using ABR logic, which relies on throughput estimation and buffer occupancy measurements. However, choosing the right decision in existing network infrastructures using DASH is difficult for at least two reasons:

insufficient bandwidth: the increasing amount of DASH traffic and the increasing demand for higher video quality by users has resulted in an explosive consumption of bandwidth. In standard DASH, achieving high QoE on existing bandwidth-limited networks is very challenging due to frequent congestion. Congestion occurs due to DASH clients competing for available bandwidth. This competition results in video instability, pauses, long startup delays, and many variations in quality, and thus significantly affects the user experience. The high traffic load of video content is typically shared between CDNs based on some redirection policy (CDN-based load balancing rules). In such a system, DASH clients use only one node at a time and connect to a new node if a bottleneck is detected based on policies decided by the content provider. Clients connected to more overloaded nodes get a lower share of throughput, resulting in unfairness.

Server side bottleneck: in standard DASH solutions, only one server is typically considered for sequential segment delivery as determined by a given base URL (i.e., the next segment can be downloaded only if the current segment is completely downloaded). This one-segment-at-a-time mechanism represents a weakness in the case of a bottleneck on the server side. This problem is exacerbated if the minimum bit rate of the encoded segments is higher than the throughput of the bottleneck link. Server bottleneck problems result in increased stutter, video instability, frequent changes in bit rate, and unfairness. Previously proposed systems attempt to identify bottlenecks using simple network metrics (e.g., latency, download time, throughput) and then select an appropriate server based on the network metrics. However, these proposals: (i) not compliant with existing DASH delivery systems, or (ii) require modification on the network side, or (iii) are not scalable (i.e., each client needs to report its status to the network controller).

Even in the presence of CDN-based redirection policies, the above factors can negatively impact QoE of viewers of DASH, and in the presence of bottlenecks, the problem can worsen.

Client requests to the server may be order-based or parallel-based.

In the order-based method, a scheduler requests video clips one after another on an order basis, and a next clip cannot be downloaded until one requested clip is completely downloaded. The ABR controller of the client may use rate-based, buffer-based, or hybrid-based heuristics for scheduling purposes.

In the parallel-based approach, the scheduler requests and downloads multiple segments simultaneously from different video servers in parallel. In most cases, this requires kernel or network function modifications in the application and transport layers. For example, some proposals include utilizing multiple network interfaces (e.g., WiFi and cellular) and MPTCP protocols employed in the client to download from different access networks. Another parallel-based implementation has been proposed by Queyreix et al (IEEE CCNC, 580-581 page 2017) and is referred to as MS-streaming (multi-source streaming over HTTP). MS-streaming is a practically evolving HAS-based streaming solution for DASH that uses multiple customized servers to improve end user QoE. Although MS-streaming shows good performance in delivering high quality video, the proposed solution has some limitations: (i) it encodes video using Multiple Description Coding (MDC), which is now not standard; (ii) this embodiment requires a specific API at each server that does not conform to the DASH standard; (iii) there is a time overhead to combine the content before playback, which may be unacceptable for standard QoS and QoE; (iv) existing DASH storage server and CDN architectures on the internet require modifications, which can be significant; and (v) all content downloaded is unplayable and there is significant overhead such that the total throughput from multiple servers is not fully utilized.

Embodiments of the present disclosure seek to overcome or alleviate one or more of the above difficulties, or at least provide a useful alternative.

Disclosure of Invention

The present disclosure provides a method of streaming remotely located content performed at a client device, comprising:

communicating with a plurality of servers, each of the plurality of servers hosting multiple copies of content, the copies being encoded at different respective bitrates and each of the copies being divided into a plurality of segments arranged according to a time sequence; and

requesting a set of parallel download segments from a set of download servers that is at least a subset of the plurality of servers,

wherein respective segments in the set are downloaded from different servers in the set of download servers, the segments being consecutive in time sequence.

The method may also include monitoring a playback buffer occupancy of the client device. In some embodiments, the method includes selecting a bit rate for the download segments based on a playback buffer occupancy of the client device and/or an estimated throughput of the set of download servers.

The method may include identifying one or more bottleneck servers of a plurality of servers; and temporarily removing one or more bottleneck servers from the set of download servers. Some embodiments may further include monitoring the throughput status of one or more bottleneck servers by requesting downloads from the one or more bottleneck servers of segments that have been downloaded from a server in the set of download servers. The method can include restoring the bottleneck server to the set of download servers in response to the bottleneck server throughput state exceeding a bit rate threshold.

The server may be a DASH server.

The present disclosure also provides a client device for streaming remotely located content, comprising:

at least one processor in communication with a computer-readable storage device having instructions stored thereon that, when executed by the at least one processor, cause the client device to:

communicating with a plurality of servers, each of the plurality of servers hosting multiple copies of the content, the copies being encoded at different respective bitrates and each divided into a plurality of segments arranged according to a time sequence; and

requesting a set of parallel download segments from a set of download servers that is at least a subset of the plurality of servers;

wherein respective segments in the set are downloaded from different servers in the set of download servers, said segments being consecutive in the time series.

The instructions may further include instructions that, when executed by the at least one processor, cause the client device to monitor a playback buffer occupancy of the client device. The instructions may also include instructions that, when executed by the at least one processor, cause the client device to select a bit rate for downloading the segments based on a playback buffer occupancy of the client device and/or an estimated throughput of the set of download servers.

The instructions may further include instructions that, when executed by the at least one processor, cause the client device to: identifying one or more bottleneck servers of a plurality of servers; and temporarily removing one or more bottleneck servers from the set of download servers.

The instructions may further include instructions that, when executed by the at least one processor, cause the client device to: monitoring the throughput status of one or more bottleneck servers by requesting from the one or more bottleneck servers to download segments that have been downloaded from a server in the set of download servers. The instructions may further include instructions that, when executed by the at least one processor, cause the client device to restore the bottleneck server to the set of download servers in response to a throughput state of the bottleneck server exceeding a bit rate threshold.

The present disclosure also provides a non-transitory computer-readable storage medium having stored thereon instructions that, when executed by at least one processor of a client device, cause the client device to perform a method as disclosed herein.

The present disclosure also provides a computing device for streaming remotely located content from a plurality of servers, each of the plurality of servers hosting a plurality of copies of the content, the copies being encoded at different respective bitrates and each divided into a plurality of segments arranged according to a time sequence, the client device comprising:

a download scheduler configured to request a set of parallel download segments from a set of download servers that is at least a subset of the plurality of servers,

wherein the download scheduler is configured to download respective segments of the set from different servers of the set of download servers, the segments being consecutive in time sequence.

Embodiments may also include a buffer controller configured to monitor a playback buffer occupancy of the computing device.

Embodiments may also include an adaptive bitrate controller configured to: communicating with a buffer controller to receive a playback buffer occupancy; and selecting a bit rate for the download segments based on the playback buffer occupancy of the computing device and/or the estimated throughput of the set of download servers.

Some embodiments may include a throughput estimator for determining an estimated throughput for the set of download servers.

The download scheduler may be configured to: identifying one or more bottleneck servers of a plurality of servers; and temporarily removing one or more bottleneck servers from the set of download servers. The download scheduler may be further configured to: monitoring the throughput status of one or more bottleneck servers by requesting from the one or more bottleneck servers to download segments that have been downloaded from a server in the set of download servers. In some embodiments, the download scheduler is configured to restore the bottleneck server to the set of download servers in response to a throughput status of the bottleneck server exceeding a bit rate threshold.

Drawings

Embodiments of the present disclosure will now be described, by way of non-limiting example only, with reference to the accompanying drawings, in which:

FIG. 1 shows an overview of an example architecture of a system for streaming content;

FIG. 2 illustrates a detailed architecture of an embodiment of a streaming client;

FIG. 3 illustrates an example of a queue model for an embodiment of a streaming client;

FIG. 4 schematically depicts segment scheduling with and without bottlenecks;

FIG. 5 schematically depicts a scheduling strategy in the case of out-of-order fragment arrival;

js-based player fig. 6 shows an example architecture of a dash.js-based player;

FIG. 7 is a bar graph of the average bit rate of clients when they are connected to servers with different profiles (P1-P5) and when all clients share all servers for different buffer capacity configurations (30, 60 and 120) s;

FIG. 8 is a bar graph representing the average number of changes in presentation when clients connect to servers with different configuration files (P1-P5) and when all clients share all servers (MSDAH) for different buffer capacity configurations (30, 60, and 120) s;

FIG. 9 shows the pause duration and the number of pauses when clients are connected to servers with different configuration files (P1-P5) and when all clients share all servers (MSDAH) for different buffer capacity configurations (30, 60 and 120) s;

fig. 10 shows the average QoE when clients are connected to servers with different bandwidths (P1-P5) and when all clients share all servers (MSDAH) with different bandwidths for different buffer capacity configurations;

fig. 11 shows the average bit rate of an embodiment of the present disclosure compared to CDN-based load balancing rules;

FIG. 12 illustrates the average number of representation changes of an embodiment of the present disclosure compared to CDN-based load balancing rules;

fig. 13 shows the average QoE of embodiments of the present disclosure compared to CDN-based load balancing rules;

FIG. 14 illustrates the pause duration and number of pauses of an embodiment of the present disclosure compared to CDN-based load balancing rules;

fig. 15 shows the average bit rate and quality variation for segment durations of 2 and 4 seconds starting together and having an interval of 60s for 5 clients;

fig. 16 illustrates a bit rate fairness comparison of a client to a single server client according to an embodiment of the disclosure. (a) One msah client and one single server client; (b) two single server clients sharing the same server; (c) bit rate over time for a single server DASH (left) and MSDAH (right); (d) bit rate over time for a single server client 1 (left) and client 2 (right);

FIG. 17 shows a comparison of the performance of embodiments of the present invention with different segment durations for a 30 second buffer capacity;

fig. 18 shows the average bit rate, representation variation, and QoE for 100 clients with different total bandwidths (300, 350, and 400Mbps) and buffer capacity configurations (30, 60, and 120) for embodiments of the present disclosure compared to clients using CDN-based load balancing rules. (a) 100 clients sharing a bottleneck network with a total bandwidth of 300Mbps and 4 servers with fixed network profiles (60, 70, 80, and 90 Mbps); (b)100 clients sharing a bottleneck network with a total bandwidth of 350Mbps and 4 servers with fixed network profiles (60, 70, 80, and 140 Mbps); (c)100 clients sharing a bottleneck network with a total bandwidth of 400Mbps and 4 servers with fixed network profiles (60, 70, 80, and 190 Mbps);

FIG. 19 shows an example architecture of a client device;

FIG. 20 is a flow diagram of an example of stream processing according to some embodiments; and

fig. 21 is a flow chart of an example of a bit rate selection process.

Detailed Description

Embodiments of the present disclosure relate to a method of streaming remotely located content, and to a client device configured to perform the method. Referred to as MSDAH (multi-server DASH) in at least some embodiments herein.

In embodiments of the present disclosure, multiple clients may share more than one server in parallel. The sharing of servers enables a unified QoE, and bottleneck links or overloaded servers do not have a local impact on the client. The functionality of the presently disclosed embodiments is implemented in a distributed manner in the application layer of the client side and may be, for example, a modified version of the existing DASH client side architecture. Thus, the presently disclosed embodiments do not require any modification to the kernel or network functions, including transport layer modifications. As will be described in detail below, it has been found that embodiments of the present disclosure can significantly improve streaming performance, including the following improvements:

QoE higher than 33% with less than 1% variation between clients compared to sequential downloads from a single server.

High robustness against server bottlenecks and variable network conditions. The currently proposed solution does not over-utilize the available bandwidth and in most cases the additional data overhead is an additional clip download of media data for 10 minutes of video playback.

A single server DASH and CDN-based load balancing rule that is significantly better than sequential, including: round robin scheduling, least connections, session persistence, and weighting.

Advantageously, embodiments of the present disclosure efficiently handle bottlenecks by first determining the bottleneck or failed server; stopping requesting future segments from the determined bottleneck server; and periodically monitor the status of the bottleneck server for any changes (e.g., it may become a health server again), e.g., by probe-based passive or active measurements.

In addition, the presently disclosed embodiments provide a fairer and higher QoE than prior art approaches and achieve the best bit rate by exploiting extended bandwidth and link diversity from multiple servers with different capacities. Embodiments of the present disclosure provide a pure client-driven solution in which modifications are restricted to client-side applications. Thus, the network and server sides remain unchanged, making the implementation less complex and less error prone.

In the present disclosure, the following symbols and abbreviations are used.

Table I: list of key symbols and tokens.

Embodiments of the present disclosure implement a bit rate selection process at a client device that is governed by a playback buffer occupancy of the client device, an estimated throughput of a set of servers from which the client device may request data segments, or a combination of the playback buffer occupancy and the estimated throughput of the set of servers.

One possible architecture of a system 50 for streaming content is shown in fig. 1. A client 100 executing on a computing device, such as a mobile device 102, a laptop 104, or a desktop 106, can connect to multiple servers via a wide area network, such as the internet 140, to request data. In the example shown in FIG. 1, system 50 includes six servers (labeled s, respectively)₁To s₆) However, fewer or more servers may be provided. In some embodiments, tens or even hundreds of servers may be deployed as part of system 50. In general, a server s_iIt would be a DASH server to which the client 100 can connect and can request content via HTTP GET requests, and the client 100 can be implemented as a modified version of, for example, DASH.

In general, a server s_iData provided by content provider 110 is typically mirrored via an internet 140 connection. Other participants, such as over-the-top (OTT) service 120, may also give server s_iContent is provided for streaming by the client 100.

The client 100 according to the presently disclosed embodiment requests in parallel from all available servers s_iPreferably the available servers s_iTo maximize throughput of multiple servers. For example, as shown in fig. 1, if the available throughput from five different servers is 2Mbps, 1Mbps, 1.5Mbps, 0.5Mbps, and 1Mbps, the client 100 should be able to play video with a quality equal to 6Mbps without any pause.

Each client 100 may be arranged to request segments simultaneously from multiple servers, which may be geographically distributed. The client 100 can take advantage of link diversity in the existing network infrastructure to provide a robust video streaming solution.

Importantly, the presently disclosed embodiments can be implemented without any modifications in the DASH server or network. All modifications are performed at the client 100, so no changes need to be made to the kernel. The client 100 may represent a video player supporting a DASH system, such as a reference player DASH.

Each client 100 is characterized by the capabilities of the device 102, 104, or 106 on which the client 100 executes (such as display resolution, memory, and CPU), and can request various content types (e.g., animation, movies, news, etc.). Client 100 may implement one or more Adaptive Bitrate (ABR) procedures.

Further details of an example architecture of the client 100 are shown in fig. 2, and the client 100 may include the following four components.

(i) A buffer controller 210 that tracks playback buffer occupancy. Buffer controller 210 may include logic to check whether the bit rate selected by ABR controller 220 results in a video stall, and if so, select a new appropriate bit rate. Buffer controller 210 may also include logic to maintain the bit rate at a safe level, for example, between two predefined high and low thresholds. Buffer controller 210 provides data regarding the buffer size to ABR controller 220 for input to a rate adaptation algorithm so that ABR controller 220 can select an appropriate bit rate.

(ii) A throughput estimator 230, the throughput estimator 230 being predictive of the throughput from the server s_iAnd provides the estimate to ABR controller 220 for input to the rate adaptation algorithm. The throughput estimator 230 may consider two smoothing functions for the throughput prediction, e.g. including the last three average throughputs or the last throughput.

(iii) ABR controller 220, the ABR controller 220 implementing a rate adaptation algorithm (also referred to herein as ABR algorithm) using one or more ABR rules 224 in conjunction with buffer size data from buffer controller 210 and/or throughput data from throughput estimator 230 to decide which bit rate should be selected for the next segment to be downloaded. For example, the ABR rules 224 may include buffer-based bit rate selection, rate-based bit rate selection, or a hybrid bit rate selection combining buffer and throughput (rate-based) considerations. The ABR algorithm may select the best possible bit rate to stream the content with the highest possible quality. ABR controller 220 provides the selected bit rate to scheduler 240 for scheduling downloads to buffer controller 210.

(iv) A scheduler 240, the scheduler 240 controlling, requesting and downloading the appropriate segments from the corresponding servers. The scheduler 240 may also be responsible for avoiding downloading the same segment multiple times to save bandwidth and avoid performance degradation due to bottleneck servers.

For example, for each segment, t e [1]Where Z represents the total number of download steps, the client 100 may use the ABR controller 220 to select the appropriate bit rate r_iThe bit rate r_iAdapted to playback buffer occupancy and each source s_iWherein i ∈ [1.,. M]And M denotes the total number of existing servers. The client 100 may then simultaneously (via the scheduler 240) from the M servers s_iA plurality of consecutive fragments is requested. When the playback buffer monitored by the buffer controller 210 reaches its maximum capacity K, the client 100 may trigger an event to stop downloading (via the buffer controller 210) and gradually reduce the number of servers to a single server to avoid buffer overflow. The number of servers used may be increased each time there is space to accommodate a fragment, i.e. when the maximum buffer capacity is not reached, until the number of servers reaches M.

In some embodiments, system 50 may be modeled by representing with a directed or undirected graph G ═ (V, E), where V ═ C ═ cs is client C ═ C { (C)₁,...,c_NS ═ S₁,...,s_MThe set of (c). For modeling purposes, a full mesh network, i.e., Fat-Tree (Fat-Tree) topology (e.g., OSPF mesh network), may be assumed, where each client c_je.C has to each s_iE.g., connectivity of S, where j ═ 1.. N]And i ═ 1.. M]And thus the client 100 simultaneously acquires consecutive segments from the existing server using different multiple links.

When the playback buffer becomes full, the client 100 stops downloading the segments and gradually reduces the total number of servers used to one. Otherwise, if there is space in the playback buffer, the client 100 may increase the number of servers until it utilizes all existing servers (full server utilization).

At any time, due to congestion and network variability, to server s_iMay be slow and the server will be considered the bottleneck server. In this case, the client 100 suffers from a delay due to the exhaustion of the client playback buffer due to the delayed segment from the bottleneck server. To avoid this problem, in some embodiments, the client 100 may stop fetching future segments from the bottleneck server, but only fetch future segments from M-H remaining servers, where H is the total number of bottleneck servers. Each client 100 can track the state of the bottleneck server by requesting the previous segment with the lowest quality and resume use of the bottleneck server once it can provide service and again meet the client requirements.

In some embodiments, before starting the streaming session (i.e., live or on demand) and after the authentication process, each client 100 may first retrieve the MPD file (typically an XML file that includes a description of the resources that form the streaming service) and then retrieve the video segments from the existing DASH server in parallel. Segments of each video v are stored in a set S of DASH servers, each video of T seconds is divided into Z (═ T/τ) segments, and each segment seg_tHaving a fixed duration of τ seconds, wherein t ∈ [1.. Z]And at various bit rate levels R_vAnd resolution L_vThe encoding is performed, denoted as η.

During each step t, the player (client) c_jSelecting an appropriate bit rate level r for the next segment to be downloaded using an Rate Adaptation (ABR) algorithm_t+1. The selected bit rate may be adapted to the available throughput w from all available servers_tAnd the buffer occupancy rate B_tIs maintained within a safe area (i.e., between an overflow threshold and an underflow threshold). Bit rate and resolution listed in MPD fileThe level of (d) may be expressed as:

wherein r ∈ [ r ]¹...r^η]And l is e [ l¹...l^η]And η is the total number of available bit rates and resolution levels. With content resolution, each client 100 selects an appropriate level of bit rate and resolution within its device display resolution.

Embodiments of the present disclosure aim to eliminate buffer underrun and overflow problems. The measurement of playback buffer occupancy may be performed as follows:

wherein B is_t-1Is the buffer occupancy estimation in the previous step t-1, Size (seg)_t,r_t,l_t) At a bit rate r_tAnd resolution l_tThe size of the encoded segment t, I is when seg_tAn increase in buffer occupancy when fully downloaded and a decrease during video rendering. Other methods of estimating buffer occupancy are also possible.

For example, video clip arrivals to client 100 can be modeled as finite buffer, batch arrivals, M^xthe/D/1/K queue, where K is the buffer capacity. An example queue model for client 100 is shown in fig. 3. The model may establish a relationship between download throughput, available bit rate, buffer capacity, and expected buffer occupancy, allowing the client 100 to adapt the video bit rate to the estimated throughput while keeping the buffer occupancy at half the buffer capacity in steady state.

As shown in FIG. 3, the arrival of segments from different servers is modeled as a batch process, and is modeled by the arrival of segments from the corresponding servers s_iRespective arrival rate λ of_iAnd summed to calculate the total effective arrival rate. Each segment has a duration of τ seconds. Per secondThe single decoder in client 100 serves the segments at a rate of 1/τ segments/second. Let from server s_iIs w_ibps thereby download quality r_iA fragment of bps. Thus, it is fragmented toFragments/second arrive at the queue and are stored in the queue with a capacity of K seconds. To limit the number of bit rate switches, segments in the same batch can be downloaded with the same quality. Thus, from the server s_iThe arrival rate of isThe total arrival rate at the queue is the sum of all arrival rates in the batch, i.e., λ ═ Σ_iλ∑_i. Thus, the queue server utilization is ρ ═ Σ_iλ_iMu-w/r, w- Σ_iw_i. Expected average queue length O_k,ρAnd the expected buffer relaxation factor Bs_K，r，w＝K-O_k，ρCan be calculated using the analytical solution given by Brun and Garcia (j.appl.prob. (2000), 1092-.

The rate adaptation algorithm of some embodiments takes into account the aggregate arrival rates from different servers. Assume that a given video has a bitrate value R ═ R¹,r²,...,r^ηAre encoded, wherein if j < k, then r^j<r^k. The algorithm selects the bit rate r at time t such that the expected buffer relaxation factor Bs is closest to the estimated (or otherwise obtained) buffer occupancy B_t，

Ties are broken by supporting higher bit rates. Unlike previously known methods, Bs is an estimated aggregate throughput from different servers, not a function of the current bit rate and the total buffer capacity (or size).

Because the client 100 downloads segments from more than one server at the same time, the download scheduler 240 may track the current buffer level before sending segment requests to avoid exceeding the buffer capacity. For example, a client 100 with a 30 second buffer capacity and with a current buffer occupancy of 24 seconds plays a video with a 4 second segment duration, and five available servers may send requests to only one server. If the current buffer occupancy falls below 10 seconds, it is desirable for the download scheduler 240 to send all servers s_iA fragment request is sent. The download scheduler 240 according to some embodiments may check the data from the server s_iThe final throughput of (c). In a batch, the download dispatcher 240 may request segments that require earlier playback from servers with higher throughput values, e.g., as shown in algorithm 1 below.

Some embodiments may employ a bottleneck detection policy to improve performance. Since the download scheduler 240 preferably does not request the same segment from more than one server to avoid wasting resources, the bottleneck server may hinder the quality of playback experience (QoE) by causing a stall. To avoid this, the client 100 may identify the bottleneck server and not request new segments from the bottleneck server.

The download scheduler 240 may treat the server as a bottleneck server if the download throughput of the last segment is less than the lowest available bit rate. The scheduler 240 may request from the bottleneck server a redundant segment that has been downloaded by another server to track its current state. Once the throughput of the bottleneck server increases beyond the minimum available bit rate, the scheduler 240 may continue to download the next non-redundant segment from the bottleneck server. As previously described, a fragment may be requested from a server only if there are no other fragments downloads in progress. This avoids blocking servers that are already overloaded and downloading too many redundant segments, and also avoids throughput overestimation.

To implement the bottleneck detection policy, the download scheduler 240 may be given additional responsibility for maintaining a timeline of downloads. An example of this is explained with reference to fig. 4. Without bottleneck, client c₁And c₂The segments are acquired in parallel and they are in the order s, respectively₁,s₂,s₃,s₂,s₁,s₃Coming from the server without redundancy. In (server s)₂) In case of a bottleneck, both clients detect the server bottleneck during the download process and by doing so with fast throughput from s₁Re-request seg₃To allow rapid reaction. This causes redundant segments to be downloaded from the bottleneck server to track its status.

Embodiments may implement the following scheduling policy, for example, by scheduler 240. Different network conditions in the download path cause associated variations in throughput. Although the urgently needed fragments are downloaded in a greedy manner from the server with the highest throughput, they may arrive out of order due to dynamic network conditions and server load. The client 100 should not skip the segment, so the unavailability of the next segment for playback causes a pause even if a subsequent segment is available. For example, in FIG. 5, it can be seen that seg₄Not available, but segment seg₅And seg₆Is present in the buffer. When the client 100 completes seg₃Will stall until seg, since the effective buffer occupancy is now zero₄And (4) arriving. To avoid this, the scheduler 240 of the client 100 may re-request the seg from another server₄. Preferably, the re-request of the fragment is not too frequent, as this may result in a large number of redundant fragment requests. On the other hand, too few re-requests may cause stalls. In some embodiments, the scheduler 240 aborts ongoing requests and re-requests missing fragments when the contiguous portion of the buffer falls below 12 seconds.

Client device 104

An example architecture of the client device 104 is shown in fig. 19. As described above, the client device104 can communicate with other components of the system 50, including the server s, over the network 140 using standard communication protocols_iCommunication is performed.

The components of client device 104 may be configured in various ways. These components may be implemented entirely in software to be executed on standard computer server hardware, which may include one hardware unit or different computer hardware units distributed over various locations, some of which may require a communication network 140 for communication. Many of the components or portions thereof may also be implemented by Application Specific Integrated Circuits (ASICs) or field programmable gate arrays.

In the example shown in fig. 19, the client device 104 may be a commercially available server computer system based on a 32-bit or 64-bit intel architecture, and the processes and/or methods performed or carried out by the client device 104 are implemented in the form of programming instructions of one or more software components or modules 1922 stored on non-volatile computer-readable storage (e.g., hard disk) 1924 associated with the client device 104. At least some portions of the software modules 1922 may alternatively be implemented as one or more special-purpose hardware components, such as an Application Specific Integrated Circuit (ASIC) and/or a Field Programmable Gate Array (FPGA).

The client device 104 includes at least one or more of the following standard, commercially available computer components, all interconnected by a bus 1935:

(a) random Access Memory (RAM) 1926;

(b) at least one computer processor 1928, and

(c) external computer interface 1930:

(i) a Universal Serial Bus (USB) interface 1930a (at least one of which is connected to one or more user interface devices, such as a keyboard, a pointing device (e.g., a mouse or touchpad) 1932,

(ii) a Network Interface Connector (NIC)1930b connecting computer system 104 to a data communications network, such as internet 140; and

(iii) a display adapter 1930c that is connected to a display device 1934 such as a Liquid Crystal Display (LCD) panel device.

Client device 104 includes a number of standard software modules, including an Operating System (OS)1936 (e.g., Linux or Microsoft Windows), a browser 1938, and a standard library, such as a Javascript library (not shown). The operating system 1936 may include standard components for downloading from the server s, e.g., in accordance with the application by the client 100_iThe received data, causing the graphics to be rendered to a display 1934.

Boundaries between modules and components within software modules 1922 are exemplary and alternative embodiments may merge modules or impose an alternate decomposition of functionality of modules. For example, the modules discussed herein may be broken down into sub-modules to be executed as multiple computer processes, and optionally on multiple computers. Furthermore, alternative embodiments may combine multiple instances of a particular module or sub-module. Further, operations may be combined or the functionality of the operations may be distributed in additional operations in accordance with the invention. Alternatively, the acts may be embodied in a circuit structure implementing the functions, such as microcode for a Complex Instruction Set Computer (CISC), firmware programmed into a programmable or erasable/programmable device, configuration of a Field Programmable Gate Array (FPGA), design of a gate array or a fully custom Application Specific Integrated Circuit (ASIC), etc.

Each block of the flowchart of the process of the client device 104 may be performed by a module or portion of a module (of the software module 1922). The process may be embodied in a non-transitory machine-readable and/or computer-readable medium for configuring a computer system to perform the method. The software modules may be stored within and/or transmitted to a computer system memory to configure the computer system to perform the functions of the module.

Client device 104 typically processes information according to a program (e.g., a list of internally stored instructions such as a particular application program and/or operating system) and produces resultant output information via an input/output (I/O) device 1930. A computer process typically includes an executing (running) program or portion of a program, current program values and state information, and the resources used by the operating system to manage the execution of the process. A parent process may spawn other child processes to help perform the overall functionality of the parent process. Because the parent process specifically spawns the child processes to perform a portion of the overall functionality of the parent process, the functionality performed by the child processes (and grandchild processes, etc.) may sometimes be described as being performed by the parent process.

Flow diagrams depicting some processes according to embodiments of the present disclosure are shown in fig. 20 and 21.

Referring to fig. 20, the streaming process 2000 implemented at the client device 104 begins at step 2010 with the client application 100 of the client device 104 obtaining the MPD file, e.g., via the scheduler 240. The process 2000 is iterative and continues until all of the desired content has been delivered to the client 100.

The address of the MPD file may be stored in a web page where a user using a web browser of the client device 104 desires to play content. The MPD file may be stored, for example, at any one of the available servers s_iAnd can be from any one of the available servers s_iAnd (5) searching. In some embodiments, the MPD file is stored at a server s different from the server that stores the content_iAt the server of (1). The MPD file contains information about segments in the content to be streamed.

In step 2020, ABR controller 220 of client 100 selects a bit rate of segments of the current lot to be downloaded. For the first iteration, a default bit rate may be used as the starting bit rate. Advantageously, in some embodiments, the lowest available bit rate may be selected as the starting bit rate to achieve fast download and low start-up delay. For subsequent iterations, the bit rate may be determined according to a rate adaptation algorithm as described above. For example, the client 100 may also determine the available resolution according to the capabilities of the display adapter 1930c of the client device 104. ABR controller 220 passes the selected bit rate and, if applicable, the available resolution to scheduler 240.

In step 2030, the scheduler 240 downloads the segments from at least a subset of the available servers at the selected bit rate. For example, as shown in algorithm 1 and described above, the download scheduler 240 may request segments requiring earlier playback from a server with a higher throughput value.

At step 2040, the download scheduler 240 may detect whether any servers are bottleneck servers based on the fragments downloaded at step 2030. If one or more bottlenecks are detected (block 2045), the download scheduler 240 may remove them from the list of available servers and begin monitoring any such bottleneck servers 2050. The monitoring may continue in parallel with an iteration (not shown) of the batch fragment download. If any bottleneck servers become available again during the monitoring process, they can be restored to the list of available servers for subsequent iterations.

If no bottleneck is detected, the client 100 checks whether the streaming of the content is complete (e.g., via the download scheduler 240) at 2055. For example, the download scheduler 240 may check whether the segment number matches the last segment number in the MPD file. If the content is not fully streamed, process 2000 returns to bit rate selection at 2020. Otherwise, the process 2000 ends.

Turning to fig. 21, the bit rate selection process 2020 of process 2000 includes an operation 2110 of determining a playback buffer occupancy of the client device 100, e.g., by the buffer controller 210 and/or the ABR controller 220.

At operation 2120, the throughput estimator 230 determines an estimated throughput based on one or more segments downloaded by the scheduler 240, and this is received by the ABR controller 220.

At operation 2130, the ABR controller 220 receives the buffer occupancy and the estimated throughput and, for example, selects a bit rate such that the expected buffer relaxation factor Bs is closest to the estimated (or otherwise obtained) buffer occupancy B_tTo determine a bit rate that may optimize the quality of experience of the client device 104, where B_tDepending on the total throughput from the different servers.

Evaluation of experiments

A client 100 configured according to some embodiments is tested to evaluate its performance relative to known client configurations. In the following discussion, the client is referred to as MSDAH.

A. Methodology of

Network configuration file: for extensive testing of MSDAH, five different server profiles were employed. The parameters of the server profile are shown in table II. As can be seen from table II, each server profile includes throughput values that vary over time in a manner that is different from server to server. The different profiles P1 through P5 simulate heterogeneous workloads on the respective servers. P1 and P4 follow an up-down-up pattern, while P2 and P5 follow a down-up-down pattern. These profiles are adopted from the DASH industry (DASH-IF) forum guide. One of the servers is configured as a bottleneck server, corresponding to profile P3. The inter-variation duration in table II is the duration of each different throughput value with respect to the streaming session time.

Table II: characteristics of the network profile.

Video parameters: reference video samples from DASH datasets male rabbits (Big Buck Bunny, BBB) were used for testing purposes. It is encoded with an h.264/MPEG-4 decoding encoder at nine bit rate levels R ═ {4.2, 3.5, 3, 2.5, 2,1.5, 1, 0.75, 0.35} Mbps and a content resolution L ═ 240, 360, 480, 720, 1080, 1920} p, and includes a total video duration of about T ═ 600 s. These bit rate levels and resolution values correspond to the quality levels used in YouTube. The 1s, 2s and 4s fragments were tested for 30s, 60s and 120s buffer capacity (or size).

Comparison scheme: to evaluate performance, MSDAH is compared to four CDN-based load balancing rule schemes implemented in network server NGINX and can be summarized as follows: (a) polling: the set of requests to the DASH server is distributed based on a polling mechanism. (b) Minimum connection: the next request is distributed to the DASH server with low load. Thus, this approach attempts to not overload a busy server with many requests. (c) Session persistence: this approach always directs requests from the same client to the same DASH server except when the server is down. To accomplish this, it uses a hash function to determine which server to select for the next request. (d) Weighting: this scheme assigns a weight to each DASH server and this weight is used for load balancer decisions. For example, if the weight for a server is equal to three, the load balancer directs three requests to that server.

Experimental apparatus: a real set of track-driven on-demand (VoD) video streaming experiments were performed using a different number of real world network profiles (i.e., throughput variability) than DASH-IF guidelines, segment durations (i.e., 1s, 2s, and 4s), QoE metrics (i.e., average bit rate, bit rate switching, start-up delay, and stall), DASH clients, and DASH servers. The experimental setup included seven machines running Ubuntu 16.04LTS for DASH clients, DASH servers, and logging. One machine is a server station with 30GB RAM, core i7 CPU, and two GPUs GeForce GTX 295. The server station runs five virtual machines VM, each representing a DASH server that hosts video and runs a simple Apache HTTP server (v 2.4). Five machines with 4GB RAM and core i7 CPU, each running a Google Chrome browser to host a modified dash.js-based player (MSDAH player shown in fig. 2), act as DASH clients. All machines are connected via D-link gigabit switches and queued using a tc-NetEm network emulator, specifically a Hierarchical Token Bucket (HTB), along with a random fair Queuing (SFQ), to form the total capacity of the link between DASH client and server according to the above network profile. MSDAH takes into account the total bandwidth of the last measured throughput from all servers. The maximum playback buffer capacity (K) is set to 30s, 60s and 120s for segment durations of 1s, 2s and 4s, respectively. The underflow prevention threshold is set to 8 s.

B. Detailed description of the preferred embodiments

The proposed method is implemented as a modification to dash.js v 2.6.6. In particular, the extensible hypertext transfer request (XMLHttpRequest), the URL-based selector (baseureselector), and how the fragments are scheduled in the schedule controller (schedule controller) are modified to take advantage of multiple download sources. The rate adaptation algorithm described above is also added as a rule to the ABR controller (ABRController).

In particular, with reference to fig. 6, the following functionality is added to the DASH reference player DASH.

(a) The scheduling controller 240: multiple requests are controlled and generated at a time based on the bit rate selected by the rate adaptation algorithm and the next available server given by the URL based selector 620. It then places the request in extensible hypertext transfer request 610 to request the fragment from the corresponding server.

(b) URL based selector 620: the URLs of existing servers are obtained from a Manifest attribute (Manifest attribute)630 and sorted according to their final throughput to decide the next server to download the fragment.

(c) Extensible hypertext transfer request 610: the request given by the scheduling controller 240 is prepared in an appropriate xhr format by a method of adding an HTTP request (addHttpRequest) and modifying a request header (modifyRequestHeader). It then sends multiple requests in parallel to different DASH servers via http get (i.e., xhr. send ()), and receives responses for the respective segments.

(d) ABR controller 220: a set of bit rate decision rules is implemented to select the appropriate bit rate to be downloaded for the next parallel segment that takes into account the buffer occupancy and total throughput given by the buffer controller (BufferController)210 and the throughput estimator (throughput estimator)230, respectively. ABR rules 224 implement the rate adaptation algorithm described above and are responsible for performing ABR decisions based on throughput from the server. It then passes such bit rate decisions to the scheduling controller 240 and the rank order of the servers to the URL based selector 620. ABR controller 220 may include a get quality function 222 for determining the bit rate (e.g., via equation (3)).

Performance metrics are: to evaluate performance, the following QoE metrics are used. The average bit rate played by the DASH client is used to measure the overall quality. The number of changes represented and their size are also counted. Playback pause duration and the number of times the pause occurred are measured. The overall impact of performance metrics on QoE can be summarized by the following model:

here, the QoE of Z-segments played by DASH clients is their aggregate bitrate f (R)_t) And an adjacent playback segment f (R)_t+1)-f(R_t) Magnitude of difference therebetween, start-up delay T_sAnd a total playback pause T_stallAs a function of (c). f is an identity function, λ is 1, α and α_sIs the maximum representative bit rate.

C. Results and analysis

The experimental results described below include a set of trace-driven and real-world test cases. The test cases are divided into five scenarios as shown below. Experimental results show that MSDAH can significantly improve the QoE of viewers and deliver high quality video in all considered scenarios.

Scenario 1 (single server DASH versus msdoor): in a first test, one client requested video clips from a single server for five different network profiles P1 to P5. This is in contrast to five different clients from all five servers s₁To s₅The cases of requesting video clips with the corresponding network profiles P1 through P5 are compared. The idea is to compare the performance of a one-to-one client-server relationship of five clients with the performance of all clients using all servers by using the proposed MSDAH solution.

Fig. 7 shows the average bit rate played during the whole session. When one client requests a video clip from only one server, the client experiences an average bit rate of 2.9Mbps to 4Mbps under profiles P1 to P5 with different buffer sizes. The performance under profile P4 is better than all other profiles because it has the highest throughput and starts at the highest value. Clients connected to the server with profile P4 experience average bit rates of 3.8, 3.9, and 4.1Mb for buffer sizes of 30s, 60s, and 120s, respectively. However, for the msah of five servers with these five different network profiles shared by all clients, the clients experience average bit rates of 4.0, 3.9Mbps for buffer sizes 30s, 60s and 120s, respectively, on average.

Similarly, as shown in fig. 8, under a one-to-one client-server architecture, the number of representations changes from 3 to 37 for different buffer capacities. For the 30s and 60s buffers, the client experienced the least number of representation changes (i.e., 15 and 7) for profile P3. For P4, the minimum number of representation changes is 3 for a 120s buffer size. MSDAH experienced an average of 13.8, 3.4 and 3 representation changes over all of them (all 5 clients) for the corresponding buffer capacity (30s, 60s and 120 s).

Even if the server with the configuration file P3 has a bottleneck, the msda performs better without stalling. As shown in fig. 9, only clients requesting the server with profile P3 experience 10s and 64s stalls for 30s and 60s buffer capacity, and stalls twice and three times, respectively.

The small error bar in fig. 7 shows that msdoh is very fair in terms of average bit rate for playback between clients. Although the error bars representing the number of changes for the 30s buffer capacity are relatively large for MSDAH, the average number of changes is still less than the average number of changes represented for clients in a one-to-one client-server architecture, as shown in fig. 8.

The QoE score as described above is calculated for clients in a one-to-one server architecture, which are connected to servers with profiles P1 to P5, and the QoE score is calculated for clients running MSDAH. The results are shown in FIG. 10. As can be seen, the client with MSDAH has a QoE score of 2.35 to 2.41 (x 100). Msah is at least 3% better and up to 40% better than msah in a one-to-one client-server architecture for a buffer capacity of 30 s; and for a buffer capacity of 60s, msah is at least 3.4% better and up to 40% better than msah in a one-to-one client-server architecture. For 120s buffer capacity, QoE is comparable to the most recent value of P4, and 23% better than the minimum value of P2.

Scenario 2 (CDN-based load balancing rule versus msdoor): to check the robustness of msah in real world network environments, msah is compared to currently implemented CDN-based load balancing rule schemes. Five servers with five different network profiles (P1-P5) are running and shared by five concurrent clients. Each profile is used to throttle the total capacity between the DASH server and the set of clients.

Fig. 11 depicts the average bit rate played during a video streaming session of 596 s. In all buffer size configurations, it can be seen that msdoh achieves the best and most stable average bit rate ranging from 3.7Mbps to 4Mbps (average 3.9Mbps for all buffer capacity configurations) for all five clients and represents the least variation, as shown in fig. 12, compared to other CDN-based load balancing rule schemes. Also, msdas h ensures that the average bit rate is distributed fairly with variations of 0.2Mbps, 0.15Mbps, and 0.3Mbps among all clients for 30s, 60s, and 120s, respectively. Furthermore, two important observations are (i) the CDN least-connected scheme achieves the second best result for the average bit rate after msah, and (ii) the CDN persistence scheme yields the worst result compared to other schemes. This is because the CDN least-connect scheme applies an efficient request policy that distributes DASH client requests on DASH servers according to their capacity. This strategy sends requests to powerful servers that execute the requests faster and mitigates the negative impact of bottleneck servers. However, CDN persistence schemes create a fixed association (hash value) between a client and a server, where all requests from a given hash value are always forwarded to the same server. Therefore, a client connected to the bottleneck server will always receive a low bit rate, and this affects the average result for all clients. In contrast to CDN-based load balancing rules, MSDAH utilizes all existing DASH servers and downloads from all DASH servers in parallel. It successfully detects the bottleneck server through an intelligent bottleneck detection policy (see above) and therefore it avoids requests from this server.

Similarly, as shown in fig. 12, 13 and 14, in all buffer capacity configurations, MSDAH achieves the best average QoE (calculated using equation (4)) with zero stalls (and hence zero stall duration) representing a very low average number of changes and startup delay compared to CDN-based load balancing rule schemes. Compared to a CDN minimum connection scheme experiencing QoE for a range of 1.4 to 1.9 on average for all buffer capacity configurations, a CDN persistence scheme experiencing QoE for a range of 0.43 to 0.73 on average for all buffer capacity configurations, a CDN polling scheme experiencing QoE for a range of 1.05 to 1.14 on average for all buffer capacity configurations, and a CDN weighting scheme experiencing QoE for a range of 1.11 to 1.56 on average for all buffer capacity configurations, a client in the MSDAH experiences a high QoE for a range of 2.35 to 2.41 (x 100) on average for all buffer capacity configurations. For CDN-based rules, the average number of changes, pauses, and pause duration are high, except for CDN persistence schemes that achieve zero pauses.

CDN-based schemes experience low average QoE. Notably, the CDN polling scheme suffers from many stalls with long durations because the scheme uses a polling mechanism to distribute requests. Thus, during the turn of the bottleneck server (since the polling scheme is inevitably downloaded from the bottleneck server), the client needs to spend a long time downloading the segments, resulting in a video pause.

Scenario 3 (internet dataset test): the performance of MSDAH was studied by performing a set of experiments on the real world internet. Using a distributed DASH dataset; a distributed DASH dataset consists of data mirrored at three servers located in different geographical areas (france, australia and italy). 6 minutes of video encoded at 17 bit rate levels 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, is streamed with segment durations of 2s and 4 s. Five clients were run in two test scenarios: (i) all clients start a video session in parallel, and (ii) clients start incrementally at intervals of Δ t ═ 60 seconds after each other. Figure 15 represents the average bit rate selected by msah plotted against the number of bit rate changes for 2s and 4s fragment durations for running five clients in two tests. It shows that most of the time the client selects a bit rate of up to 6Mbps by downloading video segments from 2 or 3 servers in parallel. Also, in both tests, the number of changes indicated was 5-10. Two important observations can be made from this scenario. First, as the number of servers increases, the client achieves better performance. Five clients utilizing three servers together achieve an improvement of about 10% in the selected bit rate and require 25% less bit rate variation than a client using two servers. Second, when clients start and end at different times, they get a fairer share of bandwidth than they do when running together and thus achieve better performance in the second test.

Scenario 4 (fairness of MSDAH): to compare the fairness of msdoh clients to a single server client, two test cases were run, as shown in fig. 16: (a) running two clients simultaneously, one msda client (sharing five servers using profiles P1-P5) and one single DASH client (connecting to servers using profile P4), (b) two single DASH clients sharing servers using profile P4. It can be seen that the msdoh client is friendly when it runs with a single DASH client, and it shares the available bandwidth equally with a single DASH client (TCP fair sharing). During the streaming session, the msdoh client plays the video at the highest and most stable possible available bit rate (3.9-4.2Mbps), indicating that there is little change (configured as an average of 5 changes for all buffer capacities) and no pause. This is because the msah benefits from all existing servers, so the buffer occupancy of the msah often reaches maximum capacity in all (switched OFF state, see figures 16(c) and 16(d)) buffer configurations. This provides a more fair shared bandwidth for a single DASH client to improve its bit rate selection (3.7-4Mbps) compared to the client (2.7-4Mbps) in fig. 16(b), as shown in fig. 16 (a).

Scenario 5 (large scale deployment MSDAH): to evaluate the scalability of MSDAH, three real world test case experiments were performed in the NCL testbed at https:// ncl.sg. These experiments included 100 clients (rendering video via Google Chrome), 4 DASH servers with different profiles, and various total last mile bandwidth components for a single bottleneck link. To simulate a real-world network environment, the real network topology provided by the NCL testbed is used and the performance of the MSDAH is compared to CDN-based load balancing rule schemes (round robin, least connected, persistent connected, and weighted). The configuration of the test case is defined as follows: (a) 100 clients sharing a bottleneck network with a total bandwidth of 300Mbps and four servers { s ] with network profiles (60, 70, 80 and 90Mbps)₁,...,s₄(FIG. 18 (a)); (b)100 clients share a bottleneck network with a total bandwidth of 350Mbps and four servers { s } with network profiles (60, 70, 80 and 140Mbps)₁,...,s₄(FIG. 18 (b)); (c)100 clients share a bottleneck network with a total bandwidth of 400Mbps and four servers { s } with network profiles (60, 70, 80, and 190) Mbps₁,...,s₄(FIG. 18 (c)). In the case of a weighted load balancing rule, four servers s₁,...,s₄Are assigned weights 1, 2, 3 and 4, respectively. The results show that for different buffer configurations, the MSDAH client selects the best and most stable possible bit rate with high fairness (see error bars in fig. 18), the highest QoE, and the least representation change. The weighted load balancing rule has comparable performance to MSDAH in terms of average bit rate for 120s buffer capacity, since the server with the highest throughput is assigned a higher weight. The representation variation is also higher for weighted load balancing rules that result in overall QoE reduction. The small error bars for msah also indicate higher fairness to a large number of clients. The 100 clients start sequentially with an interval of 0.5 seconds between them (total interval of 50 seconds between the first and last), so the average bit rate and weighted load balancing rules in some cases for msah are slightly higher than the full capacity of 300Mbps, 350Mbps and 400Mbps in the three test cases.

Embodiments of the present disclosure have several advantages over prior art approaches in terms of robustness. For example, the present embodiment is highly fault tolerant. In a single server DASH delivery system as in the prior art, the critical failure mode is when a client is no longer able to communicate with a DASH server due to sudden fluctuations such as server bottlenecks, unreliable links, failed servers, or network conditions. In this case, CDN-based solutions may help, but they have been shown to introduce delays (i.e., DNS redirection) that may compromise player buffer occupancy and negatively impact end user QoE. However, embodiments of the present invention address these issues by utilizing multiple servers and avoiding affected links or servers due to the robust and intelligent bottleneck detection strategy detailed above. If the client cannot reach the server, the client will automatically ignore downloading the next segment from the server and only use the remaining servers. In addition, the client periodically keeps track of the downstream server's state by attempting to connect again with the downstream server or downloading segments that have already played if the server is considered a bottleneck.

In some cases, such as when multiple clients begin to compete for available bandwidth in a shared network environment (e.g., the last mile network), a client-side bottleneck may occur. The performance of MSDAH and CDN-based load balancing rules were tested for the case of the last mile bottleneck, where there was no traffic shaping at all five servers, but all five servers and clients shared a common link of 15 Mbps. In this case, all five clients play video at 3Mbps on average for MSDAH and for all CDN-based load balancing rules.

In the presence of a bottleneck server, a single server DASH client will suffer from stalls and frequent bit rate changes, which results in poor viewer QoE. In contrast, embodiments of the present disclosure use multiple servers and can effectively detect server bottlenecks that may impact viewer QoE based on a simple heuristic (e.g., if download throughput is less than the lowest available bit rate, embodiments may treat the servers as bottlenecks), e.g., as described above.

It should be understood that many further modifications and substitutions are possible in various aspects of the described embodiments. Accordingly, the described aspects are intended to embrace all such alterations, modifications and variations that fall within the spirit and scope of the appended claims.

Throughout this specification and the claims which follow, unless the context requires otherwise, the word "comprise", and variations such as "comprises" and "comprising", will be understood to imply the inclusion of a stated integer or step or group of integers or steps but not the exclusion of any other integer or step or group of integers or steps.

The reference in this specification to any prior publication (or information derived from it), or to any matter which is known, is not, and should not be taken as an acknowledgment or admission or any form of suggestion that the prior publication (or information derived from it) or known matter forms part of the common general knowledge in the field of endeavour to which this specification relates.