Open-Loop Rate Control for Adaptive VideoStreaming

Yongtao ShuaiTelecommunications Lab

Saarland UniversityEmail: shuai@nt.uni-saarland.de

Goran PetrovicTelecommunications Lab

Saarland UniversityEmail: petrovic@nt.uni-saarland.de

Thorsten Herfet, IEEE Senior MemberTelecommunications Lab

Saarland UniversityEmail: herfet@nt.uni-saarland.de

Abstract—Dynamic video streaming performs video rate selec-tion based on streaming client’s throughput estimate. In practice,the accuracy of the estimated throughput is limited due tofeedback delay and unawareness of the dynamics of the underlyingHTTP/TCP transport layer. Furthermore, state-of-the-art rateselection methods inherently introduce a two-fold quantizationerror, as will be detailed in this paper. As a result, streamingadaptation is often erroneous and causes client buffer instability.In this paper, we present Open-Loop rAte Control (OLAC), anadaptive streaming architecture designed to support low-latencystreaming applications. The key components of our architectureare a server-side simulation of the streaming client’s buffer,which provides a low-delay feedback for the video rate selection,and a hybrid adaptation logic based on throughput and bufferinformation, which stabilizes the adaptive response to dynamics oftransport and application layers. We evaluate the performance ofOLAC in wireless streaming scenarios by comparing it againsttwo well-known streaming architectures, QAC and vlc-pluginDASH. The results show that our approach achieves at least10% higher average quality and at least 73% lower rebufferingduration - achieving zero rebuffering duration in most scenarios- for dynamic live streaming with buffering delays as low as twoseconds.

I. INTRODUCTION

As media streaming rapidly gains on popularity and quality,it will represent a dominant share of Internet traffic in the nearfuture. Adaptive streaming is today’s prevailing technologyfor supporting video streaming over TCP by offering multiplequality levels for a video stream segmented into chunks. It iscurrently an international standard for Internet media streamingover HTTP (DASH [1], [2]).

A. Problem Statement

Extensive modeling and evaluations of adaptation schemeshave revealed that the state-of-the-art adaptive solutions reachacceptable video quality only under buffering of several tensof seconds [3], [4], [5]. Under an unpredictable throughputincurred by TCP’s flow and congestion control, HTTP-basedstreaming applications with a low buffering delay suffer fromvideo freezes and degraded quality. These issues become evenmore pronounced in wireless networks, due to poor channelquality and contention. Based on our own observations, thefollowing three inefficiencies are the main limiting factors for

the deployment of a high-quality media streaming, especiallyfor a low-latency live content:

First, the performance bottleneck is widely a result of theunderlying TCP transport layer, which introduces severe packetjitter and unstable throughput due to its loss- and window-basedcongestion control [4], [5], [6]. As a result, the performanceof streaming applications is very unstable in scenarios with asmall buffering delay.

Second, as the transport layer throughput is not explicitlyknown, the application needs to estimate it based on chunkdownload history. In practice, the estimation is often inaccurate[3]. In particular, the random disturbance of the transport-layer throughput imposed by the adaptation decisions at theapplication layer may lead to a biased throughput feedbackand trigger a downward spiral effect, resulting in undesirablyvariable and low video quality [3]. Furthermore, althoughmost adaptation schemes are client-based, the client feedbackintroduces a significant delay into the throughput estimationand adaptation.

Third, the transport layer throughput often significantly dif-fers from the average bit rate of the selected video chunk due toa two-fold quantization error. Namely, the client’s throughputestimate is quantized by a nominal video bit rate that is chosenfrom a discrete set of quality levels. In addition, the actualaverage bit rate of any chunk of the selected quality leveloscillates around the nominal bit rate of the respective leveldue to variable bit rate encoding. For instance, Figure 1 showsthe variance of the encoding bit rate for different quality levelsof the video sequence Big Buck Bunny from [7], where theaverage bit rate of each chunk may significantly differ fromthe nominal bit rate of the same quality level of the chunk. Inthis example, at least 50% chunks have an average bit rate ofat least 5− 45% higher or lower than the nominal bit rate.

B. Related Work

Commercial video streaming platforms apply extensivebuffering at the streaming client and a conservative rate selec-tion, in order to obtain smooth video rendering with acceptablebandwidth utilization. Akhshabi et al. observe a client buffersize of 30 s in commercial streaming platforms [4]. Due to the

0

1

2

3

4

5

6

7

8

9

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Quality Profile ID

Avera

ge C

hunk B

itra

te (

Mbps)

Figure 1. Average chunk bit rate in variable bit rate encoding. The red plusmarker denotes the outliers of the 5th and 95th percentiles, which are markedwith black bars. The blue box contains the bit rate range from the 25th to the75th percentile. The red bar in the center indicates the nominal video bit rate.

lack of accurate rate estimation, Huang et al. present a purebuffer-based adaptation algorithm with a client buffer size of60 s [3]. De Cicco et al. [5] shift the throughput estimation tothe server by monitoring the TCP sender buffer and achieve aclient buffer size of 15 s. Their approach improves the timeli-ness of congestion feedback and allows for the formulation ofthe rate selection as a control law applied to the buffer level.Lohmar et al. show analytically that the minimal delay forHTTP streaming is on the order of five chunk-durations [8].

C. Contributions

In contrast to the existing solutions, our objective is toachieve a low-latency dynamic video streaming service thatfulfills the delay constraints of a live media broadcast. Ourapproach focuses on a transport latency that is as small as thechunk duration of the adaptation set. Specifically, our designassumes chunk durations of 1−2s, which are the shortest chunkdurations found in commercial streaming solutions [4] and inthe research literature [5], [9].

The contributions of this paper are as follows:• We present the design of the Open-Loop rAte Control

(OLAC) architecture, including a virtual client buffer thatimplements sender-side simulation (referred to as mirroredbuffer) of the receiver buffer and removes feedback delayfrom the control loop, and a streaming rate selection thatcontrols a small receiver buffer so as to avoid underflowsand overflows.

• We deploy OLAC over TCP and over Predictably ReliableReal-time Transport (PRRT), a transport-layer protocolproposed in [10].

• We compare OLAC performance against the Quality

Rate Controller

Transport Protocol

(Congestion Control)

Virtual Client Buffer

Client Buffer

Rate Selection

Chunked (Real-time) Video Source

Video Rendering

Stre

amin

g Se

rver

Stre

amin

g C

lient

Figure 2. Open-loop rate control architecture.

Adaptation Controller (QAC), a rate controller for HTTPlive adaptive video streaming proposed in [5], and againstHTTP-based rate selection available in the implementationof the vlc-plugin DASH1 [11].

• Our streaming experiments show that in scenarios with alow buffering delay (two seconds), OLAC achieves zerorebuffering duration and 12−77% higher average qualitycompared to state-of-the-art solutions.

In the remainder of this paper, we describe the design of OLACin Section II and OLAC algorithms in Section III. We evaluatethe proposed solution in Section IV. We conclude the paper inSection V.

II. OPEN-LOOP DYNAMIC RATE CONTROL

The main design goal of OLAC is to maintain a stablebuffer level as small as the chunk duration (Figure 2). Toachieve this goal, OLAC implements the rate control at theserver, in contrast to most streaming solutions that adopt aclient-side rate control. With this architecture modification, weeliminate the feedback delay from clients in the control loop ofrate adaptation, which allows OLAC to increase the accuracyof throughput estimation and rate adaptation. In addition,rate control algorithms in OLAC are specifically designed tomaintain a stable buffer in low-delay streaming. To this end,the OLAC rate controller is based on both the throughput andthe buffer information.

To demonstrate the effectiveness of OLAC in practice, weimplement its architecture and algorithms in a Linux-basedstreaming prototype. The OLAC streaming is flexible in thatit can be configured to operate with different transport-layerprotocols. In this paper, we present two such configurations:

1It is the currently available DASH plugin for the VLC video player(http://www.videolan.org).

• First, we configure OLAC to use Predictably ReliableReal-time Transport (PRRT) as its transport layer [10].PRRT implements an efficient, predictably reliable errorcontrol for optimal utilization of the available bandwidthon wireless Internet paths. Reference [12] shows thatPRRT improves the bandwidth utilization by provid-ing a stable estimate of the available bandwidth andachieves opportunistic TCP-friendliness. In this configu-ration, OLAC benefits from PRRT by obtaining explicitthroughput estimates and a high bandwidth utilization. Werefer to the OLAC-over-PRRT configuration as DynamicAdaptive Streaming over PRRT (DASP).

• Second, OLAC is configured to operate over standardTCP-Cubic2 available in Linux systems [14]. For brevity,we refer to this OLAC configuration as Dynamic AdaptiveStreaming over TCP (DAST). Since standard TCP doesnot provide an explicit throughput estimation, we extendOLAC with a simple throughput estimation. Overall, theperformance of DAST is inferior to that of DASP. How-ever, an OLAC implementation over TCP is immediatelydeployable and allows a direct comparison to state-of-the-art rate selection methods, which commonly use standardTCP as their transport layer.

III. OLAC ALGORITHMS

Our proposed OLAC approach has two main componentsas shown in Figure 2. First, the mirrored client buffer atthe server avoids delayed feedbacks from clients. Second, anadvanced rate control based on both the throughput and thebuffer information is implemented in order to maximize andstabilize the video quality level under the available networkbandwidth. An additional advantage of our rate control, ascompared to state-of-the-art methods surveyed in Section I-B,is that it minimizes the quantization error due to the largevariation of the coding bit rate (illustrated in I-A). We achievethis by using the average bit rate of a video chunk during thechunk selection, which will be detailed in Section III-B.

A. Virtual Client Buffer

To avoid the delayed feedback from the receiver, our mir-rored buffer simulates the client buffer at the streaming serveras follows:

b(t) =∑v∈Vt

v

rj(v)c [k(v)]

− t, (1)

where t is the time elapsed since the first video packet wassent, Vt is the set of video packets sent within the durationof t, rj(v)c is the average bit rate of a video chunk encoded atvideo quality level Rj(v), and j(v) and k(v) are the qualitylevel and the video chunk that correspond to video packetv, respectively. We introduce the variable b[i] to denote the

2All implementations of DASH, QAC, and DAST mentioned in this paperare based on TCP-Cubic [13], the default TCP flavor in current Linux andAndroid systems [14].

Table IVARIABLES OF THE RATE CONTROL ALGORITHM

P (·) bandwidth prediction functionE(·) video bit rate evaluation functionS(·) quality profile selection functiona available bandwidthr desired video bit rateTc video chunk durationrjc average bit rate of a video chunk in quality level RjR set of quality levels (bit rates) R := R1, ..., RLR video quality level (nominal bit rate)g average throughput per video chunkb mirrored buffer level (in time units)d buffer deviation (in time units)

βmax maximum client buffer size (in time units)βref desired buffer level (in time)

simulated buffer level b(t) at the time we start to streamvideo chunk i. Therefore, given the average video bit rate ofa video chunk, we translate the transmitted data volume intoits corresponding video duration and calculate the differencebetween the video duration of sent video data and the actualelapsed time of sending those video data. Due to the delay-constrained packet arrival ensured by the congestion and errorcontrol of PRRT, the mirrored buffer is an accurate estimate ofthe client buffer.

B. Rate Control

Algorithm 1 General Rate ControlAt the beginning of each streaming video chunk i:

1) Predict the available bandwidth a[i] for the chunk i as:

a[i] = P (g[n] : h ≤ n < i) (2)

where g[n] denotes average throughput of the chunk n,and h denotes the chunks preceding chunk i.

2) Evaluate the desired video bit rate r[i] under considera-tion of the mirrored buffer level b[i] as:

r[i] = E(a[i], b[i]) (3)

3) Determine the quality level R[i] for the chunk i as:

R[i] = S(r[i], b[i]) (4)

Our OLAC solution, implemented at the server, controlsthe video coding rate based on both the throughput and thevirtual buffer information. Algorithm 1 formulates a generalframework for OLAC where the functions applied in eachstep can be customized. Starting from a throughput estimate,our algorithm formulates a control loop with the objective ofreaching a desired buffer level while operating with a periodof one video chunk duration. Table I summarizes the variablesused in the rate control algorithm. The algorithm consists ofthe following steps.

Step 1): We use the mean of four previous throughputsamples as the current throughput estimate (i.e. h = i− 4).

Step 2): For each chunk, we evaluate the deviation of thevirtual buffer level b[i] from the desired buffer level βref . Thisdeviation results from quantization errors during previous rateselection steps as well as from inaccuracies of the throughputestimation. In order to compensate for the buffer deviation, wedetermine the desired video bit rate r[i] for the next chunk as:

r[i] = a[i]

(1 +

b[i]− βrefTc

). (5)

In this paper, we set βref = 0.5 · βmax, where βmax is theclient’s maximum buffer size and for simplicity, we assumethat buffer overflow and buffer underflow thresholds have thesame value.

Step 3): Frequent and abrupt changes of the quality levelshould be avoided by the rate control algorithm, as theyadversely affect the user’s viewing experience [9], [15]. There-fore, our rate control jointly considers the quality of a numberof N future chunks when making the rate decision. Ideally,our rate control selects these N chunks such that the videoquality remains constant. However, a rate selection that solelyoptimizes for video quality, while neglecting the buffer in-formation, may lead to buffer underflow or overflow events.To take both the video quality and the buffer informationinto account, our rate control explicitly considers the bufferlevel and dynamically adjusts the number of considered futurechunks N as follows:

N = 1 +

⌊min(b[i], βmax − b[i])

Tc

⌋, (6)

This equation shows that we can avoid buffer underflow andoverflow events by considering only a limited number ofchunks N into the future. Intuitively, if the virtual buffer levelb[i] deviates significantly from the desired buffer level βref ,we consider a small number of future chunks N . This enablesus to stabilize the buffer level at the expense of variationsof video quality. In turn, if the deviation is small, we canafford to consider a large number of future chunks in thefuture and equalize their video qualities. Correspondingly, themaximum number of future chunks N is employed in caseswhere the buffer level is equal to the desired buffer level,i.e.,βref = 0.5 · βmax.

After computing the desired video bit rate r[i] and thenumber of future chunks N , we determine the quality levelR[i] as follows. Our aim when computing R[i] is to minimizethe quantization error Qerr(·), which is due to two factors: (1)deviation of the nominal rate from the average chunk rate (dueto variable bit rate encoding, as illustrated in Figure 1) and (2)deviation of the desired rate from the nominal rate.

With respect to the first factor, we aim to minimize thedeviation of the nominal rate (quality level) Rj from theaverage chunk rate rjc . This is achieved as follows. By selecting

a nominal rate Rj (corresponding to desired rate r[i]), thequantization error of Qerr(·) can be quantified as:

Qerr(Rj , r[i], b[i]) = |r[i]−Rj | . (7)

In order to reduce this quantization error, our solution is tocompute the average of N future average chunk rates rjc anduse it instead of the nominal rate Rj :

Qerr(Rj , r[i], b[i]) =

∣∣∣∣∣∣r[i]− 1N∑

i≤k

Dynamic Streaming Client Buffer Level Mirrored Buffer Level

0 20 40 60 80 10012014016018002468

10121416

a.) DASH with client buffer size 2s

Qualit

y L

evel (M

bps)

0 20 40 60 80 1001201401601800

1

2

0 20 40 60 80 10012014016018002468

10121416

b.) QAC with client buffer size 2s

0 20 40 60 80 1001201401601800

1

2

0 20 40 60 80 10012014016018002468

10121416

c.) DAST with client buffer size 2s

0 20 40 60 80 1001201401601800

1

2

0 20 40 60 80 10012014016018002468

10121416

d.) DASP with client buffer size 2s

0 20 40 60 80 1001201401601800

1

2

Buffer

Level (s

)

0 20 40 60 80 10012014016018002468

10121416

e.) DASH with client buffer size 4s

Qualit

y L

evel (M

bps)

0 20 40 60 80 1001201401601800

2

4

0 20 40 60 80 10012014016018002468

10121416

f.) QAC with client buffer size 4s

0 20 40 60 80 1001201401601800

2

4

0 20 40 60 80 10012014016018002468

10121416

g.) DAST with client buffer size 4s

0 20 40 60 80 1001201401601800

2

4

0 20 40 60 80 10012014016018002468

10121416

h.) DASP with client buffer size 4s

0 20 40 60 80 1001201401601800

2

4

Buffer

Level (s

)

0 20 40 60 80 10012014016018002468

10121416

i.) DASH with client buffer size 8s

Qualit

y L

evel (M

bps)

0 20 40 60 80 1001201401601800

4

8

0 20 40 60 80 10012014016018002468

10121416

j.) QAC with client buffer size 8s

0 20 40 60 80 1001201401601800

4

8

0 20 40 60 80 10012014016018002468

10121416

k.) DAST with client buffer size 8s

0 20 40 60 80 1001201401601800

4

8

0 20 40 60 80 10012014016018002468

10121416

l.) DASP with client buffer size 8s

0 20 40 60 80 1001201401601800

4

8

Buffer

Level (s

)

0 20 40 60 80 10012014016018002468

10121416

a.) DASH with client buffer size 2s

Qualit

y L

evel (M

bps)

0 20 40 60 80 1001201401601800

1

2

0 20 40 60 80 10012014016018002468

10121416

b.) QAC with client buffer size 2s

0 20 40 60 80 1001201401601800

1

2

0 20 40 60 80 10012014016018002468

10121416

c.) DAST with client buffer size 2s

0 20 40 60 80 1001201401601800

1

2

0 20 40 60 80 10012014016018002468

10121416

d.) DASP with client buffer size 2s

0 20 40 60 80 1001201401601800

1

2

Buffer

Level (s

)

0 20 40 60 80 10012014016018002468

10121416

e.) DASH with client buffer size 4s

Qualit

y L

evel (M

bps)

0 20 40 60 80 1001201401601800

2

4

0 20 40 60 80 10012014016018002468

10121416

f.) QAC with client buffer size 4s

0 20 40 60 80 1001201401601800

2

4

0 20 40 60 80 10012014016018002468

10121416

g.) DAST with client buffer size 4s

0 20 40 60 80 1001201401601800

2

4

0 20 40 60 80 10012014016018002468

10121416

h.) DASP with client buffer size 4s

0 20 40 60 80 1001201401601800

2

4

Buffer

Level (s

)

0 20 40 60 80 10012014016018002468

10121416

i.) DASH with client buffer size 8s

Qualit

y L

evel (M

bps)

0 20 40 60 80 1001201401601800

4

8

0 20 40 60 80 10012014016018002468

10121416

j.) QAC with client buffer size 8s

0 20 40 60 80 1001201401601800

4

8

0 20 40 60 80 10012014016018002468

10121416

k.) DAST with client buffer size 8s

0 20 40 60 80 1001201401601800

4

8

0 20 40 60 80 10012014016018002468

10121416

l.) DASP with client buffer size 8s

0 20 40 60 80 1001201401601800

4

8

Buffer

Level (s

)

0 20 40 60 80 10012014016018002468

10121416

a.) DASH with client buffer size 2s

Qualit

y L

evel (M

bps)

0 20 40 60 80 1001201401601800

1

2

0 20 40 60 80 10012014016018002468

10121416

b.) QAC with client buffer size 2s

0 20 40 60 80 1001201401601800

1

2

0 20 40 60 80 10012014016018002468

10121416

c.) DAST with client buffer size 2s

0 20 40 60 80 1001201401601800

1

2

0 20 40 60 80 10012014016018002468

10121416

d.) DASP with client buffer size 2s

0 20 40 60 80 1001201401601800

1

2

Buffer

Level (s

)

0 20 40 60 80 10012014016018002468

10121416

e.) DASH with client buffer size 4s

Qualit

y L

evel (M

bps)

0 20 40 60 80 1001201401601800

2

4

0 20 40 60 80 10012014016018002468

10121416

f.) QAC with client buffer size 4s

0 20 40 60 80 1001201401601800

2

4

0 20 40 60 80 10012014016018002468

10121416

g.) DAST with client buffer size 4s

0 20 40 60 80 1001201401601800

2

4

0 20 40 60 80 10012014016018002468

10121416

h.) DASP with client buffer size 4s

0 20 40 60 80 1001201401601800

2

4

Buffer

Level (s

)

0 20 40 60 80 10012014016018002468

10121416

i.) DASH with client buffer size 8s

Qualit

y L

evel (M

bps)

0 20 40 60 80 1001201401601800

4

8

0 20 40 60 80 10012014016018002468

10121416

j.) QAC with client buffer size 8s

0 20 40 60 80 1001201401601800

4

8

0 20 40 60 80 10012014016018002468

10121416

k.) DAST with client buffer size 8s

0 20 40 60 80 1001201401601800

4

8

0 20 40 60 80 10012014016018002468

10121416

l.) DASP with client buffer size 8s

0 20 40 60 80 1001201401601800

4

8

Buffer

Level (s

)

0 20 40 60 80 10012014016018002468

10121416

a.) DASH with client buffer size 2s

Qu

alit

y L

eve

l (M

bp

s)

0 20 40 60 80 1001201401601800

1

2

0 20 40 60 80 10012014016018002468

10121416

b.) QAC with client buffer size 2s

0 20 40 60 80 1001201401601800

1

2

0 20 40 60 80 10012014016018002468

10121416

c.) DAST with client buffer size 2s

0 20 40 60 80 1001201401601800

1

2

0 20 40 60 80 10012014016018002468

10121416

d.) DASP with client buffer size 2s

0 20 40 60 80 1001201401601800

1

2

Bu

ffe

r L

eve

l (s

)

0 20 40 60 80 10012014016018002468

10121416

e.) DASH with client buffer size 4s

Qu

alit

y L

eve

l (M

bp

s)

0 20 40 60 80 1001201401601800

2

4

0 20 40 60 80 10012014016018002468

10121416

f.) QAC with client buffer size 4s

0 20 40 60 80 1001201401601800

2

4

0 20 40 60 80 10012014016018002468

10121416

g.) DAST with client buffer size 4s

0 20 40 60 80 1001201401601800

2

4

0 20 40 60 80 10012014016018002468

10121416

h.) DASP with client buffer size 4s

0 20 40 60 80 1001201401601800

2

4

Bu

ffe

r L

eve

l (s

)

0 20 40 60 80 10012014016018002468

10121416

i.) DASH with client buffer size 8s

Qu

alit

y L

eve

l (M

bp

s)

0 20 40 60 80 1001201401601800

4

8

0 20 40 60 80 10012014016018002468

10121416

j.) QAC with client buffer size 8s

0 20 40 60 80 1001201401601800

4

8

0 20 40 60 80 10012014016018002468

10121416

k.) DAST with client buffer size 8s

0 20 40 60 80 1001201401601800

4

8

0 20 40 60 80 10012014016018002468

10121416

l.) DASP with client buffer size 8s

0 20 40 60 80 1001201401601800

4

8

Bu

ffe

r L

eve

l (s

)

Figure 3. Video quality level and buffer level when competing with a single TCP flow.

By inserting Program Clock References in the packet stream,we enable the receiver to synchronize its clock to the serverclock and avoid the drift. The adaptation set includes bit ratesbetween 1Mbps and 16Mbps under variable bit rate encoding.Between 1Mbps and 6Mbps the bit rate increases in steps of1Mbps, above 6Mbps the step size is 2Mbps.

A. Comparison with state-of-the-art architectures

Our experimental evaluation includes a comparison withstate-of-the-art HTTP-based rate selection. Specifically, wecompare OLAC performance against vlc-plugin DASH [11]and Quality Adaptation Controller (QAC) for adaptive videostreaming [5]. In case of vlc-plugin DASH, a reference imple-mentation is freely available. In case of QAC, to the best ofour knowledge, a reference implementation is not available. Tothis end, we have developed our own implementation of QACfollowing the description in the research paper [5]. Therefore,our performance comparison contains 4 sets of performanceresults, including: vlc-plugin DASH, QAC, DAST (OLAC overTCP) and DASP (OLAC over PRRT).

B. Competing with TCP traffic

Figure 3 shows the performance of these four different dy-namic streaming approaches (vlc-plugin DASH, QAC, DAST,DASP) when competing with a TCP flow in terms of videoquality level and buffer level.

DAST and DASP obtain the best performance. First, thevideo stream with DAST and DASP is continuously deliveredat a high video bit rate and our rate adaptation reacts smoothly

to the injection of competing traffic by converging to anequal share of the bottleneck bandwidth. After removal ofthe competing flow, the video stream completely re-acquiresthe available bandwidth. Second, DASP accurately tracks thedynamics of the receiver buffer due to the accurate throughputinformation provided by PRRT. The buffer level convergestowards the desired buffer level of 1 s. In contrast, DASTcannot track the receiver buffer dynamics as well as DASP andit suffers from short rebuffering duration. The reason is that thedelivery of video packets over TCP has no delay constraints andthe throughput estimate is imprecise. As shown in Figure 3.c,the buffer level of DAST reaches a very low level of 0.4 s attime instants of 62, 85, 96, 128 seconds and reaches 0 s at 62second in Figure 3.g. These results confirm the efficiency of ourOLAC control scheme: the converging buffer level indicatesthat the application layer absorbs the dynamics of transportlayer with a precise throughput estimate, and the mismatchbetween transport-layer throughput and the discrete set ofavailable video bit rates is minimized. The buffer simulation,however, still shows large variations at the beginning of theexperiment (in the interval 0−60 seconds for DAST and DASPin Figure 3). This is due to variable complexity of the videocontent and the resulting discrepancy between the video qualitylevel of the adaptation set and the actual chunk bit rate undervariable bit rate encoding. Intuitively, such variations can beeffectively compensated by a larger receiver buffer. Our ratecontrol algorithm implements an explicit trade-off between thereceiver buffer size and the stability of the rate selection. As

a.) Average quality level b.) Rebuffering duration

DASH QAC DAST DASP0

5

10

15

20

Bitra

te (

Mbps)

Streaming scenariosDASH QAC DAST DASP

0

10

20

30

40

Un

de

rflo

ws (

Se

co

nd

s)

Streaming scenarios

buffer size 2s

buffer size 4s

buffer size 8s

Figure 4. Aggregate performance when competing with a single TCP flow:(a) average quality level in the intervals 1 -59 seconds and 121 -180 seconds;(b) rebuffering duration for the entire session.

demonstrated in Figure 3.k and 3.l, a larger receiver buffer of8 s provides a wider control range to the rate control algorithm.

DASH suffers from significant changes of video qualitywhen competing with TCP traffic. In case of the client buffersize of 2 s, these issues are especially visible and last for theentire session. The reason is that DASH applies a simplistic rateselection based on the measurement of the average throughputat the HTTP client.

Although QAC obtains the smoothest quality variation, itexhibits a strong mismatch between quality selection and theavailable bandwidth. Therefore it shows the longest rebufferingduration among all approaches. This is due to the fact that QACadaptation reacts too slowly in the case of a small receiverbuffer. In particular, QAC applies a feedback control loopwhere the quality selection is based on the buffer deviationfrom the target buffer5 in the Proportional-Integral (PI) controllaw. In the case of a small target buffer, errors accumulate andcause a slow control behaviour. Although we can change thebehavior of the adaptation by tuning the parameters of the PIcontrol law, we can only eliminate rebuffering if we enforce alow bandwidth utilization at all times during streaming.

Figure 4 gives an overview of the aggregate quality perfor-mance of the four different streaming architectures in terms ofaverage quality level and rebuffering duration. It shows thatour open-loop rate control architecture significantly improvesthe performance compared with DASH and QAC. The DASPconfiguration achieves the best performance due to the deploy-ment over PRRT instead of HTTP/TCP. DASP achieves zerorebuffering duration while keeping a high average quality levelof about 12Mbps of 16Mbps, 10− 17% higher than DASHand 38 − 66% higher than QAC. DAST (OLAC over TCP)obtains the highest average quality level of about 13Mbps, atleast 23% higher than DASH and 59% than QAC. However,DAST suffers from short-duration underflows. Still, DAST hasa rebuffering duration at least 73% lower than DASH andQAC. In the case of client buffer size 2 s, OLAC achieveszero rebuffering duration and 14−77% higher average qualitylevel compared to DASH and QAC.

DASP1 DASP2 DASP3

a.) DASH with client buffer size 2 s

0 20 40 60 80 100 120 140 160 1800

5

10

15

20

Bitra

te (

Mbps)

0 20 40 60 80 100 120 140 160 1800

1

2

Buffer

Level (s

)

(I)

(II)

b.) QAC with client buffer size 2 s

0 20 40 60 80 100 120 140 160 1800

5

10

15

20

Bitra

te (

Mbps)

0 20 40 60 80 100 120 140 160 1800

1

2

Buffer

Level (s

)

(I)

(II)

c.) DAST with client buffer size 2 s

0 20 40 60 80 100 120 140 160 1800

5

10

15

20

Bitra

te (

Mbps)

0 20 40 60 80 100 120 140 160 1800

1

2

Buffer

Level (s

)

(I)

(II)

d.) DASP with client buffer size 2 s

0 20 40 60 80 100 120 140 160 1800

5

10

15

20

Bitra

te (

Mbps)

0 20 40 60 80 100 120 140 160 1800

1

2

Buffer

Level (s

)

(I)

(II)

Figure 5. Video quality level and buffer level of multiple streaming sessions.

a.) Average quality level b.) Rebuffering duration

2s4s8s 2s4s8s 2s4s8s 2s4s8s0

5

10

15

20

25

30

Bitra

te (

Mb

ps)

Streaming scenarios (buffer sizes)

DASH QAC DAST DASP

2s4s8s 2s4s8s 2s4s8s 2s4s8s0

20

40

60

80

100

Underf

low

s (

seconds)

Streaming scenarios (buffer sizes)

session1

session2

session3

QAC

DASPDAST

DASH

Figure 6. Aggregate performance for multiple streaming sessions: (a) averagequality level in the interval 60 -120 seconds; (b) rebuffering duration for theentire session.

C. Multiple Streaming Sessions

To evaluate the performance of all four streaming architec-tures in scenarios with competing video sessions, we perform aseparate experiment for each architecture. In each experiment,we instantiate two concurrent streaming sessions and maximumclient buffer sizes of 2 s, 4 s and 8 s, respectively. The resultsshow that all solutions allow the competing video sessions togradually acquire their fair share of the bottleneck bandwidth.Likewise, our measurements of the buffer level demonstratethat the buffer in DASP is maintained at the same level for allconcurrent multiple sessions. Overall, these experiments showthat DASP preserves fairness with respect to the bandwidthutilization and the buffer level, thus preserving a similar videoquality among multiple competing sessions. In Figure 5, weonly demonstrate the behavior in terms of average quality leveland buffer level with the client buffer size of 2 s and omit theresults for other buffer sizes since they show a similar trend.

Similar to the scenario with competing TCP flows, Figure 6shows that DAST and DASP obtain the best performance andachieve at least 10% higher average quality level compared toDASH and QAC. In addition, DAST and DASP achieve a betterrebuffering performance. In particular, the streaming sessionswith DASP have a zero rebuffering duration, while DAST has95% lower rebuffering duration compared to DASH and QAC.In the case of client buffer size 2 s, OLAC achieves 12− 33%higher average quality level and at least 97% lower rebufferingduration, compared to DASH and QAC.

V. CONCLUSION

Adaptive HTTP-based media streaming suffers from delayedand inaccurate throughput feedback obtained at the applicationlayer of the streaming client. Further, under dynamic streamswitching with a discrete set of variable bit rate encodings,the rate selection suffers from quantization errors. As a resultof inaccurate rate selection, dynamic HTTP flows underutilizethe available bandwidth and suffer from buffer instability. Theseissues are particularly pronounced if the receiver buffer is smallin order to facilitate low-latency streaming services.

We propose OLAC, a novel approach to dynamic streamingthat effectively controls a small receiver buffer required for low-

5The target buffer level is set to the maximum client buffer level in [5].

latency streaming services. The OLAC architecture introducesa virtual client buffer and an advanced rate control that jointlyavoid buffer instability at the receiver and compensate forinaccurate selection of the video bit rate. We implement theproposed dynamic streaming architecture and algorithms on topof two transport-layer protocols, TCP and PRRT, and comparetheir performance against two state-of-the-art solutions, QACand vlc-plugin DASH. Experimental evaluations show thatOLAC significantly improves the stability and the efficiency ofthe video rate selection in scenarios with single and multiplecompeting flows, while preserving fairness. Specifically, weachieve zero rebuffering duration in the PRRT configurationand at least 73% lower rebuffering duration compared to DASHand QAC in the TCP configuration. In addition, OLAC achievesat least 10% higher average quality for dynamic live streamingwith buffering delays as low as two seconds.

VI. ACKNOWLEDGMENTS

This work was supported by the Spitzencluster-Initiativefrom the Federal Ministry of Education and Research (BMBF)under the project number 01IC12S01X and the Intel VisualComputing Institute under the project Efficient Multi-ViewVideo Streaming System.

REFERENCES[1] T. Stockhammer. Dynamic adaptive streaming over HTTP – standards

and design principles. In ACM MMSys, 2011.[2] ISO/IEC. 23009-1:2014 - dynamic adaptive streaming over http (dash):

Media presentation description and segment formats, 2014.[3] T. Huang, R. Johari, and N. McKeown. Downton abbey without the

hiccups: Buffer-based rate adaptation for http video streaming. In ACMSIGCOMM, FhMN Workshop, 2013.

[4] S. Akhshabi, S. Narayanaswamy, A. C. Begen, and C. Dovrolis. Anexperimental evaluation of rate-adaptive video players over HTTP. SignalProc.: Image Comm., 27(4):271 – 287, 2012.

[5] L. De Cicco, S. Mascolo, and V. Palmisano. Feedback control for adaptivelive video streaming. In ACM MMSys, 2011.

[6] B. Wang, J. Kurose, P. Shenoy, and D. Towsley. Multimedia streamingvia tcp: An analytic performance study. ACM Trans. Multimedia Comput.Commun. Appl., 4(2):16:1–16:22, May 2008.

[7] S. Lederer, C. Müller, and C. Timmerer. Dynamic adaptive streamingover http dataset. In ACM MMSys, 2012.

[8] T. Lohmar, T. Einarsson, P. Frojdh, F. Gabin, and M. Kampmann.Dynamic adaptive http streaming of live content. In IEEE WOWMOM,2011.

[9] J. Jiang, V. Sekar, and H. Zhang. Improving fairness, efficiency, andstability in http-based adaptive video streaming with festive. In ACMCoNEXT, 2012.

[10] M. Gorius, Y. Shuai, and T. Herfet. Predictably reliable media transportover wireless home networks. In IEEE CCNC, 2012.

[11] C. Müller and C. Timmerer. A VLC media player plugin enablingdynamic adaptive streaming over HTTP. In ACM Multimedia, 2011.

[12] M. Gorius, Y. Shuai, and T. Herfet. Dynamic media streaming withpredictable reliability and opportunistic TCP-friendliness. In IEEECCNC, 2013.

[13] S. Ha, I. Rhee, and L. Xu. CUBIC: a new TCP-friendly high-speed TCPvariant. ACM SIGOPS operating systems review, 42:64–74, July 2008.

[14] M.A. Mehmood, C. Sengul, N. Sarrar, and A. Feldmann. Understandingcross-layer effects on quality of experience for video over NGMN. InIEEE ICC, 2011.

[15] R. Mok, E. Chan, X. Luo, and R. Chang. Inferring the qoe of http videostreaming from user-viewing activities. In ACM SIGCOMM W-MUSTworkshop, 2011.