Patent Application
20220030308
The present disclosure relates to methods and devices for streaming content.
The increased availability of high-speed and high-bandwidth Internet connections has seen streaming services become almost ubiquitous in recent times. For example, HTTP Adaptive Streaming (HAS) is used by many such streaming services due to its ability to deliver high quality streams via conventional HTTP servers. It is thought that HAS systems will dominate Internet traffic by 2021.
The increase in video network traffic creates challenges for maintaining quality of user experience. One proposed method for addressing this is implemented in the Dynamic Adaptive Streaming over HTTP (DASH) framework. With DASH, a client typically accesses one server at a time and only redirects to another server via DNS redirect if a network bottleneck develops. The available media bitrate levels and resolutions are discrete. The clients that share an overloaded server or a bottleneck link limit themselves to low bitrate levels to avoid playback stalls. Conversely, clients that happen to be able to access less loaded servers can achieve a much higher video quality, so that the Quality-of-Experience (QoE) can vary widely from client to client.
DASH adapts dynamically to the network conditions thanks to its Adaptive BitRate (ABR) scheme that is based on heuristics like throughput measurements, playback buffer occupancy, or a combination of both. Furthermore, because it uses HTTP, it enables content providers to use existing content delivery network (CDN) infrastructure and simplifies the traversal through network middleboxes. Finally, it is highly scalable, and DASH clients can request and fetch video segments independently maintaining their local playback state in a decentralized way using stateless DASH servers.
A DASH system includes two main entities: a DASH server and a DASH client. The DASH server stores videos that are divided into small fixed segments (2-15 seconds) and each segment is encoded at various bitrate levels and resolutions. The segments of each video are then listed in a Media Presentation Description (MPD), which also includes metadata information of segment durations, codec/encryption details, and track correspondences (audio and subtitles). After an authentication phase, the client first fetches the MPD file of the video to be viewed, and then requests the segments sequentially based on its ABR controller decisions. The DASH server responds by sending the requested segments through HTTP. The ABR controller implements various heuristics to decide the bitrate to select for the next segments. Thus, it switches between available bitrates in case of network throughput variations and buffer occupancy changes.
In a DASH delivery system, every DASH client strives to improve its QoE by making the best bitrate decision that can accommodate the underlying network conditions without introducing stalls. The bitrate decision is performed using an ABR logic which relies on throughput estimations and buffer occupancy measurements. However, selecting the right decision in existing network infrastructures using DASH is difficult for at least two reasons:
The above-mentioned factors negatively affect the viewer QoE for DASH even in the presence of CDN-based redirection policies, and the problems are exacerbated in the presence of a bottleneck.
Client requests made to servers can be sequential-based or parallel-based.
In a sequential-based approach, the scheduler requests the video segments on a sequential basis one after the other, and the next segment cannot be downloaded until the requested one is fully downloaded. The ABR controller of the client may use a rate-based, buffer-based, or mixed-based heuristic for scheduling purposes.
In a parallel-based approach, the scheduler requests and downloads multiple segments in parallel from different video servers at the same time. In most cases this requires a kernel or network functionality modification in both the application layer and the transport layer. For example, some proposals include making use of multiple network interfaces employed in the client (e.g., WiFi and cellular) and the MPTCP protocol to download from different access networks. Another parallel-based implementation has been proposed by Queyreix et al. (IEEE CCNC, pages 580-581, 2017) and known by the name MS-Stream (Multiple-Source Streaming over HTTP). MS-Stream is a pragmatic evolving HAS based streaming solution for DASH that uses multiple customized servers to improve the end-user QoE. Although MS-Stream shows good performance in delivering high quality videos, the proposed solution has some limitations: (i) it uses Multiple Description Coding (MDC) for encoding video, which is not a standard now; (ii) the implementation needs a specific API at each server which is not in accordance with the DASH standard; (iii) there is a time overhead to combine the content before playing, which might not be acceptable for standard QoS and QoE; (iv) existing DASH storage servers and CDN architecture on the Internet require modification that might be significant; and (v) all the content downloaded is not playable, and there is significant overhead, such that the aggregate 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 to provide a useful alternative.
The present disclosure provides a method, performed at a client device, of streaming remotely located content, comprising:
The method may further comprise monitoring a playback buffer occupancy of the client device. In certain embodiments, the method comprises selecting a bitrate at which to download segments, based on the playback buffer occupancy of the client device and/or estimated throughput of the group of download servers.
The method may comprise identifying one or more bottleneck servers of the plurality of servers; and temporarily removing the one or more bottleneck servers from the group of download servers. Some embodiments may further comprise monitoring a throughput status of the one or more bottleneck servers by requesting, from the one or more bottleneck servers, download of a segment that is already being downloaded from a server in the group of download servers. The method may comprise, responsive to the throughput status of a bottleneck server exceeding a bitrate threshold, restoring the bottleneck server to the group of download servers.
The servers may be DASH servers.
The present disclosure also provides a client device for streaming remotely located content, comprising:
The instructions may further comprise instructions which, 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 further comprise instructions which, when executed by the at least one processor, cause the client device to select a bitrate at which to download segments, based on a playback buffer occupancy of the client device and/or estimated throughput of the group of download servers.
The instructions may further comprise instructions which, when executed by the at least one processor, cause the client device to: identify one or more bottleneck servers of the plurality of servers; and temporarily remove the one or more bottleneck servers from the group of download servers.
The instructions may further comprise instructions which, when executed by the at least one processor, cause the client device to: monitor a throughput status of the one or more bottleneck servers by requesting, from the one or more bottleneck servers, download of a segment that is already being downloaded from a server in the group of download servers. The instructions may further comprise instructions which, when executed by the at least one processor, cause the client device to, responsive to the throughput status of a bottleneck server exceeding a bitrate threshold, restore the bottleneck server to the group of download servers.
The present disclosure further provides a non-volatile computer-readable storage medium having instructions stored thereon 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 further provides a computing device for streaming remotely located content from a plurality of servers each of which hosts multiple copies of the content, said copies being encoded at different respective bitrates and each being divided into a plurality of segments that are arranged according to a time sequence, the client device comprising:
Embodiments may further comprise a buffer controller that is configured to monitor a playback buffer occupancy of the computing device.
Embodiments may further comprise an adaptive bitrate controller that is configured to: communicate with the buffer controller to receive the playback buffer occupancy; and select a bitrate at which to download segments, based on the playback buffer occupancy of the computing device and/or estimated throughput of the group of download servers.
Certain embodiments may comprise a throughput estimator for determining estimated throughput of the group of download servers.
The download scheduler may be configured to: identify one or more bottleneck servers of the plurality of servers; and temporarily remove the one or more bottleneck servers from the group of download servers. The download scheduler may further be configured to: monitor a throughput status of the one or more bottleneck servers by requesting, from the one or more bottleneck servers, download of a segment that is already being downloaded from a server in the group of download servers. In some embodiments, the download scheduler is configured to, responsive to the throughput status of a bottleneck server exceeding a bitrate threshold, restore the bottleneck server to the group of download servers.
Embodiments of the present disclosure will now be described, by way of non-limiting example only, with reference to the accompanying drawings in which:
Embodiments of the present disclosure relate to a method of streaming remotely located content, and to a client device configured to execute the method. At least some embodiments may be referred to herein as MSDASH (Multi-Server DASH).
In embodiments of the present disclosure, multiple clients may share more than one server in parallel. The sharing of servers results in achieving a uniform QoE, and a bottleneck link or an overloaded server does not create a localized impact on clients. The functionality of the presently disclosed embodiments is implemented in a distributed manner in the client-side application layer, and may be a modified version of the existing DASH client-side architecture, for example. Accordingly, the presently disclosed embodiments do not require any modifications to kernel or network functionality, 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:
Advantageously, embodiments of the present disclosure deal with bottlenecks efficiently by first determining the bottleneck or faulty server; ceasing to request future segments from the determined bottleneck server; and monitoring the status of the bottleneck server periodically for any changes (e.g., it may become a healthy server again), for example via probe-based passive or active measurements.
In addition, the presently disclosed embodiments provide a fairer and higher QoE than prior art approaches, and reach the best bitrate by leveraging the expanded bandwidth and link diversity from multiple servers with heterogeneous capacities. Embodiments of the present disclosure provide a purely client-driven solution where the modifications are restricted to the client-side application. Thus, the network and server sides remain unchanged, making implementation less complex and less prone to error.
In the present disclosure, the following symbols and abbreviations are used.
Embodiments of the present disclosure implement, at a client device, a bitrate selection process that is governed by a playback buffer occupancy of the client device, an estimated throughput of a group of servers from which the client device can request segments of data, or a combination of playback buffer occupancy and estimated throughput of the group of servers.
One possible architecture of a system 50 for streaming content is shown in
Typically, servers si mirror data that is provided by a content provider 110, usually via an Internet 140 connection. Other parties, such as over-the-top (OTT) services 120, may also provide content to the servers si for clients 100 to stream.
A client 100 according to the presently disclosed embodiments makes parallel requests for different segments from at least a subset, and preferably all, of the available servers si to maximise the throughput of the multiple servers. For example, as shown in
Each client 100 may be arranged to request segments from multiple servers simultaneously, which may be geographically distributed. Clients 100 may leverage the 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 servers or the network. All modifications are performed at client 100, and thus no changes are required to the kernel. Client 100 may represent a video player that supports a DASH system such as the reference player dash.js.
Each client 100 is characterized by capabilities of the device 102, 104 or 106 on which it executes (such as display resolution, memory and CPU), and may request various content types (e.g., animation, movie, news, etc.). Client 100 may implement one or more adaptive bitrate (ABR) processes.
Further details of an example architecture of a client 100 are shown in
For example, for each segment download tϵ[1, . . . , Z] where Z denotes the total number of downloading steps, the client 100 may use ABR controller 220 to choose the appropriate bitrate ri which adapts to the download throughput of each source si with iϵ[1, . . . , M] and playback buffer occupancy where M represents the total number of existing servers. Then, client 100 may concurrently request (via scheduler 240) multiple successive segments from M servers s1. When the playback buffer monitored by buffer controller 210 reaches its maximum capacity K, client 100 may trigger (via buffer controller 210) an event to stop downloading, and to decrease the number of servers gradually down to a single server, for avoidance of buffer overflow. The number of servers used may be increased until it reaches M whenever there is room to accommodate segments, i.e., when maximum buffer capacity is not reached. In some embodiments, system 50 may be modelled by representing it by a direct or undirected graph G=(V, E) where V=C∪S is the set of clients C={c1, . . . , cN} and servers S={s1, . . . , sM}. For modelling purposes, a full mesh network may be assumed, i.e., Fat-Tree topology (e.g., OSPF mesh network) where every client cj ϵC with j=[1 . . . N] has connectivity to each si ϵS and i=[1 . . . M], and thus a client 100 uses diverse multiple links to fetch successive segments simultaneously from existing servers.
When the playback buffer becomes full then the client 100 stops downloading segments and decreases the total number of used servers gradually down to one. Otherwise, if there is room in the playback buffer, then the client 100 may increase the number of servers until it utilizes all existing servers (full server utilization).
Due to congestion and network variability, at any time, the link to server si may become slow and the server would then be considered to be a bottleneck server. In this situation, the client 100 suffers from stalls since the delayed segments from the bottleneck servers lead to a drain of the client playback buffer. To avoid this issue, in certain embodiments, the client 100 may stop fetching future segments from the bottleneck servers and instead fetch from only the M−H remaining servers, where His the total number of bottleneck servers. Each client 100 may keep track of the statuses of bottleneck servers by requesting previous segments with the lowest quality, and once they can provide service and satisfy client requirements again, resume use of the bottleneck servers.
In certain embodiments, before starting a streaming session (i.e., either live or on demand) and after an authentication process, every client 100 may first fetch an MPD file (typically, an XML file that includes a description of the resources forming a streaming service), and then the video segments in parallel from the existing DASH servers. The segments of each video v are stored in the set of DASH servers S, each video of T seconds is divided into a Z (=T/τ) segments, and each segment segt where tϵ[1 . . . Z] has a fixed duration τ seconds and is encoded at various bitrate levels Rv and resolutions Lv denoted η.
During each step t, the player (client) cj selects a suitable bitrate level rt+1 for the next segments to be downloaded using the rate adaptation (ABR) algorithm. The selected bitrate may adapt to the available throughput wt from all the available servers, and maintain the buffer Bt occupancy within a safe region (i.e., between underflow and overflow thresholds). The levels of bitrate and resolutions listed in the MPD file can be represented as:
where rϵ[r1 . . . rη] and lϵ[l1 . . . lη] with η being the total number of available bitrate and resolution levels. Having the content resolution, each client 100 chooses a suitable level of bitrate and resolution which is in the range of its device display resolution.
Embodiments of the present disclosure aim to eliminate buffer underrun and overflow issues. Measurement of the playback buffer occupancy may be performed as follows:
where Bt−1 is the buffer occupancy estimate in the previous step t−1, Size(segt, rt, lt) is the size of the segment t which is encoded at bitrate rt and resolution lt, and I is the increase in the buffer occupancy when segt is fully downloaded and the decrease during the video rendering. Other methods of estimating buffer occupancy are also possible.
The arrival of video segments at client 100 may be modelled as a finite buffer, batch-arrival, Mx/D/1/K queue, for example, where K is the buffer capacity. An example queueing model for the client 100 is illustrated in
As illustrated in
segments per second and get stored in the queue with a capacity of K seconds. To limit the number of bitrate switches, segments in the same batch may be downloaded at the same quality. Thus, the arrival rate from server si is
The total arrival rate at the queue is the sum of all the arrival rates in the batch, i.e., λ=Σiλi. Thus, the queue server utilization is ρ=Σiλi/μ=w/r, where w=Σi wi. The expected average queue length Ok,ρ and expected buffer slack BsK,r,w=K−Ok,ρ may be computed using the analytical solution given by Brun and Garcia (J. Appl. Prob. (2000), 1092-1098).
The rate adaptation algorithm of certain embodiments considers the aggregate arrival rate from different servers. Let a given video be encoded with bitrate values R={r1, r2, . . . , rη}, with rj<rk if j<k. The algorithm selects the bitrate r at time t such that the expected buffer slack Bs is closest to the estimated (or otherwise obtained) buffer occupancy Bt,
breaking ties by favoring the higher bitrate. Unlike previously known approaches, Bs is a function of the estimated aggregate throughput from the different servers other than current bitrate and total buffer capacity (or size).
Because client 100 concurrently downloads segments from more than one server, the download scheduler 240 may keep track of current buffer levels before sending a segment request, to avoid exceeding the buffer capacity. For example, a client 100 with 30 seconds of buffer capacity and with a current buffer occupancy of 24 seconds playing a video with 4 seconds segment duration and five available servers can send a request to only one server. If the current buffer occupancy drops below 10 seconds, the download scheduler 240 is expected to send a segment request to all the servers si. The download scheduler 240 according to certain embodiments may check for the last throughput from the servers si. In a batch, the download scheduler 240 may request segments that are needed earlier for playback from servers with higher throughput values, for example as shown in Algorithm 1 below.
Certain embodiments may employ a bottleneck detection strategy to improve performance. Since the download scheduler 240 preferably does not request the same segment from more than one server to avoid wastage of resources, a bottleneck server can hamper the playback quality of experience (QoE) by causing stalls. To avoid this situation, the client 100 can identify the bottleneck server and refrain from requesting a new segment from it.
The download scheduler 240 may consider a server as a bottleneck server if the download throughput of the last segment is less than the lowest available bitrate. The scheduler 240 may request a redundant segment from a bottleneck server that is already being downloaded by another server to keep track of the current state of it. Once the throughput of the bottleneck server increases beyond the lowest available bitrate, the scheduler 240 may continue downloading the next non-redundant segment from it. As described earlier, a segment may be requested from a server only if there is no other segment download in progress. This avoids choking an already overloaded server as well as downloading too many redundant segments, and also avoids throughput overestimation.
To implement a bottleneck detection strategy, the download scheduler 240 may be given the additional responsibility of maintaining the time-line of downloads. An example of this situation is explained with reference to
Embodiments may implement a scheduling policy, by scheduler 240 for example, as follows. The different network conditions in the download path cause variance in the associated throughput. Although the imminently required segments are downloaded from the server with the highest throughput in a greedy fashion, they may arrive out of order due to dynamic network conditions and server loads. The client 100 should not skip a segment, so the unavailability of the next segment for playback causes stalls even though subsequent segments are available. For example, in
An example architecture of a client device 104 is shown in
The components of the client device 104 can be configured in a variety of ways. The components can be implemented entirely by software to be executed on standard computer server hardware, which may comprise one hardware unit or different computer hardware units distributed over various locations, some of which may require the communications network 140 for communication. A number of the components or parts thereof may also be implemented by application specific integrated circuits (ASICs) or field programmable gate arrays.
In the example shown in
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 interfaces 1930:
The client device 104 includes a plurality of standard software modules, including an operating system (OS) 1936 (e.g., Linux or Microsoft Windows), a browser 1938, and standard libraries such as a Javascript library (not shown). Operating system 1936 may include standard components for causing graphics to be rendered to display 1934, in accordance with data received by client application 100 from the download servers si, for example.
The boundaries between the modules and components in the software modules 1922 are exemplary, and alternative embodiments may merge modules or impose an alternative decomposition of functionality of modules. For example, the modules discussed herein may be decomposed into submodules to be executed as multiple computer processes, and, optionally, on multiple computers. Moreover, alternative embodiments may combine multiple instances of a particular module or submodule. Furthermore, the operations may be combined or the functionality of the operations may be distributed in additional operations in accordance with the invention. Alternatively, such actions may be embodied in the structure of circuitry that implements such functionality, such as the micro-code of a complex instruction set computer (CISC), firmware programmed into programmable or erasable/programmable devices, the configuration of a field-programmable gate array (FPGA), the design of a gate array or full-custom application-specific integrated circuit (ASIC), or the like.
Each of the blocks of the flow diagrams of the processes of the client device 104 may be executed by a module (of software modules 1922) or a portion of a module. The processes may be embodied in a non-transient machine-readable and/or computer-readable medium for configuring a computer system to execute 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.
The client device 104 normally processes information according to a program (a list of internally stored instructions such as a particular application program and/or an operating system) and produces resultant output information via input/output (I/O) devices 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 functions performed by child processes (and grandchild processes, etc.) may sometimes be described as being performed by the parent process.
Flow diagrams depicting certain processes according to embodiments of the disclosure are shown in
Referring to
An address of the MPD file may be stored in a webpage at which a user using a web browser of client device 104 desires to play content. The MPD file may be stored at, and retrieved from, any one of the available servers si, for example. In some embodiments, the MPD file is stored at a server which is different than the server si that stores the content. The MPD file contains information about the segments in the content to be streamed.
At step 2020, the ABR controller 220 of client 100 selects a bitrate for the current batch of segments to be downloaded. For the first iteration, a default bitrate may be used as the starting bitrate. Advantageously, in some embodiments, the lowest available bitrate may be selected as the starting bitrate, to enable fast download and low startup delay. For subsequent iterations, the bitrate may be determined according to a rate adaptation algorithm as described above. Client 100 may also determine an available resolution according to the capability of display adapter 1930c of client device 104, for example. ABR controller 220 passes the selected bitrate and, if applicable, the available resolution to scheduler 240.
At step 2030, scheduler 240 downloads segments from at least a subset of the available servers at the selected bitrate. The download scheduler 240 may request segments that are needed earlier for playback from servers with higher throughput values, for example as shown in Algorithm 1 and as described above.
At step 2040, the download scheduler 240 may detect, based on the segments downloaded at step 2030, whether any servers are bottleneck servers. If one or more bottlenecks are detected (block 2045), download scheduler 240 may remove them from the list of available servers, and begin monitoring any such bottleneck servers, at 2050. Monitoring may continue in parallel to iterations of batch segment downloads (not shown). If any bottleneck servers become available again during the course of monitoring, they may be restored to the list of available servers for subsequent iterations.
If no bottlenecks are detected, then at 2055, the client 100 (for example, via download scheduler 240) checks whether streaming of the content is complete. For example, the download scheduler 240 may check whether a segment number matches a last segment number in the MPD file. If the content has not been fully streamed, the process 2000 returns to bitrate selection at 2020. Otherwise, the process 2000 ends.
Turning to
At operation 2120, throughput estimator 230 determines an estimated throughput based on one or more of the segments downloaded by scheduler 240, and this is received by the ABR controller 220.
At operation 2130, the ABR controller 220 receives the buffer occupancy and estimated throughput, and determines a bitrate that can optimise the quality of experience of client device 104, for example by selecting a bitrate such that the expected buffer slack Bs is closest to the estimated (or otherwise obtained) buffer occupancy Bt, where Bt depends on the aggregate throughput from the different servers.
Experimental Evaluation
A client 100 configured in accordance with certain embodiments was tested to evaluate its performance with respect to known client configurations. In the following discussion, the client is referred to as MSDASH.
A. Methodology
Network Profiles: To extensively test MSDASH, five different server profiles were adopted. The parameters of the server profiles are shown in Table II. As can be seen from Table II, each server profile includes a throughput value that varies over time in a way which differs from server to server. The different profiles P1 to P5 emulate a heterogeneous workload on the respective servers. P1 and P4 follow an up-down-up pattern, whereas P2 and P5 follow a down-up-down pattern. These profiles are adopted from the DASH Industry (DASH-IF) Forum Guidelines. 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 over the streaming session time.
Video Parameters: The reference video sample Big Buck Bunny (BBB) from the DASH dataset was used for testing purposes. It is encoded with the H.264/MPEG-4 codec at nine bitrate levels R={4.2, 3.5, 3, 2.5, 2, 1.5, 1, 0.75, 0.35} Mbps, content resolutions L={240, 360, 480, 720, 1080, 1920}p and comprises approximately T=600 s of total video duration. These bitrate level and resolution values correspond to quality levels that are used in YouTube. Testing was performed on 1 s, 2 s and 4 s segments for 30 s, 60 s, and 120 s buffer capacities (or sizes).
Comparison Schemes: To evaluate performance, MSDASH was compared against four CDN-based load balancing rule schemes which are implemented in the web server NGINX and can be summarised as follows: (a) Round Robin: The set of requests to the DASH servers are distributed based on a round robin mechanism. (b) Least Connected: The next requests are assigned to the DASH servers with low load. Thus, this scheme tries not to overload a busy server with many requests. (c) Session Persistence: this scheme always directs the request from the same client to the same DASH server except when this server is down. To achieve this, it uses a hash function to determine which server to select for next request. (d) Weighted: this scheme assigns a weight for each DASH server, and this weight is used in the load balancer decision. For example, if weight equals three for a server, then the load balancer will direct three requests to this server.
Experimental Setup: A set of realistic trace-driven on-demand (VoD) video streaming experiments was performed using different real-world network profiles (i.e., throughput variability) from the DASH-IF Guidelines, segment durations (i.e., 1 s, 2 s, and 4 s), QoE metrics (i.e., average bitrate, bitrate switch, startup delay, and stalls), number of DASH clients and DASH servers. The experimental setup included seven machines running Ubuntu 16.04 LTS for DASH clients, DASH servers, and logging. One machine was a server station with 30 GB RAM, Core i7 CPU and two GPUs GeForce GTX 295. The server station ran five Virtual Box VMs, each VM representing a DASH server which hosts the video and runs a simple Apache HTTP server (v2.4). Five machines with 4 GB RAM and Core i7 CPUs act as DASH clients, each machine running the Google Chrome browser to host a modified dash.js based player (the MSDASH player shown in
B. Implementation
The proposed method was implemented as a modification to dash.js v2.6.6. In particular, modifications were made to XMLHttpRequest, BaseURLSelector and how the segments will be scheduled in SchedulerController, in order to make use of multiple download sources. The rate adaptation algorithm described above was also added as Rule in the ABRController.
In particular, with reference to
Performance Metrics: To evaluate performance, the following QoE metrics were used. The overall quality was measured using the average bitrate played by a DASH client. The number of changes in representations, and their magnitudes, were also counted. The playback stall durations and the number of occurrences of a stall were measured. The overall effect of the performance metrics on QoE can be summarised by the following model:
Here, the QoE for the Z segments played by a DASH client is a function of their aggregate bitrate f(Rt), and the magnitude of the difference in adjacently played segments f(Rt+1)−f(Rt), start-up delay Ts and total playback stalls Tstall. f is the identity function, λ=1, α and αs are the maximum representation bitrate.
C. Results and Analysis
The experimental results described below comprise a set of trace-driven and real-world test cases. The test cases are divided into five scenarios as shown below. The experimental results show that MSDASH can significantly improve the viewer QoE and deliver a high quality video in all considered scenarios.
Scenario 1 (Single Server DASH vs MSDASH): In the first test, one client requests video segment from a single server for five different network profiles P1 to P5. This is compared to the case where five different clients are requesting video segments from all the five servers s1 to s5 with respective network profiles P1 to P5. The idea is to compare the performance of a one-to-one client-server relationship for five clients with the performance when all clients use all servers using the proposed MSDASH solution.
Similarly, under a one-to-one client-server architecture, as shown in
MSDASH also performs better, with no stalls, even though the server with profile P3 has a bottleneck. As shown in
The small error bar in
A QoE score as discussed above was computed for the clients in the one-to-one server architecture, connecting to servers with profile P1 to P5, and for the clients running MSDASH. The results are shown in
Scenario 2 (CDN-based Load Balancing Rules vs MSDASH): To check the robustness of MSDASH in real-world network environments, MSDASH was compared with CDN-based load balancing rule schemes that are presently implemented. Five servers with five different network profiles (P1 to P5) were run, and were shared by five concurrent clients. Each profile was used to throttle the total capacity between a DASH server and the set of clients.
Similarly, in all buffer capacity configurations, MSDASH achieves the best average QoE (computed using Eq. (4)) with zero stalls (and thus zero stall duration), very low average number of changes in representation and startup delay compared to CDN-based load balancing rule schemes as shown in
The CDN-based schemes experience a low average QoE. Of note, the CDN round robin scheme suffers from many stalls having long duration, because this scheme uses the round robin mechanism to distribute the requests. Thus, during the turn of the bottleneck server (which is inevitably downloaded from because of the round robin scheme), the segments take long times to be downloaded by the clients, leading to video stall.
Scenario 3 (Internet Dataset Test): The performance of MSDASH was investigated by performing a set of experiments over the real-world Internet. The Distributed DASH Dataset was used; it consists of data mirrored at three servers located in different geographical areas (France, Austria, and Italy). A 6 minute video encoded at 17 bitrate 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 was streamed with segment durations of 2 s and 4 s. Five clients were run in two test scenarios: (i) all of the clients start video sessions in parallel, and (ii) clients start incrementally after each other with a gap of Δt=60 seconds.
Scenario 4 (Fairness of MSDASH): To compare the fairness for an MSDASH client with a single-server client, two test cases were run as shown in
Scenario 5 (Large-scale Deployment of MSDASH): To evaluate the scalability of MSDASH, three real-world test case experiments were performed in the NCL testbed at https://ncl.sg. These experiments consisted of 100 clients (rendering video over Google Chrome), 4 DASH servers with different profiles, and various total last-mile bandwidths of the single bottleneck link. To emulate a real-world network environment, a realistic network topology provided by the NCL testbed was used, and the performance of MSDASH was compared to the CDN-based load balancing rule schemes (round robin, least connected, persistent connection, and weighted). The configuration of the test cases was defined as follows: (a) 100 clients sharing a bottleneck network with total bandwidth of 300 Mbps and four servers {s1, . . . , s4} with network profiles (60, 70, 80, and 90) Mbps (
Embodiments of the present disclosure have several advantages over prior art approaches with respect to robustness. For example, the present embodiments are highly fault tolerant. In a single server DASH delivery system as in the prior art, the critical failure mode is when the client can no longer communicate with the DASH server such as due to a server bottleneck, unreliable link, faulty server, or sudden fluctuation in the network condition. In this situation, CDN-based solutions might help, but they have been shown to introduce a delay (i.e., DNS redirection) which may harm the player buffer occupancy and affect the end-user QoE negatively. However, embodiments of the present disclosure address these issues by leveraging multiple servers and avoiding the affected link or server thanks to the robust and smart bottleneck detection strategy detailed above. If the client is unable to reach the server, it will automatically ignore downloading the next segments from it and use only the remaining servers. Moreover, the client periodically keeps tracks the status of the down servers by either trying to connect with them again, or downloading the already played segments if the server is considered as a bottleneck.
In some circumstances, such as when multiple clients start competing for the available bandwidth in a shared network environment (e.g., last mile network), a client-side bottleneck may occur. The performance of MSDASH and CDN-based load balancing rules was tested for the case of a last mile bottleneck where there is no traffic shaping at all five servers, but all five servers and clients share a common link of 15 Mbps. In this scenario, all five clients played the video at 3 Mbps on average for both MSDASH as well as 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 bitrate changes which results in a poor viewer QoE. In contrast, embodiments of the present disclosure use multiple servers and are able efficiently to detect a server bottleneck that may affect the viewer QoE based on a simple heuristic (e.g., embodiments may consider a server as a bottleneck if the download throughput is less than the lowest available bitrate), for example as discussed above.
It will be appreciated that many further modifications and permutations of various aspects of the described embodiments are possible. 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 that 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.
| Number | Date | Country | Kind |
|---|---|---|---|
| 10201807988R | Sep 2018 | SG | national |
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/SG19/50461 | 9/13/2019 | WO | 00 |
