A novel adaptive logic for dynamic adaptive streaming over HTTP

Accepted Manuscript A Novel Adaptive Logic for Dynamic Adaptive Streaming over HTTP Waqas ur Rahman, Kwangsue Chung PII: DOI: Reference:

S1047-3203(17)30199-2 https://doi.org/10.1016/j.jvcir.2017.10.007 YJVCI 2074

To appear in:

J. Vis. Commun. Image R.

Received Date: Revised Date: Accepted Date:

11 March 2017 28 July 2017 20 October 2017

Please cite this article as: W.u. Rahman, K. Chung, A Novel Adaptive Logic for Dynamic Adaptive Streaming over HTTP, J. Vis. Commun. Image R. (2017), doi: https://doi.org/10.1016/j.jvcir.2017.10.007

This is a PDF file of an unedited manuscript that has been accepted for publication. As a service to our customers we are providing this early version of the manuscript. The manuscript will undergo copyediting, typesetting, and review of the resulting proof before it is published in its final form. Please note that during the production process errors may be discovered which could affect the content, and all legal disclaimers that apply to the journal pertain.

A Novel Adaptive Logic for Dynamic Adaptive Streaming over HTTP Waqas ur Rahmana, Kwangsue Chunga

W. Rahman and K. Chung are with the aDepartment of Electronics and Communications Engineering, Kwangwoon University, Seoul, Korea

Correspondence to: Prof. Kwangsue Chung Department of Electronics and Communications Engineering, Kwangwoon University Chambit 809, 447-1 Wolgye-Dong, Nowon-Gu, Seoul, Republic of Korea Tel: +82-2-940-5134 Fax: +82-2-919-3218 E-mail: [email protected]

Editor’s Information Classification Scheme:  Video Communication over Networks  Video Streaming

1

A Novel Adaptive Logic for Dynamic Adaptive Streaming over HTTP

Waqas ur Rahman, Kwangsue Chung

Abstract - In this paper, we propose an estimation method that estimates the throughput of upcoming video segments based on variations in the network throughput observed during the download of previous video segments. Then, we propose a rate-adaptive algorithm for Hypertext Transfer Protocol (HTTP) streaming. The proposed algorithm selects the quality of the video based on the estimated throughput and playback buffer occupancy. The proposed method selects high-quality video segments, while minimizing video quality changes and the risk of playback interruption, improving user’s experience. We evaluate the algorithm for single- and multi-user environments and demonstrate that it performs remarkably well under varying network conditions. Furthermore, we determine that it efficiently utilizes network resources to achieve a high video rate; competing HTTP clients achieve equitable video rates. We also confirm that variations in the playback buffer size and segment duration do not affect the performance of the proposed algorithm.

Keywords - HTTP-Based Video Streaming; Quality of Experience; Video Rate Adaptation Algorithm; Video Streaming Scheme

2

1. Introduction According to [1], 75 percent of global mobile data traffic will be mobile video traffic by 2019. Hypertext transfer protocol (HTTP) streaming video services have become a cost-effective means for transmitting multimedia content. This trend is expected to continue as the Internet infrastructure has evolved to support HTTP, and HTTP is firewall friendly. Additionally, an HTTP server does not have to maintain a session state; therefore, a large number of streaming clients can be supported [2]. HTTP-based video streaming solutions provide multiple representations (e.g., different bitrate/quality) of the same content, and divide those representations into small segments. The content is stored at the server, and the rate-adaptive algorithm at the client decides which segment to download next. The estimation of throughput is important in the selection of the next segment. The segment throughput is calculated as the ratio of the segment size divided by the time it takes to download that segment. Put simply, measured segment throughput can be used as the throughput estimate for the next segment [3]. However, due to short term-fluctuations, a throughput estimate calculated in this manner will result in a high frequency of fluctuations. Ran et al. [4] use the median of the throughput of the last several segments to estimate the throughput of the next segment. Rahman et al. [5] show that the McGinely dynamic indicator offers a stable response to throughput fluctuations while maintaining a stable playback buffer. The moving average technique [5] is accurate for slow throughput variations, but reacts slowly to sudden variations in the throughput. HTTP clients make an estimate of future throughput from past observations to select the video rate for the next segment [3], [6], [7]. An accurate estimate of the throughput becomes an

3

important challenge for the client. An inaccurate estimation may lead to video bit rates that degrade the user’s experience. Many rate adaptive algorithms add playback buffer occupancy as an adjustment parameter in addition to throughput estimation [5], [8]-[12]. The algorithms attempt to maximize the quality of the video by meeting conflicting objectives in a manner that improves the user’s viewing experience. Some of the potential objectives include selecting the highest feasible set of video bit rates, avoiding needless video bitrate changes, and preserving the buffer level to avoid an interruption in the playback [13]-[17]. The rate adaptation algorithms work fairly well when a client operates alone. When the client buffer is full, the client enters a periodic On-Off phase [18]. During the On-Off phase, the competing clients result in bandwidth underutilization and unfair bandwidth sharing [18]-[20]. In [18], the authors observed unfair bandwidth sharing among three Microsoft Smooth Streaming clients. This behavior is observed in the presence of the competing TCP as well as other competing HTTP clients. In [21], the authors suggest that in the presence of competing HTTP clients, the rate-adaptive algorithm selects variable and low-quality video, which is undesirable to the users. In this respect, an adaptive video algorithm must strive to choose the highest feasible video rates to maximize the user’s experience [20]. In addition, the competing clients should be able to achieve comparable video rates while striving to select the highest feasible video rates. In this paper, we first propose an estimation algorithm that accurately estimates the throughput based on variations in the network throughput. It offers a stable response to small and short term fluctuations and is sensitive to persistent and large fluctuations. We then propose a rate adaptation algorithm that dynamically selects the video bit rates based on the estimated throughput and the playback buffer occupancy. The objective of the proposed algorithm is to improve the user’s viewing experience. We adopt three rate-adaptive algorithms as benchmarks.

4

In addition to the rate-adaptive algorithm proposed in our previous work [5], we adopt the algorithms proposed in [8] and [22], as benchmarks to demonstrate the efficiency of our proposal. In the results, we refer to the algorithms proposed in [5], [8], and [22] as BBA, AAA, and SARA, respectively. We analyze the algorithms under varying network conditions, buffer sizes, and segment durations. We evaluate the proposed algorithm for single and multi-client scenarios. Our key results can be summarized as follows: 

The proposed algorithm streams high-quality video and avoids unnecessary video rate changes while avoiding playback interruption.



In the single client scenario, the proposed rate adaptive algorithm achieves average video rate better than BBA, AA and SARA up to 58%, 37.5% and 7% respectively. The proposed algorithm achieves comparable video rate changes compared to BBA and AAA and achieves up to 6.5 times less number of video rate changes compared to SARA.



Furthermore, in a multi-client environment, we show that the proposed scheme efficiently utilizes network resources to stream high-quality video and that the HTTP clients achieve equitable video rates.



We perform experiments to show that irrespective of the buffer size and segment duration, the proposed algorithm improves the user’s experience.

It is important to note that this work does not attempt to reduce the extent of multi-client problems. Its objective is to show that the proposed algorithm performs better than other state-ofthe-art algorithms in a multi-client environment. The remainder of this paper is organized as follows: Section 2 offers an overview of HTTP adaptive streaming, and reviews existing video streaming algorithms. Section 3 presents the proposed throughput estimation algorithm. Section 4 explains our throughput- and buffer-based

5

rate adaptive algorithm. Section 5 provides the simulation results. Finally, Section 6 concludes the paper.

2. Overview of HTTP Streaming 2.1. HTTP adaptive streaming HTTP adaptive streaming functions by monitoring a network in real time and adjusting the quality of the video stream accordingly without resetting the TCP connection. Fig. 1 shows the basic model of adaptive HTTP streaming, which requires the server to store multiple versions of the multimedia content. On the server side, the content annotation module provides information concerning the characteristics of the stored multimedia content. The client initiates a request for information about the stored content, which is known as metadata. In response to the request from the client, the server returns the metadata to the client. The media preparation module provides tools for encoding and encapsulation, so that the content can be presented and efficiently delivered to the client in the correct format. On the client side, the scheduling module is responsible for scheduling the download of upcoming segments. During the download of the segments, the bandwidth estimation module estimates the throughput. The adaptation module selects a suitable bitrate based on the received metadata and system conditions, such as the throughput and occupancy of the playback buffer. Once a segment is downloaded, it is temporarily stored in the playback buffer that feeds the player’s decoder.

6

CLIENT Scheduling

SERVER HTTP Requests

Adaptation

HTTP Responses (metadata)

Bandwidth Estimation

HTTP Requests

HTTP Responses (media)

Content Annotation

Media Preparation

Playback Buffer

Fig. 1 HTTP streaming architecture

2.2. Related work Currently, several methods have been proposed to estimate throughput. Akhshabi et al. [6] evaluate the performance of Microsoft Smooth Streaming and the Netflix player using the running average of the throughput of several segments as the estimated throughput. This method performs well under persistent throughput variations. Jiang et al. [20] use the harmonic mean of the throughput of the last 20 downloaded segments to estimate the throughput of the next segment. The outliers of the throughput do not influence the estimated throughput, but the method shows delay during persistent throughput variations. Many commercial clients estimate the throughput of the next segment by calculating the moving average of the previously downloaded segments [16]. This method is late to respond to large variations in the throughput. The VLC media player [23] uses the averages of all previous throughputs as the estimated throughput to download the next segment. This method responds slowly to actual throughput variations, which increases the risk of buffer underflow. QoE-aware DASH (QDASH) [24] introduces a proxy server between the client and the server to accurately measure the network throughput. However, QDASH has QoE degradation due to frequent quality-level changes. The

7

proposed estimation method offers an aggressive or stable response based on the behavior of the network throughput. Most of the throughput estimation methods proposed so far either have an aggressive response or robust to throughput variations which results in unnecessary video rate changes or increases the risk of buffer underflow respectively. The proposed estimation method can differentiate between small and large fluctuations in the throughput. Based on the behavior of the available throughput, the estimation method decides whether to offer an aggressive or stable response. References [3], [6], and [7] propose rate adaptation algorithms that select video rates based on the estimated throughput. The throughput-based rate adaptive algorithms have been found to be slow to converge on an optimal solution and result in a high frequency of video bitrate changes [25]. In [26], the authors propose a throughput-based rate adaptive algorithm to minimize the frequency of video rate changes and extreme downward switching that may occur due to sudden throughput degradation. In an unstable environment, an inaccurate throughput estimate results in the degradation of the user’s experience. Many methods have been proposed to incorporate information concerning the playback buffer in selecting the video rate. Miller et al. [8] propose a method that divides the buffer into multiple predefined thresholds (B1, B2, B3, Bmax) where (B1< B2< B3< Bmax), and selects different video rates based on the buffer level ranges. Rahman et al. [5] propose an algorithm that intelligently selects the video bit rates based on the estimated throughput and buffer occupancy, by dynamically selecting buffer ranges based on the sizes of the upcoming segments. In [22], the authors propose a segment and rate adaptive (SARA) algorithm that considers the size of the upcoming segments in addition to the throughput and buffer occupancy to predict the segment download time. Huang et al. [27] propose a video rate adaption algorithm that selects the video

8

rate by only observing the client’s playback buffer. The authors observe that due to highly variable network dynamics, especially in the case of wireless networks, it is difficult to estimate throughput. Hence, they limit the throughput estimation to the initial stage. To address the variation in segment sizes, the method directly maps the buffer occupancy to the segment size, and increases or decreases the video rate as the buffer builds up or drains, respectively. Furthermore, when deciding to change the video quality, the algorithm considers the sizes of the upcoming segments. Control-theoretic approaches, including use of proportional-integral (PI) controllers, have also been considered to improve streaming performance [28], [29]. Server-side mechanisms are also considered in some literature [30], [31]. The proposed algorithm selects the video rates based on throughput estimation and playback buffer occupancy. The algorithms proposed so far do not dynamically adjust the buffer thresholds to select the video rates as the playback buffer sizes, segment durations and available video rates vary. This approach affects the performance of the algorithms under different client and server settings. The proposed algorithm dynamically selects the buffer thresholds based on the segment duration, buffer size and available video rates to pick the video rates. This ensures that high quality segments are downloaded while avoiding playback interruption. Furthermore, the proposed algorithm does not quickly react to the changes in the throughput and buffer level to minimize the frequency of video rate changes while avoiding playback interruptions.

3. The Throughput Estimation Method The rate-adaptive algorithms strive to maximize the user’s experience by satisfying conflicting video quality objectives. Some of the potential objectives include selecting the highest feasible set of video bit rates, avoiding needless video bit rate changes, and avoiding an

9

interruption in playback. The rate-adaptive algorithms select the video segments on the basis of the estimated throughput. Therefore, it is important for the throughput estimation method to have a stable response to short-term and small variations in the throughput, to minimize unnecessary fluctuations in the video rate, and to react quickly to large fluctuations to minimize the risk of playback interruption due to buffer underflow. Segment throughput is defined as the ratio of the segment size to the segment download time. Selecting the video rate of the upcoming segments based on the segment throughput results in a high frequency of fluctuations, whereas the moving average method is late to respond to large variations in the throughput. e and Se represent the absolute and smoothed values of the throughput deviation; e and Se are determined as follows: e = T (i)  T (i) where T (i) 

(1) i 1

1

 n  T ( j)

j i  n

Se = (1-α)×e + α×Se

(2)

where T(i) represents the segment throughput and (i) represents the moving average throughput of the last 5 segments. The value of α is set to 0.9 to remove the outliers from the dataset. The smoothing factor (δ) is measured as follows:

 1 (

Se ) T (i)

(3)

To obtain the throughput TR(i), we use a form of running averages as follows: T (i  1) T R (i)   R (1   )  T (i  1)    T (i  1)

i 1 i 1

10

(4)

To differentiate between the fluctuations of different amplitude and frequency in the throughput, we calculate the log return. The log return shows the extent of the variability in the throughput in relation to the moving average throughput. We calculate the log return ρ using the following:

  log

T (i ) T (i )

(5)

A high value of the log return indicates that the difference between T(i) and

(i) is

significantly high, due to large fluctuations in the throughput. The client must be sensitive to large fluctuations in the throughput. A smaller value of the log return indicates a small fluctuation in the throughput or a short-term fluctuation. The client should offer a smooth and stable response to small fluctuations in the throughput. After the network condition is detected, the client estimates the throughput. If the throughput has large persistent variations, we use TR(i) as the estimated throughput to react quickly to the large variation in the throughput. In the case of small variations, we use the mean of the past throughput observations to provide a stable estimate.

T R (i) if    T E (i)   T (i) else

(6)

λ represents the threshold that indicates a large variation in the throughput. If the value of ρ ≥ λ, the estimated throughput is set equal to TR(i) as it quickly reacts to the large variations in the throughput; otherwise, the method uses the moving average of the past observations. We perform experiments to select the value of λ at which the proposed method is sensitive to variations in the throughput and reacts quickly. Therefore, we use a rectangular waveform, as shown in Fig. 2.

11

Fig. 2 A rectangular waveform throughput trace Amax and Amin denote the maximum and minimum values of the throughput, respectively, and Δ represents their difference. L represents the duration of the framework and D is the proportion of time when the throughput is Amax. We observe the response of the throughput estimation method by varying the value of λ, as shown in Figs. 3 and 4. 3100 3000

Throughput (kbps)

Throughput (kbps)

3000

2900 2800 2700 2600

2800 2600 2400 2200 2000

2500

1800

2400 1

1

7 13 19 25 31 37 43 49 55 61 67 73 79 85 91 97 103 109 115 121 127 Time (s)

Instant Throughput

λ = 0.05

λ = 0.075

λ= 0.10

7 13 19 25 31 37 43 49 55 61 67 73 79 85 91 97 103109115121127 Time (s)

Instant Throughput

λ = 0.125

λ = 0.05

λ = 0.075

λ= 0.10

λ = 0.125

(b) Δ = 1000 kbps

(a) Δ = 500 kbps 3100

3000

2700

Throughput (kbps)

Throughput (kbps)

2900 2500 2300 2100 1900

1700

2500

2000

1500

1500 1 7 13 19 25 31 37 43 49 55 61 67 73 79 85 91 97 103109115121127 Time (s) Instant Throughput

λ = 0.05

λ = 0.075

λ= 0.10

1000 1

6 11 16 21 26 31 36 41 46 51 56 61 66 71 76 81 86 91 96 101 106 111 116 121 126

Time (s)

λ = 0.125

Instant Throughput

λ = 0.05

λ = 0.075

λ= 0.10

(d) Δ = 2000 kbps

(c) Δ = 1500 kbps

Fig. 3 Performance of the proposed scheme as the amplitude of the fluctuations changes

12

λ = 0.125

In the first experiment, Δ is varied while maintaining Amax equal to 3000 kbps and varying Amin. The value of L and D are maintained at 30 sec and 0.5 respectively. The value of Δ is varied from 500 to 2000 kbps. In Fig. 3, we vary the value of Δ to analyze how the proposed scheme reacts to throughput fluctuations of different amplitude. Fig. 3 (a) shows that setting the value of λ equal to 0.125 results in slightly late response to the fluctuations in the throughput. For a small value of λ, the response to the throughput fluctuations becomes aggressive. As the value of Δ increases, the throughput estimation method should be able to react quickly to the fluctuations in the throughput to efficiently utilize the throughput or avoid a decrease in buffer occupancy due to throughput overestimation. Fig. 3 shows that for large values of Δ, the proposed method reacts quickly to the changes in the throughput for all values of λ.

3100

Throughput (kbps)

2900 2800 2700 2600 2500 2400 2300

3100 3000 2900 2800 2700 2600 2500 2400 2300 2200

2200

1

1 4 7 10 13 16 19 22 25 28 31 34 37 40 43 46 49 52 55 58 61 64 67 70 73 76 79 Time (s)

7 13 19 25 31 37 43 49 55 61 67 73 79 85 91 97 103 109 115 121127 Time (s)

Instant Throughput

λ = 0.05

(a)

λ = 0.075

λ= 0.10

Instant Throughput

λ = 0.125

λ = 0.05

λ = 0.075

λ= 0.10

(b) L = 16 sec

L = 30 sec 3100 3000

Throughput (kbps)

Throughput (kbps)

3000

2900 2800

2700 2600 2500 2400

2300 2200 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 Time (s) Instant Throughput

λ = 0.05

λ = 0.075

λ= 0.10

λ = 0.125

(c) L = 8 sec

Fig. 4 Performance of the proposed scheme as the frequency of the fluctuations changes

13

λ = 0.125

In the next experiment, L is varied while maintaining Amax equal to 3000 kbps. The value of Δ and D are maintained at 450 kbps and 0.5, respectively. In Fig. 4, we vary the value of L to analyze how the proposed scheme reacts to long- and short-term fluctuations. Fig. 4 shows that as the value of L decreases, a larger value of λ results in a stable response, while smaller values of λ result in an aggressive response. The rate adaptation algorithms select the video rates on the basis of the estimated throughput and the playback buffer occupancy. As explained previously, the major factors that affect the user’s experience include the average video rate, playback interruption and the frequency of video rate changes. The purpose of the proposed throughput estimation method is to assist the rate adaptive algorithm proposed in the next section in selecting the video rates. Based on the experimental results shown in Figs. 3 and 4, we select λ equal to 0.1 for the proposed scheme. We observe that when λ is equal to 0.1, the proposed method reacts quickly to large fluctuations in the throughput; in cases of small or short-term fluctuations in the throughput, the proposed method reacts conservatively to stabilize the estimated throughput. When the value of ρ is less than 0.1, the proposed technique uses the moving average of throughput observed over the previous segments. As the value of ρ increases above 0.1, the proposed scheme reacts quickly to the variations in the throughput. To evaluate the performance of the proposed method, we implement the throughput estimation method in the network simulator, ns-3. The server offers discrete bit rates from 400 to 3000 kbps, with a step size of 200 kbps. The duration of each segment is 2 sec, and the client starts playback after a segment has completely downloaded. The video bitrate is determined by selecting the highest video rate that is less than the estimated throughput.

14

To evaluate the performance of the proposed scheme, we compare our results with the method that estimates throughput by dividing the download size by the download time and passing it through a moving average filter [21].

3500

3000

3000

2500

2500

Throughput (kbps)

Throughput (kbps)

3500

2000 1500 1000

2000 1500

1000 500

500

0

0 1

4

1

7 10 13 16 19 22 25 28 31 34 37 40 43 46 49 52 55 58 61 64 67 70 73 76 79 82 85 88 91 94 Time (s) Instant Throughput Estimated Throughput Moving Average Video Rate Moving Average

6 11 16 21 26 31 36 41 46 51 56 61 66 71 76 81 86 91 96 101 106 111 116 121 126 131 Time (s) Instant Throughput Estimated Throughput Moving Average Video Rate Moving Average

Estimated Throughput Proposed Scheme

Video Rate Proposed Scheme

Estimated Throughput Proposed Scheme

Video Rate Proposed Scheme

(a) Small and large throughput fluctuations network scenario

(b) Gradual decrease and gradual increase network scenario

Fig. 5 Performance comparison of proposed and moving average throughput estimation methods

Fig. 5 compares the performance of the proposed scheme with the moving average throughput estimation method. Fig. 5 (a) shows that the proposed scheme is sensitive to large variations in the throughput. In the case of a large decrease in the throughput, the proposed scheme reacts quickly to minimize the risk of buffer underflow, and when the throughput increases, the proposed scheme increases the video rate to improve the utilization of the available throughput. The moving average scheme reacts late to variations in the throughput which not only results in underutilization of the available throughput when the throughput increases, but also risks playback interruption due to buffer underflow when the throughput suddenly decreases. In the case of a gradual decrease and increase in the throughput, the proposed scheme accurately estimates the throughput and gradually increases and decreases the video rate. The weighted average method reacts slowly to variations in the throughput which results in inefficient utilization when the throughput increases.

15

4. Proposed Algorithm The proposed rate adaptive algorithm selects the video rate based on the estimated throughput and the playback buffer level. Video rates and rebuffering events are important factors for improving the user’s experience. In addition, frequent video rate changes have been found to annoy the viewer. The primary goal of the proposed algorithm is to adaptively select a video rate from a set of video rates R = {R1, R2, R3,…, Rn}, to optimize the viewing experience.

4.1. System model The video stream is segmented into n segments, each containing τ sec of playback, and stored on the server. Each segment is available in multiple bit rates. The set of representations available for the video stream is denoted by R. The client dynamically selects a video rate from the set R. The client selects the kth video rate, Rk, from the set R for each segment to adapt the video according to the estimated throughput and playback buffer. Rmin and Rmax are the representations with the lowest and highest video rate in set R. We denote video rates higher and lower than the current video rate by R↑ and R↓, respectively. The presented work uses a serial segment fetching method to download segments, which requests the next segment after the current segment has completely downloaded. Once the current segment has completely downloaded, it adds τ sec of data to the buffer. After the first segment has downloaded, the client begins playing the video.

4.2. Adaptive bitrate algorithm Algorithm 1 provides the details of the proposed algorithm. The algorithm selects the kth video rate from, Rk, from the set R for the ith segment. The video rate for the ith segment is selected the end of the download of segment i-1. The video rate selected for the segment i-1 is denoted by

16

Rprev. The proposed algorithm running on the client outputs the video rate for the ith segment as Rnext. The algorithm selects the video rate by considering the throughput and buffer level together. To download the first segment, the client always selects the minimum available video rate, Rmin. There are two reasons for selecting Rmin as the video rate of the first segment. First, as the buffer begins to initially fill, it carries little information with which to select a video rate. Therefore, we consider a conservative approach at the start. Second, downloading the segment with the smallest video rate reduces the initial delay. Waiting time impairment such as an initial delay, is of considerable interest in HAS systems [17]. The video rate for the next segment is selected on a segment-by-segment basis. Let B(i-1) represent the buffer level at the end of the download of segment i-1. Then, B(i) is given as follows: B(i)  B(i  1)    [ 

Rk (i) ] T (i)

(7)

where Rk is the kth video rate from the set R and T(i) is the video throughput observed during the download of segment i. Equation (7) shows that a video rate greater than the throughput depletes the playback buffer. The change in the buffer level during the download of the ith segment is equal to the following:

B  B(i)  B(i  1)    [ 

Rk (i) ] T (i)

(8)

The throughput is estimated based on the past observations. In an environment with stable throughput, past observations are reliable to estimate the throughput of the upcoming segments. However, in a highly variable environment, the actual throughput during the download of the segment may differ from the estimated throughput. The higher the selected video rate, the higher the risk of playback interruption if the throughput suddenly decreases during the download of a

17

segment. The video clients do not have control over TCP sockets, and HTTP/1.1 does not support the termination of ongoing segment transfer, so the client can only change to a different video rate when the segment download finishes. If the throughput suddenly decreases in the middle of a segment transfer, the buffer may run dry before the client changes to a lower video rate. Therefore, the proposed rate adaptive algorithm considers buffer occupancy in addition to the estimated throughput when selecting the video rate. We denote Bk as the minimum buffer occupancy for a client to select the kth video rate, as follows:  R  Bk  Bmin   1  k   Rmin 

for k > Rmin

(9)

There should be at least one segment (  sec) available in the buffer for uninterrupted video playback. In real networks, the network capacity decreases below Rmin; therefore, the proposed rate-adaptive algorithm ensures that the client does not experience playback interruption during a brief network outage. Equation (9) ensures that if the client selects the kth video rate when at least Bk seconds of buffer is available and the throughput decreases to Rmin, there will be Bmin seconds of buffer available at the end of the segment download. The HTTP clients offer distinct buffer sizes. Streaming vendors deploy segment duration differently in their services. Microsoft Smooth Streaming, Adobe HTTP Dynamic Streaming and Apple HTTP Live Streaming offer segment durations of 2, 4 and 10 sec, respectively [33]-[35]. In the case of a large τ and small playback buffer sizes, Bk can be higher than the buffer size, Bmax, for high video rates. As the client selects the video rate based on Bk, the client may not be able to select high video rates, although the available throughput allows the client to select high video rates. Therefore, if the playback buffer threshold Bk for the highest available video rate is greater than 0.9×Bmax, we determine Bk according to the following:

18

  R   0.9  Bmax Bk   Bmin   1  k       Rmin   

(10)

where η denotes the playback buffer threshold for the highest video rate Rmax. This ensures that the client selects the highest video rate when the playback buffer occupancy is 90% of the Bmax.

Algorithm 1: Adaptation Algorithm Bk: Buffer threshold to select the kth video rate B(i): Buffer level at the download of the ith segment Rprev : Video rate selected for the previous segment Rnext : Video rate selected for the next segment D : Segment duration n : Number of available video rates k : Index of the current video rate i: Index of the next segment if B(i-1) < Bmin then // Select the lowest available video rate Rnext = Rmin else if Rk(i-1)≠Rmax && Rk+1Bk+1 then // Increase the video rate for j=k+1 to n if B(i) > Bj && TE(i) > Rj Rnext ← Rj end if j ← j+1 end for else if R(i-1)≠Rmin && B(i-1) Bmin Rnext ← Rj break end if j ← j-1 end for else // Stay at the current video rate Rnext = Rprev

The buffer model to calculate the video rate restriction λ is given by the following:

19

B(i  1)  Bmin

Rmin  Rk

 (si )  

Bmin  Bk  B(i  1)

(11)

We set the value of Bmin equal to 20% of the buffer size. If the buffer occupancy is less than Bmin, the proposed algorithm selects the lowest available video rate. High

B(i) < Bn-1

Bn-1

Rn-1 Rn-2

Bn-2

μ
Bn-3

Rn-3 μ> Bmin

R2

Buffer level (s)

Bitrate (kbps)

Rn

Video rate Throughput Buffer level B n

B2 Bmin

Rmin

Low 1

2

3

n-2

n-1

n

Segment Index

Fig. 6 Proposed algorithm video rate reduction mechanism First, we consider the scenario of an increase in the throughput and a subsequent increase in the buffer level. To increase the video rate in response to the increase in the throughput and the buffer level, the following two conditions should be satisfied; first, the selected video rate should be less than the estimated throughput. To avoid depletion of the buffer, the first condition ensures that the selected video rate is below the estimated throughput. The throughput is estimated using the estimation method described in Section 3. Second, for a client to increase the video rate, the buffer level should be higher than the playback buffer threshold calculated using Eq. (10). As the video rate cannot be adapted until the download of the next segment, a sudden decrease in throughput or an inaccurate throughput estimate reduces the probability of a buffer underflow event.

20

Next, we consider the scenario of a decrease in the throughput and a subsequent decrease in the buffer level. We remain at the current video rate until the buffer level decreases below Bk. This is to minimize the frequency of video rate changes by not reacting to short-term fluctuations. If there is a drastic decrease in the throughput, adapting the video rate based on the throughput will result in a drastic decrease in the video rate. The drastic drop in the video rate impairs the user’s engagement [16], [35]. On average, the minimum quality level is rated as 30% better quality in the cases of gradual video rate changes compared to instantaneous changes [35]. Once the buffer level decreases below Bk, irrespective of the estimated throughput, the proposed method selects the highest video rate such that the buffer level at the download of the next segment does not decrease below Bmin. This avoids the sudden decrease in the video rate. Fig. 6 depicts how the proposed algorithm avoids the unnecessary drastic decrease in the video rate to minimize the degradation of the user’s experience. At the beginning, the throughput is greater than Rn-1 and the buffer level is greater than Bn-1; the client selects the video rate Rn-1 for the upcoming segments. When the throughput drastically decreases, the client does not decrease the video rate suddenly; the client remains at Rn-1 as long as the video rate stays above Bn-1. When the buffer level decreases below Bn-1, the client selects the highest video rate that satisfies the condition μ = B(i)-TE(i)/Rk ×D > Bmin where D is the segment duration. As the buffer level further decreases and μD is satisfied.

5. Performance Evaluation We use a network simulator, ns-3, as the experimental simulation environment. The length of the video is 400 seconds. To achieve adaptive streaming, the HTTP server offers the client eight

21

levels of representation to adapt the video rates. These video rates are 184, 356, 500, 800, 1200, 1800, 2500 and 3000 kbps. HTTP Server

HTTP Client Bottleneck Link

Router

Router

Fig. 7 The network topology

5.1. Single-user scenario Fig. 7 shows the topology implemented for the single user scenario. The topology consists of an HTTP server, an HTTP client, and a pair of routers. The link between the routers is our bottleneck link. To vary the throughput across the bottleneck, we add UDP traffic between the routers. The traffic is generated according to an On-Off pattern. The UDP traffic is generated at a varying data rate to vary the throughput across the bottleneck. We analyze the algorithms under a predetermined network scenario to demonstrate the performance of the algorithms for different network conditions, buffer sizes and segment durations.

22

3500

3000

3000 Bitrate (kbps)

4000

3500

2500 2000 1500

2500 2000

1500

1000

1000

500

500 0

0 1

1

9 17 25 33 41 49 57 65 73 81 89 97 105 113 121 129 137 145 153 161 169 177 185 193 Segment Number Instant Throughput

AAA

BBA

Proposed Scheme

9 17 25 33 41 49 57 65 73 81 89 97 105113121129137145153161169177185193 Segment Number Instant Throughput

SARA

AAA

BBA

Proposed Scheme

SARA

(b)

(a) 4000

4000

3500

3500

3000

3000 Bitrate (kbps)

Bitrate (kbps)

2500 2000

1500

2500 2000 1500

1000

1000

500

500 0

0

1

1 10 19 28 37 46 55 64 73 82 91 100109118127136145154163172181190199 Segment Number Instant Throughput

AAA

BBA

Proposed Scheme

6 11 16 21 26 31 36 41 46 51 56 61 66 71 76 81 86 91 96 Segment Number

Instant Throughput

SARA

AAA

BBA

Proposed Scheme

SARA

(d)

(c) 4000 3500 3000

Bitrate (kbps)

Bitrate (kbps)

4000

2500 2000 1500 1000 500

0 1

3

5

7

9

Instant Throughput

11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 Segment Number

AAA

BBA

Proposed Scheme

SARA

(e)

Fig. 8 Adaptation results of different adaptation algorithms with (a) buffer size of 60 sec and segment duration of 2 sec, (b) buffer size of 40 sec and segment duration of 2 sec, (c) buffer size of 20 sec and segment duration of 2 sec, (d) buffer size of 60 sec and segment duration of 4 sec, and (e) buffer size of 60 sec and segment duration of 10 sec

23

5.1.1. Impact of buffer size In this section, we demonstrate the impact of the buffer size on the performance of the algorithms. The HTTP clients offer distinct buffer sizes. The rate-adaptive algorithms should be able to guarantee QoE under different client settings. For the following experiments, we set the buffer size to 20, 40 and 60 sec and evaluate the performance of the rate-adaptive algorithms. The segment duration is maintained at 2 sec for all of the experiments. In the first scenario, the buffer size is set to 60 sec. Fig. 8 (a) shows the video rates achieved by the algorithms over the streaming session. We can observe that SARA is the most unstable algorithm whereas AAA is the most stable algorithm; however, AAA is late to react to the increase in throughput, resulting in an underutilization of the throughput. Table 1 shows the number of fluctuations and the average video rate achieved by the algorithms. The proposed algorithm achieves the highest video rate and a lower number of video rate changes. The AAA algorithm experiences the lowest number of video rate changes, but to the detriment of video rate. The BBA algorithm achieves approximately 100 kbps less than the proposed scheme. Furthermore, the SARA algorithm experiences a buffer underflow of 3.1 sec that degrades the user’s experiences. In the second scenario, the buffer is set to 40 sec. Fig. 8 (b) shows the video rates achieved by the algorithms during the implementation of the second scenario. As in the first scenario, the SARA algorithm achieves a high video rate but is the most unstable. The proposed algorithm achieves rates 632, 183 and 119 kbps higher than AAA, BBA and SARA, respectively, and results in a lower number of video rate fluctuations. Moreover, the SARA algorithm experiences a playback interruption of 2.8 seconds. In the third scenario, we set the buffer size to 20 sec. The proposed algorithm achieves rates 524, 311 and 67 kbps higher than AAA, BBA and SARA, respectively. We observe there is a reduction in the average video rate achieved by the

24

BBA algorithm as the buffer size decreases. This is because the BBA algorithm requires large buffer sizes to select higher video rates. The proposed algorithm maintains a higher video rate and a lower number of video rate changes for all scenarios. The SARA algorithm experiences buffer underflow while downloading the 78th segment for 2.8 seconds, whereas the other algorithms stream the video without experiencing any playback interruption.

5.1.2. Impact of segment duration In this section, we demonstrate how the algorithms perform as the segment duration varies. Currently, streaming vendors deploy segment duration differently in their services. In the following experiments, we set the segment durations to 2, 4 and 10 sec and evaluate the performances of the rate adaptive algorithms. The buffer size is set to 60 sec for all the experiments. Section 5.1.1 explained the performance of the algorithms when the segment duration is set to 2 sec. Fig. 8 (d) shows the adaptation results of the rate adaptive algorithms when the segment duration is set to 4 sec. The AAA, BBA and SARA algorithms have rates nearly 600, 224 and 144 kbps worse than the proposed scheme, respectively. The clients experience comparable video rate changes during the implementation of AAA, BBA and the proposed algorithm, but the SARA algorithm results in nearly 4 times more video rate changes. Fig. 8 (e) shows the adaptation results of the rate adaptive algorithms for the fifth scenario, when the segment duration is set to 10 sec. The video rate of the BBA algorithm decreases considerably, and it achieves the lowest video rate. The rates of AAA, BBA and SARA algorithms are 594, 828 and 52 kbps worse than the proposed scheme, respectively. The SARA algorithm experiences the largest number of video rate changes. The number of video rate changes is less than the previous

25

scenarios because there are fewer segments as the segment duration is increased to 10 sec. The client does not experience playback interruption during the implementation of any algorithm. The experiments show that the proposed scheme achieves the highest average rate and a lower frequency of video rate changes while mitigating the playback interruptions to enhance the user’s experience. The results of the other algorithms show that the potential objectives to improve the user’s experience are conflicting. Maximizing the video rate may result in playback interruption because of buffer underflow, whereas minimizing the playback interruption may result in a higher number of video rate changes. The SARA algorithm achieves a higher video rate compared to the AAA and BBA algorithms, but it also experiences higher number of video rate changes and playback interruptions. However, the AAA algorithm mitigates the number of video rate changes but provides a lower video rate. The BBA algorithm results in video rate changes comparable to the proposed scheme but achieves a video rate less than the SARA and proposed algorithms. Furthermore, the proposed algorithm maintains a high video rate and a lower number of video rate changes irrespective of the buffer size and segment duration. The BBA algorithm maintains a high video rate in the cases of high buffer size or small segment duration, but when the buffer size is reduced or the segment duration is increased, it results in lower video rates. The AAA algorithm maintains a low average video rate, and the SARA algorithm maintains a high number of video rate changes during the implementation of all experiments.

5.2 Multi-user scenario In this section, we analyze the performance of the algorithms when multiple clients share the bottleneck. Fig. 9 shows the topology implemented for the multi-user scenario. The bandwidth of the bottleneck link is 10mbps for all experiments. The algorithms are evaluated for varying

26

number of clients, buffer sizes, and segment durations. Similar to the single client-scenario, we set the buffer size to 20, 40 and 60 sec and set the segment duration to 2, 4 and 10 sec. We analyze the algorithms for scenarios when two, three, four and five users share the bottleneck. In cases of two and three users sharing the bottleneck, the sum of the video rates of the competing users does not exceed the throughput at the bottleneck. In cases of four and five users, the sum of the video rates of the competing users can exceed the throughput at the bottleneck.

HTTP Client 1

HTTP Client 2

HTTP Server

Network 10mbps Network Element Bottleneck Element

HTTP Client 3

HTTP Client 4

HTTP Client 5

Fig. 9 Multi-client network topology

In an environment where multiple clients compete for the bottleneck, the clients are inefficient and select low-quality video rates and bandwidth is shared unfairly among the competing clients. The inefficiency at time t is given by the following [20]:

Inefficien cy 

 bx , t

W

x

(12)

W

27

where W is the bandwidth, and each client x selects bit rate bx,t. The average video rate is defined as the average of the video rates selected by the client for each segment. [18] defines the unfairness metric for two competing clients as the average of the absolute bit rate differences between the corresponding segments requested by each client. Let RA={RA1,RA2,…,RAn} denote the set that contains the video rates achieved by n competing clients. To evaluate the unfairness metric for more than two users, we define the parameter diff as follows: diff  Max( R A )  Min( R A )

(13)

Ideally, the values of inefficiency and diff should be zero. Low values of inefficiency and diff are desired; a low value of inefficiency means that the client selects the highest feasible bit rates lower than the actual throughput and a low value of diff means that the competing clients achieve equitable video rates.

5.2.1. Two-clients scenario First, we explain the results of the two-user scenario. The actual available throughput is 10 mbps; therefore, the clients can quickly increase the video rate and maintain the highest video rate. For all settings, once the clients reached the highest video rate of 300 kbps, they maintained this rate throughout the streaming session.

5.2.2. Three-clients scenario In case of three clients sharing the bottleneck, all clients should ideally be able to stream at the highest video rate. However, the clients sharing the bottleneck inaccurately estimate the bandwidth, resulting in low-quality video, inefficient utilization of the bandwidth and unfairness among the competing clients. Table 2 shows the statistics of the comparison of the adaptive

28

algorithms when three clients share the bottleneck. We evaluate the algorithms under varying buffer sizes and segment durations.

The experiments show the proposed scheme achieves the highest average video rate in all experiments except when the segment duration is increased to 10 sec. In this case, the proposed scheme is worse than the BBA algorithm by only 6kbps. Similarly, the proposed scheme has the lowest diff value, which shows that the competing clients achieve similar video rates. The proposed scheme has the most efficient algorithm for a 3-user scenario overall. The proposed algorithm has the lowest inefficiency value except when the segment duration is set to 4 and the buffer size is set to 40 sec; in these cases, the proposed scheme is second to the SARA algorithm by .008 and .006, respectively. Despite a slightly lower inefficiency value, the proposed scheme achieves higher video rates compared to the SARA algorithm. This means that a higher efficiency value does not necessarily result in a higher video rate because when competing for the bottleneck, the HTTP clients may inaccurately estimate the throughput [21].

5.2.3. Four-clients scenario Table 3 shows the statistics of the compared adaptive algorithms when four clients share the bottleneck. When the buffer size is set to 60 sec and segment duration is 2 sec, the proposed scheme and the BBA algorithm have the lowest inefficiency value. The proposed scheme achieves the highest average video rate. The AAA algorithm has the highest diff value and is the most inefficient scheme. The SARA algorithm has the lowest value of diff, followed by the

29

proposed scheme. In the next experiment, the buffer size remains at 60 sec and the segment duration is increased to 4 sec. The proposed scheme is the most efficient and results in the highest average video rate. The BBA algorithm has the lowest value of diff, followed by the proposed scheme. The AAA algorithm is the most inefficient algorithm and achieves the lowest average video rate. In the next experiment, the segment duration is increased to 10 sec. The proposed scheme is the most efficient, followed by the SARA algorithm. The proposed scheme achieves the highest video rate, followed by the BBA algorithm. Furthermore, the proposed scheme results in the lowest value of diff. The AAA algorithm results in the highest value of diff and achieves the lowest average video rate among all the algorithms. Next, we reduce the buffer size to 40 sec and segment duration is set to 2 sec. The BBA algorithm has the lowest inefficiency value, followed by the proposed scheme. The proposed algorithm achieves the highest average video rate whereas the AAA algorithm results in the lowest average video rate. The BBA and AAA algorithms achieve the smallest and largest diff values, respectively. Next, we reduce the buffer size to 20 sec, and the segment duration remains at 2 sec. The BBA algorithm has the lowest value, whereas the remaining algorithms result in an equal value of inefficiency. The BBA algorithm has the highest average video rate, while the proposed scheme is 7 kbps less than BBA. The proposed and AAA algorithms result in the lowest and the highest diff values, respectively.

5.2.4. Five-clients scenario Table 4 shows the statistics of the compared adaptive algorithms when five clients share the bottleneck. First, we set the value of the buffer size to 60 sec and the segment duration to 2 sec.

30

The proposed, BBA and SARA algorithms are equally efficient and the AAA algorithm has the lowest efficiency value. The proposed algorithm achieves the highest average video rate; the rates of BBA, SARA and AAA algorithms are 47, 81 and 151kbps worse than the proposed scheme, respectively. The BBA and AAA algorithms have the lowest and highest values of diff, respectively. Next, we increase the segment duration to 4 sec and set the buffer size to 60 sec. The proposed scheme and the BBA algorithm have similar inefficiency and average video rate values. Additionally, the BBA and AAA algorithms result in the lowest and highest values of diff, respectively. For the next experiment, we increase the segment duration to 10 sec. The proposed scheme achieves the highest average video rate and the lowest value of inefficiency. The AAA algorithm has an average video rate equal to the proposed scheme, and the SARA algorithm results in the lowest average video rate. Additionally, the AAA algorithm has the lowest value of diff. In the next experiment, we set the buffer size to 40 sec and reduce the segment duration to 2 sec. The proposed scheme has the lowest value of inefficiency, the highest value of average video rate and lowest value of diff achieved by the clients. The AAA algorithm results in the lowest average video rate, the highest value of inefficiency and the highest value of diff among the compared algorithms. In the final experiment, we reduce the buffer size to 20 sec. The proposed, BBA and SARA algorithms have the lowest value of inefficiency. The BBA algorithm has the highest value of the average video rate, followed by the proposed algorithm. The SARA algorithm results in the lowest value of diff, whereas the proposed scheme has the second lowest value among the compared algorithms.

31

The results show that the proposed scheme provides the best performance among the compared algorithms overall. In case of two users sharing the bottleneck, all the algorithms maintain the highest achievable video rate throughput the streaming session. In case of three users sharing the bottleneck, the proposed algorithm achieves the highest average video rate, best efficiency and lowest diff value. The BBA algorithm is the most inefficient algorithm, whereas the AAA algorithm results in the lowest average video rate. Moreover, the AAA and SARA algorithms have the highest diff value among the compared algorithms. These experiments also show the trade-offs among inefficiency, fairness and video rate for the SARA and BBA algorithms; the SARA algorithm has higher efficiency but achieves a low video rate and higher diff value. Similarly, the BBA algorithm has a high average video rate but results in low efficiency and has a higher diff value. The results show that when four users share the bottleneck, the proposed scheme shows the best performance among the compared algorithms overall. Similar to the 3-user scenario, the AAA algorithm has the worst performance among the competing algorithms, followed by the SARA algorithm. The performance of the BBA algorithm fluctuates from one environment to another. For example, the BBA algorithm has the lowest diff value when the buffer size is set to 60 and the segment duration is set to 4 sec, but it is the worst among the competing algorithms when the segment duration is reduced to 2 sec. Similarly, it has a lower inefficiency value when the buffer size is reduced to 40 and 20 sec; however, when the segment duration is increased to 10 sec, it is the most inefficient algorithm among all the clients. When five users share the bottleneck, the proposed algorithm achieves the highest average video rate and the best efficiency among the competing algorithms. When the segment duration is increased to 4 and 10 sec, it has a slightly higher diff value. Similar to the previous scenarios, the AAA algorithm has the worst overall performance, followed by the SARA algorithm. The

32

performance of the BBA algorithm fluctuates from one environment to another. The BBA algorithm shows improved performance for large buffer sizes and small segment durations, but when the segment duration is increased, the performance of the BBA algorithm degrades. Similarly, when the buffer size is decreased to 20 sec, it achieves a higher average video rate, but it has a higher diff value.

6. Conclusion In this paper, we propose a throughput estimation method and a rate-adaptive algorithm for HTTP adaptive streaming. The proposed throughput estimation method estimates the throughput of the upcoming segment based on previous samples. We show that the proposed method accurately estimates the throughput by reacting quickly to large throughput variations and offers a stable response to short-term and small variations to assist the rate-adaptive algorithm in improving the user’s experience. The objective of the adaptive bitrate streaming algorithm is to improve the viewing experience. Single- and multi-client adaptive-streaming experiments were conducted under varying network conditions. We evaluated the performance of the proposed algorithm in terms of the achieved video rate, the number of video rate changes, buffer underflow occurrences, efficiency and fairness among the competing algorithms. The proposed algorithm provides high-quality video by achieving a high video rate and minimizes the number of video rate changes while preventing interruption in playback. Furthermore, we show that it efficiently utilizes the network resources; the competing HTTP clients achieve comparable video rates. We also show that variations in buffer size and segment duration do not affect the performance of the proposed algorithm.

33

Acknowledgement This work was supported by Institute for Information & communications Technology Promotion(IITP)

grant

funded

by

the

Korea

government(MSIT)

(No.2015-0-00195,

Development of LifeMedia hub terminal and services based on life style analysis)

References [1] “Cisco Visual Networking Index: Global Mobile Data Traffic Forecast, 20142019,” White Paper (2014). [2] I. Sodagar: The mpeg-dash standard for multimedia streaming over the internet. IEEE MultiMedia. 18(4), 62-67 (2011). https://doi.org/10.1109/MMUL.2011.71 [3] T. C. Thang, Q. D. Ho, J. W. Kang, and A. T. Pham: Adaptive streaming of audiovisual content using MPEG DASH. IEEE Tran. Consum. Electron. 58(1), 78-85 (2012). doi: 10.1109/tce.2012.6170058 [4] R. Dubin, O. Hadar, and A. Dvir: The effect of client buffer and MBR consideration on DASH adaptation logic. In: Proceedings of IEEE Wireless Commun. and Netw. Conf., pp. 2178-2183. Shanghai, China (2013). doi: 10.1109/wcnc.2013.6554900 [5] W. Rahman and K. Chung: Buffer-based adaptive bitrate algorithm for streaming over HTTP. KSII Tran. Internet and Inform. Syst. 9(11), 4585-4622 (2015). doi: 10.3837/tiis.2015.11.019 [6] S. Akhshabi, A. C. Begen, and C. Dovrolis: An experimental evaluation of rate-adaptation algorithms in adaptive streaming over HTTP. In: Proceedings of ACM Conf. on Multimedia Syst., pp. 157-168. California, USA (2011). doi: 10.1145/1943552.1943574 [7] C. Liu, I. Bouazizi, and M. Gabbouj: Rate adaptation for adaptive HTTP streaming. In: Proceedings of ACM Conf. on Multimedia Syst., pp. 169-174. California, USA (2011). doi: 10.1145/1943552.1943575 [8] K. Miller, E. Quacchio, G. Gennari, and A. Wolisz: Adaptation algorithm for adaptive streaming over HTTP. In: Proceedings of IEEE Packet Video Workshop, pp. 173-178. Munich, Germany (2012). doi: 10.1109/pv.2012.6229732 [9] P. Juluri, V. Tamarapalli, and D. Medhi: SARA: Segment aware rate adaptation algorithm for dynamic adaptive streaming over HTTP. In: Proceedings of IEEE Int. Conf. on Commun. Workshop, pp. 1765-1770. London, United Kingdom (2015). doi: 10.1109/iccw.2015.7247436 [10] H. T. Le, D. V. Nguyen, N. P. Ngoc, A. T. Pham, and T. C. Thang: Buffer-based bitrate adaptation for adaptive HTTP streaming. In: Proceedings of IEEE Conf. on Advanced Technol. Commun., pp. 33-38. Hochiminh, Vietnam (2013). doi: 10.1109/atc.2013.6698072 [11] W. Rahman and K. Chung: Chunk size aware buffer-based algorithm to improve viewing experience in dynamic HTTP streaming. IEICE Tran. Commun. E99-B(3), 767-775 (2016). doi: 10.1587/transcom.2015ebp3398 [12] W. Rahman, D. Yun, and K. Chung: A Client Side Buffer Management Algorithm to Improve QoE. IEEE Trans. Consum. Electron. 62(4), 371-379 (2016). https://doi.org/10.1109/TCE.2016.7838089 [13] F. Dobrian, A. Awan, D. Joseph, A. Ganjam, J. Zhan, V. Sekar, I. Stoica, and H. Zhang: Understanding the impact of video quality on user engagement. ACM SIGCOM Comput. Commun. Review. 56(3), 91-99 (2013). doi: 10.1145/2018436.2018478 [14] P. Ni, R. Eg, A. Eichhorn, C. Griwodz, and P. Halvorsen: Flicker effects in adaptive video streaming to handheld devices. In: Proceedings of ACM Int. Conf. on Multimedia, pp. 463-472. Arizona, USA (2011). doi: 10.1145/2072298.2072359 [15] Y. Liu, S. Dey, D. Gillies, F. Ulupinar, and M. Luby: User experience modeling for DASH video. In: Proceedings of IEEE Packet Video Workshop, pp. 1-8. San Jose, USA, (2013). doi: 10.1109/pv.2013.6691459 [16] Y. Shen., L. Yitong, H. Yang, and D. Yang: Quality of Experience study on dynamic adaptive streaming based on HTTP. IEICE Tran. Commun. 98(1), 62-70 (2015). doi: 10.1587/transcom.e98.b.62 [17] S. Egger, B. Gardlo, M. Seufert, and R. Schatz: The impact of adaptation strategies on perceived quality of http adaptive streaming. In: Proceedings of ACM Workshop on Design, Quality and Deployment Adaptive Video Streaming, pp. 31-36. Sydney, Australia (2014). doi: 10.1145/2676652.2676658

34

[18] S. Akhshabi, L. Anantakrishnan, A.C. Begen, and C. Dovrolis: What happens when HTTP adaptive streaming players compete for bandwidth?. In: Proceedings of ACM Workshop Netw. and Operating Syst. Support for Digital Audio and Video, pp. 9-14. Toronto, Canada (2012). https://doi.org/10.1145/2229087.2229092 [19] Z. Li, X. Zhu, J. Gahm, R. Pan, H. Hu, A.C. Begen, and D. Oran: Probe and adapt: Rate adaptation for HTTP video streaming at scale. IEEE J. Sel. Areas Commun. 32(4), 719-733 (2014). https://doi.org/10.1109/JSAC.2014.140405 [20] J. Jiang, V. Sekar, and H. Zhang: Improving fairness, efficiency, and stability in http-based adaptive video streaming with festive. In: Proceedings of ACM Int. Conf. on Emerg. Netw. Experiments and Technol., pp. 97108. Nice, France (2012). https://doi.org/10.1145/2413176.2413189 [21] T. Y. Huang, H. Nikhil, H. Brandon, M. Nick, and J. Ramesh: Confused, timid, and unstable: picking a video streaming rate is hard. In: Proceedings of ACM Int. conf. on Internet Meas., pp. 225-238. Boston, USA (2012). doi: 10.1145/2398776.2398800 [22] P. Juluri, V. Tamarapalli, and D. Medhi: SARA: Segment aware rate adaptation algorithm for dynamic adaptive streaming over HTTP. In: Proceedings of IEEE Int. Conf. on Commun. Workshop, pp. 1765-1770. London, United Kingdom (2015). doi: 10.1109/iccw.2015.7247436 [23] VideoLAN. (2013). Vlc sourece code. [Online]. Available: http://www.videolan.org/ vlc/downloadsources.html. [24] R. Mok, X. Luo, E. Chan, and R. Chang: QDASH: A QoE-aware DASH system. In: Proceedings of ACM Int. Conf. on Multimedia Syst., pp. 11–22. North Carolina, USA (2012). https://doi.org/10.1145/2155555.2155558 [25] T. C. Thang, H.T. Le, A. T. Pham, Y. M. Ro: An evaluation of bitrate adaptation methods for HTTP live streaming. IEEE IEEE J. Sel. Areas Commun. 32(4), 693-705 (2014). https://doi.org/10.1109/JSAC.2014.140403 [26] M. Azumi, T. Kurosaka, M. Bandai: A QoE-aware quality-level switching algorithm for adaptive video streaming. In: Proceedings of IEEE Global Commun, pp. 1-5. San Deigo, CA, USA (2015). https://doi.org/10.1109/glocom.2015.7417622 [27] T. Y. Huang, R. Johari, N. McKeown, M. Trunnell, and M. Watson: A buffer-based approach to rate adaptation: Evidence from a large video streaming service. ACM SIGCOM Comput. Commun. Review. 44(4), 187-198 (2015). doi: 10.1145/2619239.2626296 [28] L. D. Cicco, S. Mascolo, and V. Palmisano: Feedback control for adaptive live video streaming. In: Proceedings of. ACM Conf. on Multimedia Syst., pp. 145–156. San Jose, CA, USA (2011). https://doi.org/10.1145/1943552.1943573 [29] X. Zhu, Z. Li, R. Pan, J. Gahm, and H. Hu: Fixing multi-client oscillations in HTTP-based adaptive streaming: A control theoretic approach. In: Proceedings of IEEE Workshop on Multimedia Signal Process., pp. 230-235. Pula, Italy (2013). https://doi.org/10.1109/mmsp.2013.6659293 [30] S. Akhshabi, L. Anantakrishnan, C. Dovrolis, and A. C. Begen: Server-based traffic shaping for stabilizing oscillating adaptive streaming players. In: Proceedings of ACM Workshop on Netw. and Operating Syst. Support for Digital Audio and Video, pp. 19-24, Feb. Portland, USA (2013). https://doi.org/10.1145/2460782.2460786 [31] R. Houdaille and Stephane Gouache: Shaping HTTP adaptive streams for a better user experience. In: Proceedings of ACM Multimedia Syst. Conf., pp. 1-9. Chapel Hill, USA (2012). [32] A. Zambelli. Microsoft Corporation. IIS smooth streaming technical overview. [Online]. Available: http://www.microsoft.com/enus/download/details.aspx?id=17678 [33] Adobe. Configure HTTP Dynamic Streaming and HTTP Live Streaming. [Online]. Available: https://helpx.adobe.com/adobe.../configure-dynamic-streaming-live-streaming.html [34] R. Pantos. HTTP Live Streaming. [Online]. Available: https://tools.ietf.org/html/draft-pantos-http-livestreaming-13 (2014). [35] N. Staelens, J. De Meulenaere, M. Claeys, G. Van Wallendael, W. Van den Broeck, J. De Cock, R. Van de Walle, P. Demeester, and F. De Turck: Subjective quality assessment of longer duration video sequences delivered over HTTP adaptive streaming to tablet devices. IEEE Trans. Broadcast. 60(4), 707-714 (2014). doi: 10.1109/tbc.2014.2359255

35

Table 1. Statistics of different adaptive methods for the single-user scenario Scenario 1

Scenario 2

Scenario 3

Scenario 4

Scenario 5

Scheme

Average video rate

# of video rate fluctuations

Average video rate

# of video rate fluctuations

Average video rate

# of video rate fluctuations

Average video rate

# of video rate fluctuations

Average video rate

# of video rate fluctuations

AAA BBA Proposed Scheme

1701.32 2124.72

12 15

1688.72 2137.22

13 15

1745.32 1959.02

13 15

1697.84 2076.24

11 13

1663.7 1430.6

8 7

2275.14

16

2321.18

14

2269.54

19

2300.32

12

2258.6

10

SARA

2176.7

91

2201.98

92

2201.98

91

2155.76

49

2205.9

18

Table 2. Statistics of different adaptive methods when three clients share the bottleneck Scheme

AAA

BBA

Proposed Scheme

SARA

Buffer size = 60 sec and segment duration = 2 sec

Average Video Rate (kbps) Mean (kbps)

User 1

User 2

User 3

User 1

User 2

User 3

User 1

User 2

User 3

User 1

User 2

User 3

2832.92

2349.6

2825.92

2817.62

2851.72

2904.52

2924.94

2744.04

2924.94

2874.72

2718.92

2757.72

2669.48

2857.953333

2864.64

2783.786667

Inefficiency

0.216

0.1378

0.11

0.119

Diff (kbps)

483.32

86.9

180.9

155.8

Buffer size = 60 sec and segment duration = 4 sec

Average Video Rate (kbps) Mean (kbps)

User 1

User 2

User 3

User 1

User 2

User 3

User 1

User 2

User 3

User 1

User 2

User 3

2774.72

2683.52

2959.12

2785.6

2903.98

2921.58

2924.94

2874.94

2924.94

2690.12

2823.42

2926.22

2805.786667

2870.386667

2908.273333

2813.253333

Inefficiency

0.129

0.128

0.113

0.105

Diff (kbps)

275.6

135.98

50

236.1

Buffer size = 60 sec and segment duration = 10 sec

Average Video Rate (kbps) Mean (kbps)

User 1

User 2

User 3

User 1

User 2

User 3

User 1

User 2

User 3

User 1

User 2

User 3

2770.7

2836.7

2737.7

2774.1

2806.6

2819.1

2793.7

2793.7

2793.7

2067.1

2091.1

2389.1

2781.7

2799.933333

2793.7

2182.433333

Inefficiency

0.124

0.319

0.148

0.12

Diff (kbps)

99

45

0

322

Buffer size = 40 sec and segment duration = 2 sec

Average Video Rate (kbps) Mean (kbps)

User 1

User 2

User 3

User 1

User 2

User 3

User 1

User 2

User 3

User 1

User 2

User 3

2904.24

2650.08

2656.68

2866.12

2867.12

2761.12

2849.88

2849.88

2849.88

2605.64

2780.44

2767.44

2737

2831.453333

2849.88

2717.84

Inefficiency

0.151

0.153

0.114

0.108

Diff (kbps)

254.16

106

0

174.8

36

Buffer size = 20 sec and segment duration = 2 sec

Average Video Rate (kbps) Mean (kbps)

User 1

User 2

User 3

User 1

User 2

User 3

User 1

User 2

User 3

User 1

User 2

User 3

2911.92

2835.18

2965.72

2926.44

2926.44

2900.06

2924.94

2927.44

2946.94

2854.62

2852.92

2932.32

2904.273333

2917.646667

2933.106667

2879.953333

Inefficiency

0.104

0.1378

0.1

0.1

Diff (kbps)

130.54

26.38

22

79.4

Table 3. Statistics of different adaptive methods when five clients share the bottleneck Scheme

AAA

BBA

Proposed Scheme

SARA

Buffer size = 60 sec and segment duration = 2 sec User

Video Rate

User

User

User

User

User

User

User

User

User

User

User

User

1

2

3

4

1

2

3

4

1

2

3

4

1

1980

2208

2038

1984

2106

2204

2256

2368

2247

2210

2305

2423

2257

User

User

User

2

3

4

2305

2218

2130

(kbps) Mean (kbps)

2052

2234

2296

2228

Inefficiency

0.25

0.08

0.08

0.12

Diff (kbps)

228

262

213

175

Buffer size = 60 sec and segment duration = 4 sec

Video Rate

User

User

User

User

User

User

User

User

User

User

User

User

User

1

2

3

4

1

2

3

4

1

2

3

4

1

2255

2271

2160

1888

2246

2246

2178

2258

2293

2225

2312

2255

2130

User

User

User

2

3

4

1986

2279

2222

(kbps) Mean (kbps)

2143

2232

2271

2154

Inefficiency

0.20

0.11

0.08

0.10

Diff (kbps)

383

79

86

293

Buffer size = 60 sec and segment duration = 10 sec User

Video Rate

User

User

User

User

User

User

User

User

User

User

User

User

1

2

3

4

1

2

3

4

1

2

3

4

1

2253

1970

2514

1957

2122

2278

2309

2182

2178

2199

2342

2205

1665

User

User

User

2

3

4

1509

1539

1572

(kbps) Mean (kbps)

2173

2223

2231

1571

Inefficiency

0.17

0.36

0.09

0.11

Diff (kbps)

558

188

165

156

Buffer size = 40 sec and segment duration = 2 sec

Video Rate

User

User

User

User

User

User

User

User

User

User

User

User

User

1

2

3

4

1

2

3

4

1

2

3

4

1

2370

2193

2485

1656

2307

2289

2287

2152

2247

2210

2305

2423

2257

(kbps)

37

User

User

User

2

3

4

2305

2218

2130

Mean (kbps)

2176

2259

2296

2228

Inefficiency

0.12

0.08

0.09

0.12

Diff (kbps)

829

154

213

175

Buffer size = 20 sec and segment duration = 2 sec

Video Rate

User

User

User

User

User

User

User

User

User

User

User

User

User

1

2

3

4

1

2

3

4

1

2

3

4

1

2043

2052

2487

2338

2266

2243

2258

2412

2313

2292

2264

2284

2029

User

User

User

2

3

4

2275

2439

2156

(kbps) Mean (kbps)

2230

2295

2288

2225

Inefficiency

0.11

0.08

0.11

0.11

Diff (kbps)

444

169

49

410

Table 4. Statistics of different adaptive methods when five clients share the bottleneck Scheme

AAA

BBA

Proposed Scheme

SARA

Buffer size = 60 sec and segment duration = 2 sec

Video Rate (kbps)

User 1 1849

User 2 1562

User 3 1593

User 4 1740

User 5 1688

User 1 1783

User 2 1742

User 3 1827

User 4 1849

User 5 1752

User 1 1766

User 2 1910

User 3 1791

User 4 1895

User 5 1824

User 1 1714

User 2 1657

User 3 1736

Mean (kbps)

1686

1790

1837

1756

Inefficiency

0.25

0.10

0.10

0.10

Diff (kbps)

288

107

144

185

User 4 1842

User 5 1832

User 4 1600

User 5 1708

User 4 1109

User 5 1506

User 4 1842

User 5 1832

Buffer size = 60 sec and segment duration = 4 sec

Video Rate (kbps)

User 1 1805

User 2 1626

User 3 1859

User 4 1508

User 5 1829

User 1 1820

User 2 1798

User 3 1890

User 4 1760

User 5 1664

User 1 1783

User 2 1609

User 3 1864

User 4 1911

User 5 1865

User 1 1688

User 2 1814

User 3 1828

Mean (kbps)

1726

1786

1783

1728

Inefficiency

0.20

0.10

0.09

0.12

Diff (kbps)

350

129

303

227

Buffer size = 60 sec and segment duration = 10 sec

Video Rate (kbps)

User 1 1757

User 2 1739

User 3 1946

User 4 1733

User 5 1779

User 1 1901

User 2 1844

User 3 1752

User 4 1766

User 5 1661

User 1 1768

User 2 1842

User 3 1744

User 4 1668

User 5 1941

User 1 1572

User 2 1566

User 3 1110

Mean (kbps)

1791

1785

1792

1372

Inefficiency

0.20

0.30

0.09

0.13

Diff (kbps)

213

241

273

463

Buffer size = 40 sec and segment duration = 2 sec

Video Rate (kbps)

User 1 1687

User 2 1761

User 3 1655

User 4 1924

User 5 1625

User 1 1867

User 2 1661

User 3 1899

User 4 1794

User 5 1819

User 1 1766

User 2 1910

User 3 1791

User 4 1895

User 5 1824

User 1 1714

User 2 1657

User 3 1736

Mean (kbps)

1730

1808

1837

1756

Inefficiency

0.18

0.10

0.09

0.10

Diff (kbps)

299

238

144

185

38

Buffer size = 20 sec and segment duration = 2 sec

Video Rate (kbps)

User 1 1713

User 2 1702

User 3 1786

User 4 1796

User 5 1981

User 1 1719

User 2 1908

User 3 1768

User 4 1842

User 5 1953

User 1 1744

User 2 1874

User 3 1778

User 4 1875

User 5 1805

User 1 1722

User 2 1825

User 3 1777

Mean (kbps)

1795

1838

1815

1782

Inefficiency

0.14

0.10

0.10

0.10

Diff (kbps)

279

234

131

103

39

User 4 1805

User 5 1782

Highlights       

Throughput estimation method based on the throughput observed over past segments Rate adaptive algorithm based on the buffer occupancy and estimated throughput Analyzes the algorithm for single- and multi-client environments Selects high-quality video segments, while minimizing video quality changes Minimizes the risk of playback interruption Efficiently utilizes network resources to stream high-quality video Competing HTTP clients achieve equitable video rates

40