Computers and Electrical Engineering 58 (2017) 49–66

Contents lists available at ScienceDirect

Computers and Electrical Engineering

journal homepage: www.elsevier.com/locate/compeleceng

Improvement of adaptive HTTP streaming using advanced

real-time rate adaptationR
Selvaraj Kesavan∗, J. Jayakumar
Department of Electrical & Electronics Engineering, Karunya University, Coimbatore 641 114, Tamil Nadu, India

a r t i c l e i n f o a b s t r a c t

Article history: We propose a real-time rate-adaptation approach for adaptive Hypertext Transfer Protocol
Received 5 May 2016 streaming. In this advanced real-time rate-adaptation (ARTRA) approach, we monitor the
Revised 16 December 2016
parameters at the client in real time, and select the most likely available bit representation
Accepted 21 December 2016
for the next segment download. The algorithm dynamically triggers the rate evaluation
Available online 14 January 2017
and decides the rate switch according to metrics calculated using the segment download
Keywords: duration, measured throughput, and buffer data-level indication. The performance of the
Adaptive HTTP streaming ARTRA is compared with those of throughput-based adaptation and segment-fetch time-
ARTRA based adaptation algorithms. An analysis of the experimental results shows that ARTRA
DASH enables clients to use the maximum available end-to-end network capacity and delivers
Performance evaluation the best user experience by reducing re-buffering events and bitrate level changes. AR-
Rate adaptation TRA performs remarkably well under challenging network conditions and supports system
User experience stability and robustness.
© 2017 Elsevier Ltd. All rights reserved.

1. Introduction

Multimedia applications, such as playback, streaming, and video telephony, have become an integral part of our lives.
With the advent of the internet, streaming has begun to replace the use of storage devices as the method by which large
files, such as audio/video content, are delivered to consumers. In a heterogeneous network architecture, achieving the opti-
mal quality of service (QoS) and quality of experience (QoE) in streaming poses a significant challenge. Streaming method-
ologies implement intelligent rate-adaptation models to calculate network metrics and adjust the system to pick the stream,
which then creates a tradeoff between the network bandwidth and media quality. The client media player initially buffers
a portion of data before starting actual playback to balance the throughput variation. However, throughput delivery is less
likely when short-time bandwidth variation occurs due to the sharing of network bandwidth among many clients. This
eventually leads to buffer drain, which degrades media quality and the streaming experience of the user.
Development of dynamic adaptive streaming over Hypertext Transfer Protocol (HTTP) (DASH) specifications helps over-
come the shortcomings of conventional progressive-download [1] and real-time transport protocol (RTP) [2] streaming ap-
proaches. The basic objective of adaptive HTTP streaming is to divide the audio and video into a number of small chunks
of ideal duration, encode them at different bitrates, and store them, and deliver them to the client via HTTP downloading.
MPEG and 3GPP work together to standardize the adaptive streaming of continuous media over HTTP [3]. DASH became an
international standard in 2011; it was revised in 2014 from a previous version published in ISO/IEC 23,009-1:2012 in 2012

R
Reviews processed and recommended for publication to the Editor-in-Chief by Associate Editor Dr. J. Tian.
∗
Corresponding author.
E-mail addresses: selvarajkesavan@gmail.com (S. Kesavan), jayakumar@karunya.edu (J. Jayakumar).

http://dx.doi.org/10.1016/j.compeleceng.2016.12.019
0045-7906/© 2017 Elsevier Ltd. All rights reserved.
50 S. Kesavan, J. Jayakumar / Computers and Electrical Engineering 58 (2017) 49–66

[4]. An application-level adaption is required to compensate for throughput variations owing to the TCP congestion control
effect and bandwidth variations. Without a suitable rate-adaptation algorithm, an adaptive-streaming client might frequently
undergo oscillations and interruptions in playback, leading to a poor user experience. Proper bitrate selection and effective
rate adaptation are required to ensure smooth media data flow and efficient use of the available network bandwidth and
end-device capabilities.
To the best of our knowledge, adaptive HTTP streaming rate adaptation suffers from multiple problems, such as clients
failing to choose optimal bitrates, interrupted playback, and slow convergence. Thus, we study and analyze the behavior of
popular conventional throughput-based adaptation (TBA) and segment-fetch time-based adaptation (SFTBA) algorithms and
propose a novel rate-adaptation approach for overcoming current rate-adaptation limitations.
Here, we present a novel, client-centric advanced real-time rate-adaptation (ARTRA) approach for monitoring and trig-
gering rate evaluation according to the ideal or actual segment download time and buffer warning/critical level. The optimal
bitrate representation is chosen using the buffer occupancy and received throughput. When necessary, the ARTRA system
initiates rate adaptation in real time, rather than waiting for the previous segment to finish downloading. The contributions
of this paper can be quantified in three aspects: First, we propose the novel ARTRA approach for DASH. Second, we capture
and analyze the conventional TBA and SFTBA approaches. Third, the performance of the ARTRA, TBA, and SFTBA in a real-
time experiment are evaluated and analyzed using key performance streaming indices. TBA is presented as Algorithm 2 and
is based on a previously proposed algorithm [5]. SFTBA is presented as Algorithm 3 and is based on an algorithm proposed
by Corvoysier and Zakari [6]. Detailed analysis of each algorithm provides key insights into the suitability and limitations of
the algorithm under different network conditions.
The rest of the paper is organized as follows. Section 2 presents related work that describes different rate-adaptation ap-
proaches in adaptive-streaming models. The proposed ARTRA approach for adaptive HTTP streaming is presented in Section
3. The system implementation and description of the conservative segment-fetch time and TBA algorithms are given in
Section 4. The real-time, internet-based, on-demand, live adaptive-streaming experiment setup is explained in Section 5.
The experimentation results, a performance analysis of ARTRA, and comparisons are provided in Section 6. Section 7 con-
cludes the paper.

2. Related work

Rate adaptation in DASH is an emerging and active research field. The DASH standard [4] does not provide any rate
adaptation logic or approach recommendations. Clients are allowed to implement optimized proprietary algorithms suited
to the device and network conditions. Hence, many commercial and open-source DASH clients implement their own rate-
adaptation algorithms with minimal or no change in the server. In addition to DASH, numerous commercial adaptive-
streaming methods developed by different commercial vendors, such as Microsoft Smooth Streaming (MSS), Apple HTTP
Live Streaming (HLS), and Abode HTTP Dynamic Streaming (HDS), use different file formats and transportation standards.
Alaoui and Dröge [5] developed an algorithm to determine the bitrate switch-up or switch-down of the next segment
from the time required to download the current segment. However, this algorithm does not consider the segment size, which
may lead to an overestimation of the available network bandwidth. Corvoysier and Zakari [6] introduced a TBA approach as
part of the GStreamer multimedia framework [15] DASH de-multiplexer implementation. The algorithm determines the next
optimal bitrate according to the measured average bitrate for the current downloaded segment.
Chenghao Liu et al. [7] proposed algorithms that help select appropriate switch-down/switch-up bitrates in serial and
parallel segment-download methods. They estimated the current available bandwidth by comparing the actual and expected
segment-fetch durations. The experimental methodology and metrics are suitable for measuring and comparing the perfor-
mance of any adaptive HTTP streaming rate-adaptation algorithm. However, their algorithm performs the adaptation cal-
culation according to the segment duration. Encoding and compression schemes cause the segment size to vary widely
for the same bitrate and duration. Additionally, variations in the download times for the segments can affect the available
bandwidth-calculation accuracy.
Buffer-based rate-adaptation algorithms have been reported [8,9]. In [8], the algorithm uses the current buffer occupancy
in the steady state directly to select the appropriate video rate and does not use other metrics to adapt the rate. Although
described as a buffer-based algorithm, the algorithm completely relies on the network to adapt the rate and decide the
bitrate during the startup phase, owing to the lack of buffer occupancy. Zhou et al. [9] presented a proportional deriva-
tive control approach for controlling the buffer size and adapting the proper bitrate. Client buffer occupancy-based rate
adaptation may not efficiently utilize the available bandwidth, as the buffer consumption also depends on the end-device
capabilities. Client processing constraints may increase or decrease the media buffering time, and lead to the selection of a
substandard or oversubscribed bitrate.
Rate-adaptation decisions based on the media segment size were presented in [10] and [11]. The segment-aware rate-
adaptation algorithm proposed by Juluri et al. [10] adapts to the proper rate by predicting when to start downloading the
next segment using segment-size variation, along with the bandwidth availability and the current buffer occupancy. These
researchers proposed an algorithm based on the buffer level, with the bitrate-representation selection occurring in a single
step or multiple steps to match safe playback and avoid re-buffering events. The algorithm proposed in [11] determines
the appropriate segment duration to enable precise rate adaptation. Fetching smaller media segments can improve the rate
 S. Kesavan, J. Jayakumar / Computers and Electrical Engineering 58 (2017) 49–66 51

Fig. 1. Illustration of the proposed ARTRA for rate measurement.

adaptation, especially when there are short spikes in the network bandwidth variation. However, smaller segment sizes lead
to frequent requests to the server and higher occurrences of bitrate-switching.
Liu et al. [12] developed an additive-increase and aggressive-decrease rate-adaptation algorithm for adaptive HTTP
streaming. The algorithm uses the available network throughput as the deciding factor to increase or reduce the bitrate
for the next segment. However, aggressive bitrate decisions based on the received throughput may lead to data loss and
playback interruptions at the client. Instantaneous bandwidth variation may lead to improper throughput estimation, which
affects the bitrate selection. Adaptive HTTP streaming with small segment durations is more prone to abrupt bandwidth
variations compared to streaming with long segments. Azumi et al. [13] proposed a QoE-aware quality-level switching al-
gorithm that switches adaptively according to the intermediate quality level, the limitation of the quality level, and the
network throughput. However, this algorithm requires additional steps in order to converge when the available bandwidth
changes, and it does not fully utilize the available network capacity. Processes of bitrate selection and adaptation based
on the predicted probability of the playout buffer were also presented [14]. Prediction-based rate selection is not an effi-
cient solution under highly varying network conditions and does not effectively use the available end-to-end bandwidth.
Our proposed approach is unique in that it aims to design a novel, client-centric, real-time rate-adaptation algorithm that is
dynamic and robust. The algorithm adapts and selects the appropriate bit representation in real time.

3. Comprehensive client-centric ARTRA

In this section, the proposed ARTRA algorithm for adaptive HTTP streaming to improve the user experience and QoS via
the real-time measurement, scheduling, and selection of the bit representation using the throughput, segment-fetch time,
and buffer level is described. A graphical illustration of ARTRA is presented in Fig. 1. Detailed measurements of key metrics
and evaluation of the proposed algorithm are provided.

3.1. Media presentation description

DASH streaming standard supports on-demand, live, and time-shifting applications with various content profiles. It can be
deployed using standard web servers and works with current internet infrastructures. An XML-based manifest file describes
the media presentation details and playlists required to stream the content to the client.

3.2. Key parameter indices

3.2.1. Buffer occupancy

The playback buffer holds arriving packets for a short interval before playing them. The playback of prefilled data ensures
continued playback despite short fluctuations in the throughput and regulates the received data flow. However, the high net-
work jitter or random network variation causes buffer underflow, and re-buffering creates a playback pause until the buffer
is filled back to a certain level. The playout buffer threshold and data-level parameters play important roles in designing
effective rate adaptation, and reduce the buffer drain and overflow conditions. The average playback data consumption in a
52 S. Kesavan, J. Jayakumar / Computers and Electrical Engineering 58 (2017) 49–66

Fig. 2. Measurement of key parameters.

system can be estimated using the equation

 T
1/ ( T − α ) t=α P (t ) dt t>α
P (t ) = (1)
0 t≤α
The data availability in the buffer B(t) at time t calculated is using the expression
 t2  t2
B(t2 ) = B(t1 ) + A(t ) − P (t ) (2)
t =t 1 t =t 1

To implement effective rate-adaptation logic, the buffer is logically divided into five regions, as illustrated in Fig. 2a. The
buffer data event is trigged for the specified level, and action is taken in the rate-adaptation procedure.
• BEMPTY - buffer empty.
• BCRIT - critical buffer region below 10% of the buffer level
• BLTH - buffer lower threshold at 20% of the buffer level
• BHALF - buffer half-full
• BUTH - buffer upper threshold at 80% of the buffer level
• BFULL - buffer full

3.2.2. Segment-duration measurement

Adaptive-streaming media content is divided into multiple segments with bitrates and defined durations. When a client
requests a particular bit representation, the server dynamically seeks the proper segment of the bit representation and
sends it to the client. The duration of each segment of the bit representation is specified in the description file if requested.
Without the duration from the description file, the entire segment duration is calculated using the simple equation
SDi = (Ssi ∗ 8 )/SRi (3)
Here, Ssi is the total size of the ith segment, calculated using the segment start and end byte-range fields, which are
available in the description file.
Ri – bitrate of ith segment
Ssi = Mei − Msi (4)
The idle download-completion time for the ith segment is calculated as follows:
STfi = Ts + S Di (5)
 S. Kesavan, J. Jayakumar / Computers and Electrical Engineering 58 (2017) 49–66 53

The actual time required to download the segment differs from the expected segment download time, as it depends
on the network conditions. We estimate slow, fast, and ideal segment fetching according to the actual segment download
completion time and scheduled idle segment download time. The segment arrival scenario is categorized into three phases
according to the actual segment download completion time and scheduled segment download time. The different segment
download scenarios are illustrated in Fig. 2b.
Fast Download: The actual segment download duration is shorter than the estimated segment download duration.
Ideal Download: The actual segment download duration exactly matches the estimated segment download duration.
Slow Download: The actual segment download duration is longer than the estimated segment download duration.
The download time is a critical to triggering the rate adaptation and choosing the appropriate bitrate in the proposed
ARTRA algorithm. The slow, fast, and ideal download times are calculated using the equation
AT f i = (Ts − ST f i ) (6)
ATfi is the actual time required to download the ith segment, calculated using the current system time when the segment
is completely downloaded at the client. The segment is downloaded slower than expected if
AT f i > S T f i (7)
In the case of fast segment fetching,
AT f i < S T f i (8)
For ideal segment fetching,
AT f i = S T f i (9)
The segment download time is a vital indicator of the available network capacity over the segment duration.

3.2.3. Average-throughput measurement

The average throughput indicates the current network variation and available capacity. Each media segment in adaptive
HTTP streaming has a predefined playback duration; however, adaptive-streaming segment sizes vary, even for the same
bitrates. Throughput measurement for a constant segment duration with varying segment sizes does not yield an accurate
available bandwidth. As shown in Fig. 2c, the proposed ARTRA algorithm uses two approaches based on segment data arrival
to measure the average throughput precisely.
Ideal Measurement: The throughput measured exactly at the segment duration when the segment download time ex-
ceeds or matches the segment duration. It is expressed as:
Dfi
ABi = (10)
SDi
Early Measurement: The throughput measured at the completion of the segment download when the segment download
time is shorter than the segment duration, which is expressed as
Dfi
ABi = (11)
ATfi
ABi (t) is the average throughput of the ith segment.
Dfi is the ith downloaded data segment at the client and can be estimated as
 t=ET i
Dfi = B(t ) (12)
t=ST i

ETi - segment end time.

Di ≥ T i (13)
STi - segment start time.

3.3. ARTRA algorithm description

ARTRA uses two steps to measure and switch to the new bitrate using the real-time throughput, client buffer level, and
segment download time. In the first step, the algorithm triggers the most appropriate time to start the rate measurement.
In the second step, the algorithm chooses the most likely new bitrate from the set of available representations to switch to.

3.3.1. Triggering rate-adaptation measurement and choosing most feasible bitrate representation
The time taken to trigger the rate-adaptation measurement and start fetching the next segment is critical in maintaining
the playback buffer at a safe level and ensuring uninterrupted playback. Segment duration and buffer level are critical to
triggering the rate-adaptation measurements in ARTRA . The time taken to download the segment indicates the available
network capacity, and the buffer level indicates the client processing ability and short-time network variation. By combining
54 S. Kesavan, J. Jayakumar / Computers and Electrical Engineering 58 (2017) 49–66

Algorithm 1 proposed ARTRA.

1: Initialize bit representation at i=0 and send HTTP request to fetch first segment
2: LCURR = R0 ∈ R
3: While ((Ts − STfi == 0) or (ATfi == true) or (BCURR < BLTH ) or (BCURR < BCRIC ) or (BCURR > BUTH ) && (Segments Available))
i is the current segment index
4: if (Ts − STfi == 0)
5: if (BCURR > BUTH )
6: wait for BCURR -BUTH = 0 or (ATfi == true) event
7: set SWDOWN_UTH Flag=true;
8: else
9: if (LCURR ! = R0 ) //parallel download & switch-down

10: LNEXT = Rcurr ∈ R ≤ (Max( 0i−1 ((Ri−1 /ABi )∗ SDi-1 ) ≤ SDi-1 )))
11: else
12: LNEXT = R0 ∈ R
13: else if (ATfi == true)
14: set SWDOWN_UTH Flag=false;
15: if ((BCURR > BUTH ) && ( ATfi < STfi ))
16: wait till BCURR -BUTH =0 event
17: set SWUP_UTH Flag=true;
18: else if ((BCURR > BUTH ) && ( ATfi = STfi ))
19: wait till BCURR -BUTH =0 event
20: set SWEQ_UTH Flag=true;
21: else if ( ATfi < STfi )
22: if (LCURR ! = RN-1 ) //aggressive switch-up

LNEXT = Rcurr ∈ R ≤ (Max ( N−1 i+1 ((Ri+1 /ABi ) SDi+1 )+(BUTH -BCURR )≤ SDi+1 )))
∗
23:
24: else
25: LNEXT = RN − 1 ∈ R
26: else if (ATfi = =STfi )
27: LNEXT = LCURR
28: else
29: if (LCURR != R0 ) //aggressive switch-down

30: LNEXT = Rcurr ∈ R ≤ (Max( 0i−1 ((Ri−1 /ABi )∗ SDi-1 )+(BUTH -BCURR )≤ SDi-1 )))
31: else
32: LNEXT = R0 ∈ R
33: else if (BCURR < BCRIC or BCURR < BLTH )))
34: if (LCURR ! = R0 ) //initiate parallel download and aggressive switch-down

35: LNEXT = Rcurr ∈ R ≤ (Max ( 0i−1 ((Ri−1 /ABi )∗ SDi-1 )+(BHALF -BCURR )≤ SDi-1 )
36: else
37: LNEXT = R0 ∈ R
38: else if (BCURR –BUTH == 0)
39: if (SWDOWN_UTH Flag==true)
40: if (LCURR != R0 ) //parallel download & switch-down

41: LNEXT = Rcurr ∈ R ≤ (Max ( 0i−1 ((Ri−1 /ABi )∗ SDi-1 )≤ SDi-1 )))
42: else
43: LNEXT = R0 ∈ R
44: else if (SWUP_UTH Flag == true)
45: if (LCURR != R0 ) //parallel download & switch-up

46: LNEXT = Rcurr ∈ R ≤ (Max ( 1i−1 ((Ri−1 /ABi )∗ SDi-1 ) ≤ SDi-1 )))
47: else
48: LNEXT = R0 ∈ R
49: else if (SWEQ_UTH Flag==true)
50: LNEXT = LCURR
51: LCURR = LNEXT
52: Set SWDOWN_UTH Flag=false;
53: Set SWUP_UTH Flag=false;
54: Set SWEQ_UTH Flag=false;
55: End while

the ideal and actual segment-fetch time and current buffer level, the algorithm calculates the best realistic time to start the
next segment.
ARTRA selects the optimal bitrate representation for the next segment using the current buffer level and received average
bitrate at the client. The average throughput is used as one of the deciding factors along with the buffer level to choose the
best bitrate representation.
The pseudocode of the proposed algorithm is given in Algorithm 1. The algorithm downloads the description file and
initializes the request to fetch the first segment. Then, it waits for Ts − STfi == 0, ATfi == true, BCURR < BLTH , BCURR < BCRIC ,
or BCURR > BUTH to trigger the measurement and select the next bitrate. The rate-adaptation scheduling and rate selection
comprise the following stages.

• Early Start
 S. Kesavan, J. Jayakumar / Computers and Electrical Engineering 58 (2017) 49–66 55

Algorithm 2 TBA.

INPUT:
STfi – Scheduled segment-fetch time i =0, 1,…, N-1.
SSTfi –Segment start time i = 0, 1,…, N-1
Ts – Current system time
SDi – Target duration
β – Bitrate tolerance factor
R = Available bit representation {R0 , R1 , R2 ,…, RN-1 )
LCURR = Current bit representation = Ri ∈ R
ω = Bandwidth usage
B(t) =Buffer size
BMIN = Minimum buffering time
BTIME = Buffering time
BRATIO = Buffer ratio
LSST = Last segment stop time
FSST = First segment start time
ABi = Average segment bitrate i = 0, 1,…, N-1.
Duration = Duration to calculate the average throughput
dnl_rate = download rate
ALGORITHM:
Initialization:
ω = 0.8
BMIN = 5 s
i is the current segment index
Initialize bit representation at i = 0 and send HTTP request to fetch the first segment
LCURR = R0 ∈ R
1: While (completion of each segment fetch and more segments available to fetch)
2: Calculate duration = Ts - SSTfi
3: Calculate dnl_rate = (B(t) ∗ 8) / duration
4: BTIME = LSST – FSST
5: if (BTIME > BMIN )
6: BRATIO = 1;
7: else
8: BRATIO = BTIME / BMIN
9: Calculate ABi = BRATIO ∗ dnl_rate∗ ω
10: if (ABi <= 0)
11: LNEXT = LCURR
12: exit;
13: for (I = 0; I < N; i++) /∗ switch-up /switch-down bit representation selection ∗ /
14: Get corresponding representation for index i (Ri ∈ R)
15: if (Ri <= ABi )
16: LNEXT = Ri
17: end for
18: LCURR = LNEXT
19: end while
OUTPUT:
LNEXT ∈ R = next selected bit representation to fetch

The algorithm triggers the rate measurement before the previous segment download is completed. This occurs when the
actual segment arrives, before the ideal scheduled segment download completion time—i.e., ATfi < STfi —or when the buffer
level is below the lower threshold (BCURR < BLTH ) or below the critical level (BCURR < BCRIC ).
The algorithm chooses an aggressive switch-up when ATfi < STfi and BCURR < BUTH. The selection of the appropriate
switch-up bitrate is closer to the target segment duration and the time offset between BUTH and BCURR. When the buffer
level decreases to below the lower threshold (BCURR < BLTH ) or below the critical level (BCURR < BCRIC ), the algorithm chooses
an aggressive switch-down and initiates a parallel next-segment download to avoid data scarcity at the client. The algorithm
chooses a bitrate that is closer to the target segment duration and the time offset between BHALF and BCURR .

• Prompt Start

The rate measurement is triggered immediately after the previous-segment download is completed. This occurs when
the actual segment download time matches the ideal scheduled segment download time—i.e., ATfi = STfi — which indicates
that the available bandwidth is closer to the requested bitrate. The algorithm keeps the next-segment bitrate the same as
the previous-segment bitrate (LNEXT = LCURR ) when BCURR < BUTH. Otherwise, the segment-download scheduling is delayed
until BCURR reaches BUTH. The algorithm also switches down the bitrate and starts fetching the next segment in parallel,
although the previous-segment download is ongoing when Ts − STfi reaches zero for BCURR < BUTH . Otherwise, the segment
scheduling is postponed until BCURR reaches BUTH.

• Delayed Start
56 S. Kesavan, J. Jayakumar / Computers and Electrical Engineering 58 (2017) 49–66

Algorithm 3 SFTBA.

INPUT:
STfi – Scheduled segment-fetch time I = 0, 1,…, N-1
Ts – Current system time
SDi – Target duration
β – Bitrate tolerance factor
R = Available bit representation {R0 , R1 , R2 ,…, RN-1 )
LCURR = Current bit representation = Ri ∈ R
ALGORITHM:
Initialization:
β = 0.4;
Initialize and fetch the first segment
LCURR = R0 ∈ R
1: While (completion of each segment fetch and more segments available to fetch)
2: Calculate limit = SDi ∗ β
3: Calculate diff = STfi – Ts
4: delay = 0
5: if (diff > limit) /∗ switch to a higher bitrate ∗ /
6: while (diff > limit)
7: if (LCURR != Last Segment)
8: LNEXT = LCURR+1
9: else
10: LNEXT = LCURR
11: diff = diff - limit
12: LCURR = LNEXT ∈ R
13: end while
14: else if (diff < 0) /∗ switch to a lower bitrate ∗ /
15: delay = delay - diff;
16: if (delay >= limit) {
17: while (delay >= limit)
18: if (LCURR != Last Segment)
19: LNEXT = LCURR-1
20: else
21: LNEXT = LCURR
22: LCURR = LNEXT ∈ R
23: delay = delay - limit
24: end while
25: delay = 0;
26: else /∗ continue with same bitrate ∗ /
27: LNEXT = LCURR ∈ R
28: else /∗ continue with same bitrate ∗ /
29: LNEXT = LCURR ∈ R
30: end while
OUTPUT:
LNEXT ∈ R = next selected bit representation to fetch

The rate measurement is triggered with a delay to balance the network speed and the client buffer level. This occurs
when the requested segment download is completed before the ideal download time and the buffer level is beyond the
upper threshold (BUTH ) or when Ts − STfi reaches zero and BCURR > BUTH . When the buffer level is closer to being full, the
algorithm starts fetching the next segment with a delay to avoid overflow. An early segment download indicates that more
bandwidth is available and that the user can switch-up the representation. Ts − STfi indicates a delayed download due to
a lower available bandwidth. The algorithm decides on the bitrate switch-down or switch-up with or without a parallel
download request according to the delay set in the case of an early download or if Ts − STfi reaches zero.

• Parallel Download

ARTRA proposes requesting segments in parallel to achieve real-time rate adaptation and maintain intact playback. A par-
allel download scenario is illustrated in Fig. 3. The main HTTP downloader fetches the segment from the server. Whenever
the segment download exceeds STfi , the algorithm evaluates the condition and can decide to download the next segment in
parallel using a helper HTTP downloader. The algorithm initiates parallel downloads only when the conditions for parallel
downloads are met.
In parallel HTTP, the download helps maintain an intact framerate and reduces the frame drops at the client. However,
exceeding the optimal number of parallel connections leads to a congested network and results in performance degradation.
To avoid increased complexity and unnecessary performance bottlenecks in the system, we use a maximum of two parallel
downloaders in our design. The main HTTP downloader fetches the segments sequentially whenever the rate-adaptation
algorithm triggers the fetching of the next segment before the completion of the previous segment using a helper HTTP
downloader. In the example shown in Fig. 3, downloading segments 1 and 4 requires more than the scheduled time. The
 S. Kesavan, J. Jayakumar / Computers and Electrical Engineering 58 (2017) 49–66 57

Fig. 3. Parallel segment download approach.

algorithm can trigger segments 2 and 5 to download concurrently with segments 1 and 4 using the helper HTTP downloader
instance.

4. System implementation

This section covers the system implementation of the proposed ARTRA algorithm, as well as the experiment procedure.
We use the GStreamer multimedia framework [15] to implement the ARTRA and evaluate its behavior. The proposed ARTRA
algorithm is implemented in the GStreamer DASH streaming plugin. The playout total and minimum buffer sizes are config-
ured. we developed streaming client application that enables the playback and receives the events from the DASH streaming
plugin and buffer. This allows the application and rate-adaptation algorithm to act on events and take appropriate action.
The streaming application runs with specified DASH uniform resource locators and renders the stream. The application also
collects stream statistics using logs and tools.

4.1. Comparative experiment

To compare the performance of the ARTRA with existing rate-adaptation techniques, we evaluate two conventional TBA
and SFTBA algorithms, as follows.

4.1.1. TBA
TBA (Algorithm 2) determines the next optimal bitrate according to the measured average bitrate for the current segment
downloaded. The algorithm begins with first bitrate representation R0 ∈ R and starts fetching the segment. For consecutive
segments, the algorithm calculates the average bitrate using the existent client buffering ratio, download rate, and band-
width usage-limit factor, compares it with the available bit representation (R0 , R1 , R2 ,…, RN-1 ∈ R), and chooses the optimal
bitrate: LNEXT = Ri. The bandwidth usage limit (ω) is set to 0.8, and the minimum buffering (BMIN ) is set to 5 s. A detailed
description of the algorithm is given in Algorithm 2.

4.1.2. SFTBA
The SFTBA algorithm (Algorithm 3) is implemented and evaluated in the GStreamer DASH client for comparison. SFTBA
decides the bitrate switch-up or switch-down of the next segment according to the time required for downloading the
current segment. The algorithm decides the bitrate switch-up when the actual segment download requires less time than the
ideal segment-download limit. The ideal segment-download limit is calculated by multiplying the ideal segment download
time by the bitrate tolerance factor (β ). In our evaluation method, β is set to 0.4. The optimal bitrate is selected from the
available bit representations {R0 , R1 , R2 ,…, RN-1 ) to match the network variation using the segment-fetch time observed at
the player. The pseudocode of SFTBA is given in Algorithm 3.

5. Experimental setup

ARTRA, SFTBA, and TBA are evaluated in a real-time environment with a controlled cloud-based streaming client-server
setup. The cloud experimental setup is illustrated in Fig. 4. The different network experimentation settings used in the ex-
periment are given in Table 2. The list of hardware and software tools used in the evaluation methodology and their required
specifications are listed in Table 3. Settings 1 and 2 are used for low-bandwidth and higher-bandwidth scenarios. Setting 3 is
used to analyze a variable-bandwidth scenario. In a real-time experiment, it is tedious to connect many clients and observe
the behavior of each one; hence, we use no more than three adaptive-streaming clients to evaluate the performance of the
ARTRA algorithm.

5.1. Cloud streaming server experiment setup

We tested the algorithm performance for real-time live and on-demand streaming using an Amazon media services
setup, as shown in Fig. 4.. The setup consists of two server regions located in Singapore and Northern Virginia. The setup
58 S. Kesavan, J. Jayakumar / Computers and Electrical Engineering 58 (2017) 49–66

Table 1
Definition of symbols.

Notation Definition

P (t ) Average playback consumption at time t > 0

P(t) Playback data rate at time t > 0
Ts Current system time
T Media playback duration
α Pre-buffered duration
B(t) Data availability in the buffer at time t > 0
A(t) Data arrival rate at time t > 0
BCURR Current buffer level
BLTH Buffer lower threshold
BHALF Buffer at half full
BUTH Buffer upper threshold
BCRIC Buffer critical level
SDi Segment duration i = 0, 1, 2,…, N-1.
Ssi Total segment size i = 0, 1, 2,…, N-1.
Mei Segment end i = 0, 1, 2,…, N-1.
Msi Segment start i = 0, 1, 2,…, N-1.
Dfi Segment downloaded data i = 0, 1, 2,…, N-1.
STfi Scheduled ideal segment-fetch time i = 0, 1, 2,…, N.
ATfi Actual segment download time i = 0, 1, 2,…, N-1.
R Available bit representation {R0 , R1 , R2 ,…, RN-1 )
ABi Average throughput measurement i = 0, 1, 2,…, N.
LCURR Current bitrate
LNEXT Bitrate of selected next segment

Table 2
Experimental network settings.

Setting 1 Setting 2 Setting 3

Bandwidth (Mbps) 2 6 2 to 6
Delay 3 ms 3 ms 3 ms
Client connections 1 to 3 1 to 3 1 to 3

Table 3
Experimentation tools and specifications.

Module Hardware/Software/Tools Specification

Encode/broadcast Android Nexus 7 tablet OS: Android 5.1 (Lollipop)

CPU: Snapdragon S4 Pro APQ8064, Quad core, 1500 MHz
Memory: 2 GB
GPU: Adreno 320
Wowza Gocoder Encoding Bitrate: up to 50 0 0 Kbps
Resolution: up to 1,080p
Encoding format: H264 ABR/ AAC-LC up to 48 kHz
Protocol: RTP/RTSP/ TCP/UDP
Cloud streaming server setup (live and Amazon Server Region: Asia Pacific (Singapore), U.S. East (Northern
on-demand) Virginia)
Elastic Cloud Computing Instance (EC2) Instance: c4.4xlarge (Ubuntu)
Media Server Wowza streaming engine version: 4.1.1
Amazon Cloud Front Edge Content Delivery Network Service
On-Demand Storage Amazon Simple Storage Service (S3)
Download bandwidth limiter Ipfw User interface for traffic control utility
Dummynet Traffic control/shaping utility
Streaming client Laptop OS: Ubuntu 12.04 LTS, 64-bit,
CPU: Intel Core i7-2640 M CPU @ 2.80 GHz
Memory: 8 GB
Graphics: Intel HD Graphics
GStreamer Streaming Client Media Components: GStreamer-0.10.36 and plugins
HTTP Adaptive Streaming ARTRA Pipeline.
Network configuration (managed Network AP Cisco Linksys E2500 - IEEE 802.11a/b/g/n
service provider)
Data Rate 16 Mbps
Adaptive-streaming players for MPEG-DASH GStreamer DASH Streaming player with TB-DASH
comparison rate-adaptation algorithm
Tools used Highcharts Graph building and visualization
FFmpeg Multi-bitrate content encoding and PSNR calculation
Wireshark Network data collection
 S. Kesavan, J. Jayakumar / Computers and Electrical Engineering 58 (2017) 49–66 59

Fig. 4. Cloud-based adaptive HTTP streaming client-server experimental setup.

Table 4
Media representations and dataset.

Bitrate Level On-Demand Streaming: Bitrate/Resolution Live Streaming: Resolution/Bitrate

0 176 × 144/50 Kbps 176 × 144/50 Kbps

1 352 × 240/150 Kbps 352 × 240/150 Kbps
2 480 × 320/250 Kbps 480 × 320/250 Kbps
3 640 × 480/500 Kbps 480 × 320/300 Kbps
4 852 × 480/700 Kbps 640 × 480/400 Kbps
5 1280 × 720/1200 Kbps 640 × 480/500 Kbps
6 1280 × 720/20 0 0 Kbps 704 × 396/600 Kbps
7 1920 × 1080/30 0 0 Kbps 854 × 480/700 Kbps
8 1920 × 1080/50 0 0 Kbps 960 × 540/900 Kbps
9 1920 × 1080/60 0 0 Kbps 1280 × 720/1200 Kbps
10 1920 × 1080/80 0 0 Kbps 1280 × 720/1500 Kbps
11 1280 × 720/20 0 0 Kbps
12 1920 × 1080/2500 Kbps
13 1920 × 1080/30 0 0 Kbps
14 1920 × 1080/40 0 0 Kbps
15 1920 × 1080/50 0 0 Kbps
16 1920 × 1080/60 0 0 Kbps
17 1920 × 1080/80 0 0 Kbps

also consists of Wowza GoCoder, an IEEE 802.11 a/b/g/n wireless access point (AP), and a maximum of three adaptive-
streaming clients, each with a network data limiter installed. The proposed rate-adaptation algorithm ARTRA is implemented
in a GStreamer-based streaming player and can connect to the DASH server, located at Amazon media services, to receive
streams. Two more GStreamer-based adaptive clients are configured to dynamically connect with the streaming server to
study the algorithm performance under congestion scenarios. The Wireshark and ipfw/dummynet tools are configured in
clients to monitor and control the network traffic. In our evaluation methodology, live media is directly fed into the stream-
ing engine, and the encoded media segments with different bitrates are delivered to the edge server and then to the gateway
AP and the adaptive-streaming client. The Amazon edge-service delivery model helps deliver media content at the edge re-
gardless of the content origin. On-demand and live streaming experiments are conducted in both server regions, and the
performance values are measured. The average measurement values of two regions are considered to be the final analysis
result. The adaptive-streaming server is configured to generate 18 different bit representations, as listed in Table 4. We did
not enable a media cache in the server; thus, all content is fetched directly from the server. This helps us study the exact
behavior of the streaming client and adaptation algorithm. For on-demand streaming, a 1,080p, 30 fps MP4 video of a 1260 s
duration is stored in Amazon Simple Storage Service (s3) buckets, and the Wowza Streaming Engine transcodes the content
with 11 different bit representations, as specified in Table 4.
60 S. Kesavan, J. Jayakumar / Computers and Electrical Engineering 58 (2017) 49–66

6. Data collection and analysis

6.1. Performance metrics

To evaluate the quality and efficiency of the proposed ARTRA streaming algorithm and perform a comparison, we use
the following performance metrics.
Stability and robustness: These are measured in terms of the rate-change occurrences to bandwidth variations and the
ability to remain at the maximum bit-representation level for the available bandwidth. The algorithm is said to be more
stable and robust when there are less rate-change occurrences, and the maximum bitrate is selected more often.
Buffer underflow/overflow occurrences: This is the number of times that buffer stall or loss of video/audio data occurs
when the download data rate is less than the actual playback rate or the playout buffer receives additional data.
Achievable throughput: This is a measure of the ability of the algorithm to converge and receive the maximum through-
put under the available network bandwidth when multiple clients compete for bandwidth.
Received video quality: This is the quality of the received video measured in terms of the average peak signal-to-noise
ratio (PSNR) of the received segment. The PSNR provides an objective measurement of the received video quality by com-
paring it with the original transmitted video.
Segment request and arrival interval: These are measures of the time taken for segment request initiation and segment
arrival to the client, respectively. They provide insight on how closely the segment arrival time matches the real time.

6.2. Data analysis

This section provides a detailed analysis of different performance metrics of ARTRA, SFTBA, and TBA. A detailed compar-
ison of the algorithms are made, and their merits and demerits with respect to the metrics are listed.

6.2.1. Stability and robustness

The bitrate-change occurrences and algorithm representation-level evolutions are considered to demonstrate the stability
and robustness of the algorithm. The efficient algorithm should be able to converge rapidly and switch to the maximum
possible level representation. First, the rate-adaptation stability can be observed from the bitrate-change occurrences under
different network bandwidth. The bitrate-change occurrence is an important factor in the determination of the algorithm
efficiency. Fig. 5 shows the on-demand streaming average media bitrate level-change occurrences of ARTRA, TBA, and SFTBA
under low, high, and variable bandwidth conditions in single- and multiple-client bandwidth-sharing scenarios. Fig. 5a and
b indicate that ARTRA has 20 to 40% less level-change occurrences than TBA and SFTBA. With a single client connection, the
behavior of ARTRA is similar to those of SFTBA and TBA. When two and three clients simultaneously fetch the stream from
the server, ARTRA has considerably less level-change occurrences.
Second, the algorithm stability can be observed from the representation-level histogram under a variable bandwidth. Fig.
5d shows the on-demand streaming representation-level stability with three simultaneous connections. The results show
that ARTRA, TBA, and SFTBA start with a bitrate of 50 Kbps. Subsequently, ARTRA selects 500 Kbps as the download bitrate
for the next segment, while, TBA and SFTBA select 150 and 250 Kbps, respectively. ARTRA chooses 20 0 0- Kbps segments 11
times and 1200-Kbps segments 78 times. TBA and SFTBA fall behind ARTRA in terms of selecting higher-bitrate segments
under similar network conditions.
Real-time monitoring, available bandwidth estimation, and scheduling in ARTRA allow the precise prediction of available
end-to-end bandwidth. This helps ARTRA select a bitrate that is closer to the network capacity with fewer fluctuations.
Owing to the optimal bitrate selection, the algorithm tends to choose and remain at higher bitrates many times. The be-
havior of the algorithm for live streaming is shown in Fig. 6. The live-streaming level changes of the algorithm are more
frequent compared to the changes in on-demand streaming. As shown in Fig. 6d, the higher-bitrate stability of the algo-
rithm is slightly lower than that of on-demand streaming. However, ARTRA exhibits considerably better performance than
other competitive algorithms. In addition to the initial startup delay, the live-streaming segment request and download are
delayed owing to live transcoding from the server, which leads to a deviation in receiving the throughput estimation and
the selection of the appropriate next bitrate.

6.2.2. Buffer overflow/underflow

The experimental results for the overall average number of buffer overrun/underrun occurrences of each algorithm for
live and on-demand streaming are presented in Table 5. In higher-bandwidth scenarios, the ARTRA streaming experience
is good, without any buffer overrun/underrun occurrences. These occurrences are more frequent when there are short
fluctuations in the available bandwidth. The experimental results indicate that ARTRA has considerably less overall under-
flow/overflow frequencies than TBA and SFTBA owing to the on-the-fly real-time adaptation.
On average, ARTRA improves buffer overflow/underflow occurrences by 70–90% compared to TBA and SFTBA. ARTRA
predicts the available bandwidth very well by evaluating appropriate metrics in real time and employs the parallel download
approach for fast downloads to maintain a safe buffer level. This helps minimize buffer starvation, but not entirely, as buffer
starvation and overflow still occur due to the very high inflow or outflow in the throughput caused by the highly random
S. Kesavan, J. Jayakumar / Computers and Electrical Engineering 58 (2017) 49–66 61

Fig. 5. On-demand streaming—stability and robustness.

Fig. 6. Live-streaming—stability and robustness.

62 S. Kesavan, J. Jayakumar / Computers and Electrical Engineering 58 (2017) 49–66

Table 5
Buffer overflow/underflow occurrences.

Bandwidth settings Buffer overflow/underflow frequencies

On-demand Live

ARTRA TBA SFTBA ARTRA TBA SFTBA

2 Mbps 2 4 4 2 4 3
6 Mbps 0 3 2 0 5 2
2 to 6 Mbps: long BW variations 3 7 4 4 9 6
2 to 6 Mbps: short BW variations 4 11 8 7 20 14

Fig. 7. Comparison of playback buffer size under different bandwidths (2 to 6 Mbps).

variations in the network bandwidth. Thus, the ARTRA algorithm must be further optimized to improve its performance and
enhance the media streaming experience of the user.
Fig. 7 illustrates the algorithm playback buffer-size variation under variable-bandwidth. The behavior of the three algo-
rithms is plotted in the graph for a single-trial experiment at peak time. The graphs of 7a and b show that the buffer size
shrinks and is nearly empty in a few places; this leads to starvation. Similarly, a few times, the buffer level is nearly filled.
The buffer level decreases when the available bandwidth changes abruptly from high to low. This is clearly visible at media
durations of 80, 640, and 1160 s in the on-demand scenario. At the same point, in the live-streaming scenario, the ARTRA
buffer reaches a critically low level at 640 and 1080 s, and TBA and SFTBA exhibit buffer starvation. Plot 7 indicates that
ARTRA returns to the normal zone from the critical zone quicker than the other two algorithms. The ARTRA algorithm cau-
tiously calculates and decides the bitrate whenever there is a sudden change in the available bandwidth. This helps avoid
an abrupt decrease or increase in buffer occupancy. The graphs 7a and b clearly indicate that the client buffer in ARTRA
maintains a better consistency than the traditional rate-adaptation approach.

6.2.3. Achievable media throughput

The behavior of the algorithm in the bottleneck situation with short- and long-time bandwidth variations is analyzed in
detail. Short-time network variations and packet loss at the TCP level reduce the received throughput to below the expected
level. Short-time spike occurrence is considered as short-time variation if the duration is less than the segment duration.
In this experiment, we set the bandwidth variations to 4 and 8 s to study the behavior of the algorithm for short-time
variations.
Long-time bandwidth variations in adaptive streaming are variations greater than or equal to the segment duration.
The behavior of the algorithm is observed for long-time bandwidth variations, with up to three competitive clients sharing
the bandwidth randomly. Using the measured output, we examine the performance of the algorithms with regard to (1)
how close the received throughput is to the available bandwidth; (2) how quickly or slowly the algorithm converges to
bandwidth changes during the startup and steady phases; (3) the algorithm behavior in response to short-time and long-
time bandwidth variations; (4) how quickly the algorithm reacts to bandwidth congestion; and (5) the behavior of the
algorithm when additional clients share the available capacity. We consider the initial 60–80 s as the startup phase in which
the media player begins ramping up. The steady phase is considered to start after the client reaches the stable media
download bitrate—i.e., beyond 80 s.
Fig. 8 shows the average received throughput for on-demand and live streaming with long-time bandwidth variation.
Our experiment results show that when the available bandwidth is set to 4 Mbps from 0 to 100 s, ARTRA reaches 1200 Kbps
within three steps and 30 0 0 Kbps at nine steps in the on-demand playback scenario. At 100 s, the bandwidth drops to
2 Mbps. The bandwidth is not sufficient to continue receiving the 30 0 0- Kbps bitrate; thus, the algorithms must select lower
bitrates. ARTRA follows the bandwidth change and decreases from ∼30 0 0 to 20 0 0 Kbps in two steps, whereas SFTBA and
TBA take three to four steps. At 240 s, an additional parallel client connection is established with the server to share the
bandwidth. The bitrate tends to decrease owing to bandwidth reduction. Fig. 8 shows that ARTRA ensures its share during
more congested scenarios and maintains the bitrate at a more consistent level than the other algorithms. The bandwidth
 S. Kesavan, J. Jayakumar / Computers and Electrical Engineering 58 (2017) 49–66 63

Fig. 8. Long-bandwidth variation—comparison of average received throughput.

Fig. 9. Short-bandwidth variation—comparison of average received throughput.

Table 6
Comparison of average video quality.

Performance metrics On-demand streaming Live streaming

ARTRA SFTBA TBA ARTRA SFTBA TBA

Average PSNR (dB) 36.39 32.36 34.86 34.98 31.52 31.70

Min PSNR (dB) 26.04 22.51 27.01 27.06 21.01 20.05
Max PSNR (dB) 47.49 42.88 46.92 45.94 44.59 44.34
Standard Deviation (dB) 4.57 4.91 5.68 4.53 4.86 5.01

decreases to 4 Mbps at 630 s and increases to 6 Mbps at 890 s. Similar to the ramp-down scenario, ARTRA ramps up quickly,
in a few steps. The slow movement, up or down, with the bandwidth variation in TBA and SFTBA shows that the rate
switching is conservative and does not always select the optimal bitrate or keep the output close to the available bitrate.
The live-streaming behavior under variable-bandwidth conditions is similar, except that the received throughput sometimes
oscillates more and is two to three steps behind that of the on-demand streaming.
ARTRA handles short-time variations well. The short-time variations are handled in real time using an algorithm that
helps keep the received throughput close to the available bandwidth, resulting in an outstanding user experience. Fig. 9
shows the average received throughput for on-demand and live streaming with short-time bandwidth variations. A sudden
short-time upward bandwidth fluctuation occurs at 120 s for 8 s. Downward variation occurs at 240 s for 6 s. Fig. 9 shows
that the average bitrate received by all algorithms for the segment duration is relatively high when there is a short-time
upward bandwidth fluctuation. For a downward variation, the average received output is low. This causes playout buffer
overflow and underflow and leads to the selection of an improper bitrate for the next segment fetch. ARTRA handles the
buffer overflow/underflow problem via real-time segment downloading or buffer level-based scheduling.

6.2.4. Received video quality

The received video quality is one of the critical metrics by which the rate-adaptation performance is evaluated.
Application-level received video quality can be assessed using the average PSNR. The PSNR is a widely used subjective met-
ric for measuring application video quality. Details regarding the proposed and conventional algorithms for received video
quality are provided in Table 6 and Fig. 10. The PSNR values are measured frame-to-frame, and the average PSNR values for
each segment are plotted in the graph.
Fig. 10 shows the PSNR values calculated according to the video received at the client for the segment level. The exper-
imental results show that on average, the ARTRA algorithm achieves a PSNR advance of up to 3 dB more than the classical
SFTBA and TBA algorithms. The results show that the PSNRs for most of the ARTRA segments are greater than 30 dB, with a
comparatively small standard deviation. The reduction of the standard deviation indicates less deviation in the video quality
of the received segment.
64 S. Kesavan, J. Jayakumar / Computers and Electrical Engineering 58 (2017) 49–66

Fig. 10. Segment-level video-quality comparison.

Fig. 11. ARTRA segment arrival and request interval comparison.

The available bandwidth variation between 2 and 6 Mbps forces the algorithms to evaluate and choose different bitrate
segments. Poor rate adaptation and bitrate selection results in buffer underflow and glitches in the videos. This leads to
abrupt degradation in PSNR values. We observe from on-demand and live streaming video-quality comparison plots that
the quality decreases as the PSNR values approach 20 dB in a few occurrences due to poor received video quality or buffer
stalling. Plot 10 indicates that occurrences of a poor PSNR are fewer than they are in TBA and SFTBA. Although all algorithm
evaluation setups are prone to common transmission delays and channel errors, the performance of ARTRA is better because
ARTRA monitors, triggers, estimates, and fetches the segments in real time. This leads to a minimal number of buffer stalls,
reduced frame drops, and decreased packet delay; thus providing a glitch-free, continuous streaming experience.

6.2.5. Segment request and arrival interval

The segment request interval is the measure of the algorithm efficiency in terms of how close the segment schedule time
matches the real-time streaming data requirement to avoid video freezing at the client. The conventional rate-adaptation al-
gorithms SFTBA and TBA monitor the segment download rate and client capabilities and schedule the next segment down-
load request with the new bitrate. These algorithms adapt either periodic scheduling or late scheduling according to the
download and consumption data rates. In periodic scheduling, clients make a request to a new segment upon the arrival of
the previous segment; in late scheduling, upon the arrival of a previous segment, clients wait for the calculated time period
before making a request to the new segment.
Whenever the client requires more data to avoid a buffer stall and match the client playback speed, periodic and late
scheduling fail to fetch the segments in time, leading to a substandard user streaming experience. When multiple client
requests are segmented simultaneously, connecting to the server and accessing the content, the server load increases, and
the quality of the video stream declines. In live-streaming scenarios, segment availability and response require some time;
this significantly influences the performance during client playback.
The ARTRA segment request and arrival intervals are measured using on-demand and live DASH streaming with a seg-
ment duration of 10 s and variable bandwidths between 2 and 6 Mbps. The plots in Fig. 11 compare the segment time-
interval comparisons for on-demand and live streaming. The results show that ARTRA schedules 20–24% of the total seg-
ments in advance, compared to 40–52% for periodic scheduling and 25–28% for late scheduling. Live-streaming segments are
delayed more than on-demand streaming segments because of the dynamic packing and delivery at the server. The advance
scheduling in ARTRA allows subsequent segments to be fetched prior to the completion of the previous-segment download,
which allows the client to maintain data stability and provides an uninterrupted streaming experience. Advance scheduling
 S. Kesavan, J. Jayakumar / Computers and Electrical Engineering 58 (2017) 49–66 65

is the chief innovation in ARTRA, as it helps minimize the buffer-underrun occurrences and the streaming experience is an
improvement from that of conventional SFTBA and TBA algorithms. This is evident from the buffer underrun data in Section
6.2.2 and the buffer-level variation plot 7. ARTRA dynamically adapts to the playback environment and chooses different
scheduling approaches. The throughput, buffer level, and stability comparisons show that owing to its enhanced strategic
bitrate selection and real-time scheduling, ARTRA is more competent than classical algorithms. However, according to the
experimental results, ARTRA does not eliminate 100% of the buffer stalls, and slight quality-degradation issues remain. These
are opportunities to further explore and optimize the algorithm.

7. Conclusion

We proposed a novel ARTRA algorithm for dynamic adaptive streaming over HTTP that helps the client monitor the pa-
rameters in real time, evaluate the metrics, and choose the optimal next likely bitrate to fetch the segment. The proposed
rate-adaptation metric dynamically detects the network capacity and congestion by using the average throughput, client
buffer occupancy, and segment download time. The algorithm was implemented as a software component and evaluated
using a DASH adaptive-streaming client. Live and on-demand adaptive-streaming experiments were conducted in real-world
scenarios under highly variable network conditions. For comparison, we examined the behavior and performance of con-
ventional SFTBA and TBA algorithms using the identical experimental setup and network conditions. The performances of
the SFTBA, TBA, and ARTRA algorithms were compared in terms of the stability, robustness, buffer overflow/underflow oc-
currences, achievable throughput, PSNR, and segment arrival time. Experimental results show that ARTRA outperformed
the competition, with a faster rate convergence and minimal playback interruptions regardless of the segment sizes. ARTRA
helps take timely appropriate action to control the bitrate, deliver an out-of-the-box experience to the end user, and increase
the system reliability, content quality, and predictability of the end-to-end delivery network. ARTRA is not only an efficient
solution for optimizing the bitrate selection but can also be used for video-quality monitoring in real-time streaming. In the
future, we will investigate the QoE according to subjective metrics, as well as the optimization and suitability of ARTRA for
other adaptive-streaming models, such as HLS, HDS, and MSS.

Acknowledgments

We thank our colleagues at Accenture, Bangalore, and Karunya University for their extensive guidance and valuable com-
ments, which significantly improved the quality of our research.

References

[1] Fielding R, Gettys J, Mogul J.C, Frystyk H, Masinter L, Leach P, Berners-Lee T. Hyper-text Transfer Protocol-HTTP 1.1. RFC 2616; June 1999.
[2] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson. RTP: a transportprotocol for real-time applications. Internet Engineering Task Force. RFC 1889;
January 1996.
[3] 3GPP TS 26.247 Release 13.2.0: Transparent end-to-end Packet- switched Streaming Service (PSS). Progressive Download and Dynamic Adaptive
Streaming over HTTP (3GP-DASH).
[4] International Standard ISO/IEC 23009-1. Dynamic adaptive streaming over HTTP (DASH) http://standards.iso.org/ittf/PubliclyAvailableStandards/index.
html.
[5] Alaoui Youness, Dröge Sebastian. HTTP live streaming demuxer and rate algorithms implementation for Gstreamer HLS playback https://gstreamer.
freedesktop.org/src/gst- plugins- bad/;.
[6] Corvoysier David, Zakari Hamid. Dynamic Adaptive Streaming over HTTP demuxer and rate adaptation implementation for Gstreamer DASH playback
https://gstreamer.freedesktop.org/src/gst- plugins- bad/.
[7] Liu Chenghao, Bouazizib Imed, Miska M, Hannukselab MoncefGabbouja. Rate adaptation for dynamic adaptive streaming over HTTP in content distri-
bution network. Elsevier Signal Process 2012;27(4):288–311.
[8] Huang Te-Yuan, Johari Ramesh, McKeown Nick, Trunnell Matthew, Watson Mark. A buffer-based approach to rate adaptation: evidence from a large
video streaming service. SIGCOMM 2014;44(4):187–98.
[9] Zhou Chao, Lin Chia-Wen, Zhang Xinggong, Guo Zongming. Buffer-based smooth rate adaptation for dynamic HTTP streaming. In: IEEE Signal and
Information Processing Association Annual Summit and Conference; 2013. p. 1–9.
[10] Juluri P, Tamarapalli V, Medhi D. SARA: segment aware rate adaptation algorithm for dynamic adaptive streaming over HTTP. In: IEEE International
Conference on Communication Workshop (ICCW); 2015. p. 1765–70.
[11] Liu Chenghao, Bouazizi I, Gabbouj M. Segment duration for rate adaptation of adaptive HTTP streaming. In: IEEE International Conference on Multi-
media and Expo (ICME); 2011. p. 1–4.
[12] Liu C, Bouazizi I, Gabbouj M. Rate adaptation for adaptive HTTP streaming. In: ACM Conference on Multimedia systems; 2011. p. 169–74.
[13] Azumi Minoru, Kurosaka Takumi, Bandai Masaki. A QoE-aware quality-level switching slgorithm for adaptive video streaming. In: IEEE Global Com-
munications Conference (GLOBECOM); 2015. p. 1–5.
[14] Beben A, Wiśniewski P, Mongay Batalla J, Krawiec P. ABMA+: lightweight and efficient algorithm for HTTP adaptive streaming. In: Proceedings of the
7th International Conference on Multimedia Systems; 2016.
[15] Gstreamer:open source multimedia framework, http://gstreamer.freedesktop.org/; 2016.
66 S. Kesavan, J. Jayakumar / Computers and Electrical Engineering 58 (2017) 49–66

Selvaraj Kesavan received his B.E. in Electronics and Communication from Bharathiar University, Coimbatore, India in 20 0 0. He obtained his M.E. in Com-
munication Systems from Madurai Kamaraj University, Madurai, India in 2002. Currently, he is pursuing his Ph.D in the Department of Electrical and
Electronics Engineering, Karunya University, Coimbatore, India. His research interests include multimedia cloud computing, mobile multimedia, and multi-
media communications.

Jayakumar J received his M.E. in power systems from Madurai Kamaraj University, Madurai in 2002 and a Ph.D in Electrical Engineering from Anna
University, Chennai in 2010. He works as an Associate Professor at Karunya University, Coimbatore, India. His research interests are multimedia systems,
cloud computing, smart grids, and power-system analysis.