A Control-Theoretic Approach forDynamic Adaptive Video Streaming over HTTP

Xiaoqi Yin, Abhishek Jindal, Vyas Sekar, Bruno SinopoliCarnegie Mellon University

{yinxiaoqi522, abhishekjindal93}@gmail.com, {vsekar,brunos}@andrew.cmu.edu

ABSTRACTUser-perceived quality-of-experience (QoE) is critical in In-ternet video applications as it impacts revenues for contentproviders and delivery systems. Given that there is little sup-port in the network for optimizing such measures, bottle-necks could occur anywhere in the delivery system. Conse-quently, a robust bitrate adaptation algorithm in client-sideplayers is critical to ensure good user experience. Previ-ous studies have shown key limitations of state-of-art com-mercial solutions and proposed a range of heuristic fixes.Despite the emergence of several proposals, there is still adistinct lack of consensus on: (1) How best to design thisclient-side bitrate adaptation logic (e.g., use rate estimatesvs. buffer occupancy); (2) How well specific classes of ap-proaches will perform under diverse operating regimes (e.g.,high throughput variability); or (3) How do they actuallybalance different QoE objectives (e.g., startup delay vs. re-buffering). To this end, this paper makes three key technicalcontributions. First, to bring some rigor to this space, wedevelop a principled control-theoretic model to reason abouta broad spectrum of strategies. Second, we propose a novelmodel predictive control algorithm that can optimally com-bine throughput and buffer occupancy information to outper-form traditional approaches. Third, we present a practicalimplementation in a reference video player to validate ourapproach using realistic trace-driven emulations.

CCS Concepts•Information systems→Multimedia streaming; •Networks→Network protocol design; Application layer protocols;

KeywordsInternet Video; Bitrate Adaptation; DASH; Model PredictiveControl

Permission to make digital or hard copies of all or part of this work for personalor classroom use is granted without fee provided that copies are not made ordistributed for profit or commercial advantage and that copies bear this noticeand the full citation on the first page. Copyrights for components of this workowned by others than ACM must be honored. Abstracting with credit is per-mitted. To copy otherwise, or republish, to post on servers or to redistribute tolists, requires prior specific permission and/or a fee. Request permissions frompermissions@acm.org.

SIGCOMM ’15, August 17 - 21, 2015, London, United Kingdomc© 2015 ACM. ISBN 978-1-4503-3542-3/15/08. . . $15.00

DOI: http://dx.doi.org/10.1145/2785956.2787486

1 IntroductionMany recent studies have highlighted the critical role thatuser-perceived quality-of-experience (QoE) plays in Internetvideo applications, as it ultimately affects revenue streamsfor content providers [24, 35]. Specifically, metrics such asthe duration of rebuffering (i.e., the player’s playout bufferdoes not have content to render), startup delay (i.e., the lagbetween the user clicking vs. the time to begin rendering),the average playback bitrate, and the variability of the bitratedelivered have emerged as key factors.

Given the complex Internet video delivery ecosystem andpresence of diverse bottlenecks, the bitrate adaptation logicin the client-side video player becomes critical to optimizeuser experience [16]. In the HTTP-based delivery model thatpredominates today [44], videos are typically chunked andencoded at different bitrate levels. The goal of an adaptivevideo player is to choose the bitrate level for future chunksto deliver the highest possible QoE; e.g., maximizing bitratewhile minimizing the likelihood of rebuffering and avoidingtoo many bitrate switches.

Many recent efforts have pointed out key challenges in de-signing this adaptation logic (e.g., [46, 17, 32, 34]) and sev-eral proposals have emerged to try and address these chal-lenges (e.g., [34, 17, 33]). Despite the proliferation of nu-merous algorithms, however, there appears to be a lack ofclarity and consensus across these solutions on several fronts;e.g., some argue for better throughput estimation [47], whileothers suggest improving chunk scheduling [34]. Some re-searchers even argue against rate-based approaches that relyon throughput estimates from previous chunk downloads andmake the case for buffer-occupancy based algorithms thatmake their decisions purely based on buffer occupancy [33].

In order to understand the fundamental tradeoffs betweendifferent classes of algorithms (e.g., rate- vs buffer-based)under different operating regimes (e.g., low vs. high through-put variability), we begin by formulating the video bitrateadapdation as a stochastic optimal control problem. We for-mally define the key dynamic variables involved in the videoadaptation problem and a concrete objective. This frame-work allows us to outline the broader design space of controlalgorithms for this problem. We identify a key shortcomingin existing approaches that rely exclusively on pure rate- orbuffer-based strategies, and that might be potentially missingout on strategies that combine both signals.

Building on insights from the control-theoretic formula-tion, we argue that model predictive control (MPC) [22] is

325

a suitable class of algorithms that can optimally combineboth rate-based and buffer-based feedback signals. At a highlevel, MPC attempts to predict key environment variablesover a moving look-ahead horizon and solve an exact opti-mization problem based on the prediction. MPC is the tech-nology of choice in a multitude of real world control prob-lems [22]. In addition to its intuitive formulation, it can ex-plicitly handle complex control objectives and constraints,and has a set of well understood tuning parameters such asthe prediction horizon. Moreover, MPC has other qualitativeadvantages as its development time is much shorter com-pared to advanced control methods and it is easier to main-tain, as changing model parameters does not require com-plete redesign.

In our context, the MPC approach entails predicting theexpected throughput for the next few chunks and using thisto make optimal bitrate decisions for QoE maximization. In-deed, our simulation results confirm that if we could run anoptimal MPC algorithm and the prediction error was low,then the MPC scheme can outperform traditional rate-basedand buffer-based strategies.

In practice, however, running a MPC-based algorithm ischallenging because it needs to solve a non-trivial discreteoptimization problem at each time step. Even ignoring thecomputational overhead, there are practical difficulties aswe might need to bundle this solver logic with every videoplayer or require users to download and install additionalsoftware. To address these challenges, we develop a simple-yet-efficient FastMPC mechanism. Conceptually, FastMPCessentially follows a table enumeration approach, where wedescribe the problem state-space, solve the specific instancesoptimally offline, and store the optimal control decisions forfuture online use. If implemented naively, however, the sizeof this table can induce significant memory overhead andstartup delays for video players (e.g., additional JavaScriptto load). Fortunately, we show that with a simple value bin-ning and compression strategy, we can achieve near-optimalperformance with manageable table sizes.

We have prototyped our FastMPC bitrate adaptation algo-rithm in an open source dynamic adaptive streaming playercalled dash.js [1]. Our choice of platform is a prag-matic one—it is the reference open-source implementationfor the MPEG-DASH standard based on the HTML5 speci-fication and is actively supported by leading industry partic-ipants [7]. We show that our implementation adds negligibleoverhead to the baseline dash.js player. We also show-case the FastMPC-based player in our demo page [14].

We evaluate our algorithms and prototype implementa-tion using realistic emulation experiments on measured [9,10] and synthetic throughput variability traces. We also aug-ment these results with simulation-based sensitivity analysisexperiments to analyze the effect of key operating parame-ters on the performance of different classes of algorithms.Our key findings are:

1. Our proposed MPC approach consistently outperformsthe state-of-art adaptation algorithms by 15% in broad-band (FCC) dataset and 10% in cellular (HSDPA) dataset

in terms of median QoE. It also achieves significant im-provement (60+% median QoE) compared to the indus-try reference player dash.js;

2. Our fast and low-overhead implementation FastMPC re-quires similar CPU usage and only 60 kB extra memoryusage comparing to other algorithms.

Contributions and roadmap: In summary, this paper makesthe following key contributions:1

• Development of a formal control-theoretic model of thebitrate adaptation problem (Section 3);• Design of a MPC approach that subsumes existing rate-

and buffer-based strategies (Section 4);• A practical and fast table enumeration based algorithm

FastMPC that near-optimally approximates the perfor-mance of an exact MPC approach (Section 5);• A low-overhead implementation based on the open source

reference video player dash.js (Section 6);• A systematic evaluation of different classes of algorithms

over a wide range of operating parameters and realistictraces (Section 7)

We begin by discussing background on DASH and relatedwork in the next section.

2 Background and Related WorkWe begin with a high-level overview of how HTTP-basedadaptive video streaming works, before describing the keyshortcomings of today’s state-of-art solutions.

Internet video technologies such as Microsoft Smooth-Streaming [13], Apple’s HLS [5], and Adobe’s HDS [2] relyon HTTP-based adaptive streaming. This class of protocolsis being standardized under the umbrella of Dynamic Adap-tive Streaming over HTTP or DASH [16]. In DASH systems,each video consists of multiple segments or “chunks” (cor-responding to a few seconds of play time) and each chunk isencoded at multiple discrete bitrates. The chunks from dif-ferent bitrate streams are aligned so that the video player canswitch to a different bitrate if necessary at a chunk boundary.This approach has several pragmatic advantages over cus-tom streaming protocols such as Real-Time Messaging Pro-tocol (RTMP). The use of HTTP enables providers to seam-lessly bypass middleboxes. Furthermore, it can use existingcommodity CDN servers without requiring custom modifi-cations. Finally, by making the server stateless, one canimplement better application-layer resilience using multipleservers and CDNs [41, 40].

Figure 1 shows an abstract model of the adaptive videoplayer. The player uses some inputs (e.g., buffer occupancyor estimates of the network throughput) in its decision logicto choose the bitrate level for the next chunk(s) to be down-loaded. In making this decision, there are many potentiallyconflicting QoE considerations a player must account for:(1) minimizing rebuffering events where the playback buffer1An early workshop version of the paper made the case fora MPC-based approach [50]. However, it did not provide aconcrete algorithm, a practical implementation, and evalua-tion using real throughput traces.

326

QoE

InternetInternet

Throughput

Predictor

Throughput

Predictor

Bitrate

Controller

Bitrate

ControllerHTTPHTTP

GET

Chunk

Buffer

Occupancy

Video Player

BufferBufferBuffer

End User

Bitrate

Throughput

Prediction

Figure 1: Abstract model of DASH players

is empty and cannot render the video; (2) delivering as higha playback bitrate as possible within the throughput con-straints; (3) minimizing startup delay so that the user doesnot quit while waiting for the video to load; and (4) keepingthe playback as smooth as possible by avoiding frequent orlarge bitrate jumps [24, 35].

To see why these objectives are conflicting, let us con-sider two extreme solutions. A trivial solution to minimizerebuffering and the startup delay would be to always pickthe lowest bitrate, but it conflicts with the goal of deliver-ing high bitrate. Conversely, picking the highest availablebitrate may lead to many rebuffering events. Similarly, thegoal of maintaining a smooth playback may also conflict ifthe optimal choice to simultaneously minimize rebufferingand maximizing average bitrate is to switch bitrates for ev-ery chunk.

The focus of this paper is on client-side adaptation solu-tions. Other complementary work includes the use of server-side bitrate switching (e.g., [37, 18]), TCP changes to avoidbursts (e.g., [27]), and in-network throughput managementand caching (e.g., [31, 45, 42]). We focus on the client-sideproblem for two key reasons. First, client-side solutions of-fer the most immediately deployable alternative in contrastto solutions that require in-network support (e.g., [31, 45,42]), server-side software changes (e.g., [37, 18]), or modi-fications to lower-layer transport protocols (e.g., [27, 28, 39,29, 36]). Second, the client is often in the best position toquickly detect performance issues and respond to dynam-ics. That said, we believe that the formal foundations andalgorithms we develop can be equally applied to these otherdeployment scenarios.

Many measurement studies have shown the poor perfor-mance of state-of-art video players with respect to these QoEmeasures (e.g., [46, 34, 32]). These studies show that mostproblems are not artifacts of specific players but manifestacross all state-of-art players such as SmoothStreaming [13],Netflix [11], Adobe OSMF [3], and Akamai HD [4]. Forbrevity we do not reproduce these results here but refer in-terested readers to prior work (e.g., [46, 34, 32]).

To alleviate these problems, there have been several recentproposals in the research literature (e.g., [47, 34, 18, 33, 38]).At a high level, these solutions can be roughly divided intotwo categories: (1) rate-based algorithms and (2) buffer-based algorithms. Video players with rate-based methodsessentially pick the highest possible bitrate based on the es-

timated available throughput. However, as shown in priorwork throughput estimation on top of HTTP suffers fromsignificant biases [32], which leads to problems with tradi-tional rate-based approaches. Some solutions try to workaround these biases by either smoothing out throughput esti-mates [47] or choosing better scheduling strategies [34]. Onthe other hand, recent work makes a case for buffer-based al-gorithms [33]. Rather than using throughput estimates, thisclass of algorithms uses buffer occupancy as the feedbacksignal, and designs mechanisms to keep the buffer occu-pancy at a desired level, essentially discarding any availablethroughput information.

Despite the broad interest in this topic, what is criticallylacking today is a principled understanding of bitrate adapta-tion algorithms. Each aforementioned solution offers pointheuristics that work under specific (and implicit) environ-mental assumptions. While each approach seen in isolationhas been shown to outperform commercial players, there islittle effort to systematically compare how different classesof algorithms stack up against each other or which of thesetechnical components are critical, or how robust these algo-rithms are across different operating regimes (e.g., through-put stability, buffer size, number of bitrate levels). Further-more, many of these algorithms even fail to formally statewhat objective they seek to optimize making it harder to con-duct a meaningful comparison.

Our first-order goal in this work is to bring some clarityto this space. Rather than design yet another point solution,we start by developing a first-principles approach via con-trol theory to develop a general framework to reason aboutclasses of algorithms. In the next section, we use this control-theoretic “lens” to formally define the stochastic optimiza-tion that video bitrate adaptation algorithms try to solve.

3 Control-Theoretic ModelIn this section, we develop a mathematical model of theHTTP video streaming process and formally define the bi-trate adaptation problem. This model gives us a frameworkto compare and evaluate existing algorithms and serves asthe foundation for potential improvements.

3.1 Video Streaming ModelWe model a video as a set of consecutive video segments orchunks, V = {1, 2, · · · ,K}, each of which contains L sec-onds of video. Each chunk is encoded at different bitrates.Let R be the set of all available bitrate levels. The videoplayer can choose to download chunk k at bitrate Rk ∈ R.Let dk(Rk) be the size of chunk k encoded at bitrate Rk. Inconstant bitrate (CBR) case, dk(Rk) = L × Rk, while invariable bitrate (VBR) case the dk ∼ Rk relationship candiffer across chunks.

The higher bitrate is selected, the higher video qualityis perceived by the user. Let q(·) : R → R+ be a non-decreasing function which maps selected bitrate Rk to videoquality perceived by user q(Rk). Note that q(·) may dependon the video-playing device as well as the content of thevideo. For example, while on HDTV 3Mbps and 1Mbpsmay lead to significant difference in user experience, the

327

TimeBu

ffe

r O

ccu

pa

ncy

𝐵𝑘

𝐵𝑘+1

𝑡𝑘+1𝑡𝑘Start chunk k

Rebuffer

Start chunk k+1

Download & Wait

𝑑𝑘(𝑅𝑘)

𝐶𝑘+ Δ𝑡𝑘

0

Figure 2: Illustration of buffer dynamics

video quality in 3Mbps and 1Mbps may be similar on a mo-bile device; Also, improving the bitrate of “dynamic” chunkswill result in more QoE gain than improving “static” chunks.

The video segments are downloaded into a playback buffer,which contains downloaded but as yet unviewed video. LetB(t) ∈ [0, Bmax] be the buffer occupancy at time t, i.e.,the play time of the video left in the buffer. The buffer sizeBmax depends on the policy of the service provider, as wellas storage limitations on the player. A typical player buffermay hold few tens of seconds of video segments.

Figure 2 helps illustrate the conceptual operation of thevideo player. At time tk, the video player starts to down-load chunk k. The download time for this chunk will bedk(Rk)/Ck; i.e., it depends on the size of selected chunkwith bitrate Rk, as well as average download speed Ck ex-perienced during this download process. Once chunk k iscompletely downloaded, the video player waits for ∆tk andstarts to download the next chunk k+ 1 at time tk+1. We as-sume that the waiting time ∆tk is small and will not lead torebuffering events. If we denote by Ct the network through-put at time t, then we have:

tk+1 = tk +dk(Rk)

Ck+ ∆tk (1)

Ck =1

tk+1 − tk −∆tk

∫ tk+1−∆tk

tk

Ct dt. (2)

The buffer occupancy B(t) evolves as the chunks are be-ing downloaded and the video is being played. Specifically,the buffer occupancy increases by L seconds after chunk kis downloaded and decreases as the user watches the video.2

Let Bk = B(tk) denote the buffer occupancy when theplayer starts to download chunk k. The buffer dynamics canthen be formulated as:

Bk+1 =

((Bk −

dk(Rk)

Ck

)+

+ L−∆tk

)+

(3)

Here, the notation (x)+ = max{x, 0} ensures that the termcan never be negative. Note that if Bk < dk(Rk)/Ck, thebuffer becomes empty while the video player is still down-loading chunk k, leading to rebuffer events as shown in Fig-ure 2.2The “startup” phase will be slightly different as the playerwaits for some amount of buffer to build up before drainingthe buffer.

The determination of waiting time ∆tk, also referred aschunk scheduling problem, is an equally interesting and im-portant problem in improving fairness of multi-player videostreaming [34]. However, in this paper we assume that theplayer immediately starts to download chunk k + 1 as soonas chunk k is downloaded. The one exception is when thebuffer is full, the player waits for the buffer to reduce to alevel which allows chunk k to be appended. Formally,

∆tk =

((Bk −

dk(Rk)

Ck

)+

+ L−Bmax

)+

(4)

3.2 QoE Maximization ProblemThe ultimate goal of bitrate adaptation is to improve the QoEof users in order to achieve higher long-term user engage-ment [24]. Our goal is to provide a flexible QoE model ratherthan a fixed notion of QoE as this is an active area of research[19]. While users may differ in their specific QoE functions,we can enumerate the key elements of video QoE as:1. Average Video Quality: The average per-chunk quality

over all chunks: 1K

∑Kk=1 q(Rk);

2. Average Quality Variations: This tracks the magnitudeof the changes in the quality from one chunk to another:

1K−1

∑K−1k=1 |q(Rk+1)− q(Rk)|;

3. Rebuffer: For each chunk k rebuffering occurs if the down-load time dk(Rk)/Ck is higher than the playout bufferlevel when the chunk download started (i.e., Bk). Thusthe total rebuffer time 3 is

∑Kk=1

(dk(Rk)

Ck−Bk

)+

.

4. Startup Delay Ts, assuming Ts � Bmax.As users may have different preferences on which of the

four components is more important, we define the QoE ofvideo segment 1 through K by a weighted sum of the afore-mentioned components:

QoEK1 =

K∑k=1

q(Rk)− λK−1∑k=1

|q(Rk+1)− q(Rk)|

− µK∑

k=1

(dk(Rk)

Ck−Bk

)+

− µsTs (5)

Here λ, µ, µs are non-negative weighting parameters cor-responding to video quality variations, rebuffering time andstartup delay, respectively. A relatively small λ indicatesthat the user is not particularly concerned about video qualityvariability; the large λ is, the more effort is made to achievesmoother changes of video quality. A large µ, relatively tothe other parameters, indicates that a user is deeply con-cerned about rebuffering. In cases where users prefer lowstartup delay, we employ a large µs.

In summary, this definition of QoE is quite general as it al-lows us to model varying user preferences on different con-tributing factors.

3Alternatively, one can also consider the number of rebuffer-ing events formulated as

∑Kk=1 1

(dk(Rk)

Ck> Bk

).

328

maxR1,··· ,RK ,Ts

QoEK1 (6)

s.t. tk+1 = tk +dk(Rk)

Ck+ ∆tk, (7)

Ck =1

tk+1 − tk −∆tk

∫ tk+1−∆tk

tk

Ct dt, (8)

Bk+1 =

((Bk −

dk(Rk)

Ck

)+

+ L−∆tk

)+

, (9)

B1 = Ts, Bk ∈ [0, Bmax] (10)Rk ∈ R, ∀k = 1, · · · ,K. (11)

Figure 3: Formulation for QoE maximization(QOE_MAXK

1 ) subject to buffer and throughputdynamics.

QoE maximization problem: We are now ready to formu-late the problem of bitrate adaptation for QoE maximizationas in Figure 3, denoted as QOE_MAXK

1 . Given through-put trace {Ct, t ∈ [t1, tK+1]} as input, the optimization pro-vides the following as output: 1) bitrate decisions R1,· · · ,RK , and 2) startup time Ts.

Note that the problem QOE_MAXK1 is formulated as-

suming the video playback has not started at the time of thisoptimization so the start-up delay Ts is a decision variable.However, this QoE maximization can also take place duringvideo playback at time tk0 when the next chunk to downloadis k0 and the current buffer occupancy is Bk0 . In this case,we can drop the variable Ts and denote the correspondingsteady state problem as QOE_MAX _STEADYK

k0.

3.3 Classes of AlgorithmsIn this section we characterize problem QOE_MAXK

1 anddescribe existing bitrate adaptation algorithms within thisframework to understand how they relate to one another.

The problem in Figure 3 is a finite-horizon stochastic op-timal control problem. The source of randomness is in theavailable throughput Ct. At time tk when the player choosesbitrate Rk, only the past throughput {Ct, t ≤ tk} is avail-able, while the future values {Ct, t > tk} are not known.

However, a throughput predictor can be used to obtainpredictions defined as {Ct, t > tk}. Based on such predic-tion and on buffer occupancy information (which is insteadknown precisely), the bitrate controller selects bitrate of thenext chunk k:

Rk = f(Bk, {Ct, t > tk}, {Ri, i < k}

). (12)

The design of effective throughput predictors is an inter-esting research direction in its own right. In this paper, wefocus on bitrate adaptation algorithms only and assume thatpredictors are given to us and are characterized in terms oftheir expected prediction errors. Namely, we focus on thedesign of f(·) and on the effect of the prediction error onthe performance of the compared control algorithms. In thefollowing sections, we will systematically evaluate how dif-

Buffer-based

Rate-based

Bitrate

Throughput

prediction

Buffer

occupancy

A1

A2A3?

Design space of

all algorithms

Figure 4: Design space of algorithms for the video adap-tation problem: Most current approaches choose the bi-trate as a function of only one variable; e.g., A1 is rate-based (RB) while A2 is buffer-based (BB).

ferent algorithms perform with a state-of-art predictor undera variety of variability conditions.

Now, different adaptation algorithms essentially adopt dif-ferent functions f(·). Specifically, two main categories of al-gorithms appear in the literature: rate-based (RB) and buffer-based (BB) algorithms. RB strategies essentially choose bi-trate only based on throughput prediction, i.e.,

Rk = f({Ct, t > tk}, {Ri, i < k}

). (13)

For example, a typical RB strategy is to choose the maxi-mum possible bitrate below the predicted throughput.

On the other hand, BB strategies advocate decision mak-ing based only on buffer occupancy, namely:

Rk = f (Bk, {Ri, i < k}) , (14)

while regarding throughput variations as unmodeled distur-bances. For example, Huang et al., illustrate one roadmapfor designing BB algorithms [33].

Note, however, that both classes of algorithms are dis-carding possibly useful information as shown in Figure 4.Consequently, both are in principle suboptimal. Ideally, wewant to use both buffer occupancy and throughput predic-tion, thereby considering a broader design space of bitrateadaptation strategies, as shown in Eq (12) and algorithm A3depicted in Figure 4.

4 Model Predictive Control Approachfor Optimal Bitrate Adaptation

In this section, we make a case for a Model Predictive Con-trol (MPC) approach for bitrate adaptation and describe aconcrete MPC-based workflow that can optimally combinethroughput prediction and buffer occupancy. We also de-velop a robust MPC approach that can better handle errorsin throughput prediction under highly variable network con-ditions.

4.1 Why MPC?First, we provide the intuition behind the choice of MPC inour setting. Note that we cannot claim that MPC is necessaryor the optimal choice in the space of all possible control al-gorithms. Our goal is merely to argue that MPC is a naturalfit for the bitrate adaptation problem.

329

Strawman solutions: As we saw before, bitrate adaptationis essentially a stochastic optimal control problem. In thisrespect, there are two candidate well-known control algo-rithms: (1) Proportional-integral-derivative (PID) control [25]and (2) Markov Decision Process (MDP) based control [21].While PID is computationally simpler compared to MPC,it can only serve to stabilize the system and cannot explic-itly optimize our QoE objective. In addition, PID control isdesigned to work in continuous time and state space and us-ing it in a highly discrete system such as ours may result inperformance degradation or instability [25]. Alternatively,with MDP we could consider formulating the throughputand buffer state transition as Markov processes, and findthe optimal control policy using standard algorithms such asvalue iteration or policy iteration [21]. However, this has astrong assumption that throughput dynamics follow Markovprocesses and it is unclear if this holds in practice. We re-gard the potential use of MDP and analysis of the throughputdynamics as future work (see Section 8).

Case for MPC: Ideally, given perfect knowledge of futurethroughput over the entire horizon of a video [t1, tK+1], theoptimal bitrate R1, · · · , RK and startup delay Ts can be cal-culated in one shot by solving the optimization problem forthe entire video QOE_MAXK

1 . In practice, such perfectinformation is not available, making it difficult to find suchoptimal solutions using offline optimization.

While perfect information may not be available for the en-tire future, it is possible that reasonably accurate throughputprediction can be instead obtained for a short horizon to thefuture [tk, tk+N ]. The intuition here is that network condi-tions are reasonably stable on short timescales and usuallydo not change drastically during a short horizon (tens of sec-onds) [51]. Based on this insight, we can run a QoE opti-mization using the prediction in this horizon, apply the firstbitrateRk, and move the horizon forward to [tk+1, tk+N+1].This scheme is known as model predictive control (MPC) orreceding horizon control [22]. MPC algorithms are widelyused in different domains, ranging from industrial control tonavigation. The general benefits of MPC are in that MPCcan utilize predictions to optimize a complex control objec-tive online in a dynamical system under constraints.

4.2 Basic MPC AlgorithmAlgorithm 1 shows a high-level overview of the workflow ofMPC for bitrate adaptation. In our context, the algorithmessentially chooses bitrate Rk by looking N steps ahead(i.e., the moving horizon), and solves a specific QoE max-imization problem (this depends on whether the player is insteady or startup phase) with throughput predictions {Ct, t ∈[tk, tk+N ]}, or C[tk,tk+N ]. The first bitrate Rk is applied byusing feedback information and the optimization process isiterated at each step k.

At iteration k, the player maintains a moving horizon fromchunk k to k+N −1 and carries out the following three keysteps, as shown in Algorithm 1.

1. Predict: Predict throughput C[tk,tk+N ] for the next Nchunks using some throughput predictor. Our goal in this

Algorithm 1 Video adaptation workflow using MPC

1: Initialize2: for k = 1 to K do3: if player is in startup phase then4: C[tk,tk+N ]= ThroughputPred(C[t1,tk])

5: [Rk, Ts] = fstmpc

(Rk−1, Bk, C[tk,tk+N ]

)6: Start playback after Ts seconds7: else if playback has started then8: C[tk,tk+N ]= ThroughputPred(C[t1,tk])

9: Rk = fmpc

(Rk−1, Bk, C[tk,tk+N ]

)10: end if11: Download chunk k with bitrate Rk, wait till fin-

ished12: end for

paper is not to design a prediction mechanism but to relyon existing approaches. Naturally, improving the accu-racy of this prediction will improve the gains achievedvia MPC. That said, MPC can be extended to be robustto errors as we discuss below.

2. Optimize: This is the core of the MPC algorithm: Giventhe current buffer occupancy Bk, previous bitrate Rk−1

and throughput prediction C[tk,tk+N ], find optimal bitrate

Rk. In steady state,Rk = fmpc

(Rk−1, Bk, C[tk,tk+N ]

),

implemented by solving QOE_MAX _STEADY k+N−1k .

In the start-up phase, it also optimizes start-up time Ts as[Rk, Ts] = fstmpc

(Rk−1, Bk, C[tk,tk+N ]

), implemented

by solving QOE_MAX k+N−1k . If we ignore practical

details about computational overhead, we can simply useoff-the-shelf solvers such as CPLEX to solve these dis-crete optimization problems. As we will see in Section 5,we do not need to explicitly solve the optimization prob-lem within the video player in practice.

3. Apply: Start to download chunk k with Rk and move thehorizon forward. If the player is in start-up phase, waitfor Ts before starting playback.

This workflow has several qualitative advantages comparedwith buffer-based (BB), rate-based (RB) as we discuss be-low. First, this MPC algorithm uses both throughput pre-diction and buffer information in a principled way. Second,compared to pure RB approaches, MPC smooths out predic-tion error at each step and is more robust to prediction er-rors. Specifically, by optimizing several chunks over a mov-ing horizon, large prediction errors for one particular chunkwill have lower impact on the performance. Third, MPCdirectly optimizes a formally defined QoE objective, whilein RB and BB the tradeoff between different QoE factors isnot clearly defined and therefore can only be addressed in anad hoc qualitative manner.

4.3 Robust MPCThe basic MPC algorithm assumes the existence of an ac-curate throughput predictor. However, in certain severe net-

330

work conditions, e.g., in cellular networks or in prime timewhen the Internet is congested, such accurate predictors maynot be available. For example, if the predictor consistentlyoverestimates the throughput, it may induce high rebuffer-ing. To counteract the prediction error, we develop a robustMPC algorithm.

Robust MPC essentially optimizes the worst-case QoE as-suming that the actual throughput can take any value in arange [Ct, Ct] in contrast to a point estimate Ct. RobustMPC entails solving the following optimization problem attime tk to get bitrate Rk = frobustmpc(Rk−1, Bk, [Ct, Ct]):

maxRk,··· ,Rk+N−1

minCt∈[Ct,Ct]

QoEk+N−1k (15)

s.t. Constraints (7) to (11) (16)

In general, it may be non-trivial to solve such a max-minrobust optimization problem. In our specific case, however,we can prove that the worst case scenario takes place whenthe throughput is at its lower bound Ct = Ct. Thus, theimplementation of robust MPC is straightforward. Instead ofCt, we use the lowest possible Ct as the input to the regularMPC QoE maximization problem. Formally,

THEOREM 1. The robust MPC controller is equivalent tothe regular MPC taking the lower bound of throughput asinput, namely,

Rk = frobustmpc(Rk−1, Bk, [Ct, Ct])

= fmpc(Rk−1, Bk, Ct)

PROOF SKETCH. Conceptually, QoE functionQoE(R,C)can be written as the sum of 3 terms (g1: total video quality,g2: total quality change, g3: rebuffer time), in which onlythe rebuffer time term depends on throughput C. Thus,

maxR

minC∈[C,C]

QoE(R,C)

≡maxR

(g1(R)− λ× g2(R)− max

C∈[C,C]µ× g3(R,C)

)≡max

RQoE(R,C)

As any decrease of throughput C will lead to longer re-buffer time, the minimum QoE is achieved at C = C.

The one potential downside is that robust MPC is moreconservative than regular MPC by always assuming the low-est throughput. The degree of conservativeness here natu-rally depends on how loose/tight the lower bound is. Inpractice, we use maximum prediction error over the past sev-eral chunks as bounds in our implementation and find that itworks well in practice (discussed in Section 7).

5 Using MPC in Practice — FastMPCWhile rate-based and buffer-based algorithms need relativelyminor computations, the challenge with MPC is that we needto solve a discrete optimization problem at each time step.There are two practical concerns here:

CPLEX

Offline Enumeration

CPLEX CPLEX

…

Scenario BufferLevel PrevBitrate Throughput Optimal Bitrate

1 1s 350kbps 350kbps 350kbps

2 2s 350kbps 600kbps 600kbps

… … … … …

50,000 20s 3000kbps 3000kbps 3000kbps

Query Lookup

BufferLevel 1s

PrevBitrate 350kbps

Throughput 350kbps

BufferLevel 2s

PrevBitrate 350kbps

Throughput 600kbps

BufferLevel 20s

PrevBitrate 3000kbps

Throughput 3000kbps

…

Online Bitrate Adaptation

Figure 5: “FastMPC” idea: We enumerate possible sce-narios and create a table indexing the optimal decisionfor each scenario.

• Computational overhead: First, the high computationaloverhead of MPC is especially problematic for low-endmobile devices, which are projected to be the dominantvideo consumers going forward. Since the bitrate adap-tation decision logic is called before the player starts todownload each chunk, excessive delay in the bitrate adap-tation logic will negatively affect the QoE of the player.• Deployment: Since we do not have a closed-form or com-

binatorial solution for the QoE maximization problem,we will need to use a solver (e.g., CPLEX or Gurobi).However, it may not be possible for video players to bebundled with such solver capabilities; e.g., licensing is-sues may preclude distributing such software or it mayrequire additional plugin or software installations whichposes significant barriers to adoption [26].

From the above discussion, it is evident that the solutionwe develop should be lightweight and combinatorial (i.e.,not solving a LP or ILP online). As such, in this section, weaddress these two key practical issues by developing a fastand low-overhead FastMPC design that does not require anyexplicit solver capabilities in the video player [48].

5.1 High-Level Idea of FastMPCAt a high level, FastMPC algorithms essentially follow atable enumeration approach. Here, we do an offline stepof enumerating the state-space and solve each specific in-stance. Then, in the online step we just use these stored op-timal control decisions mapped to the current operation con-ditions. That is, the algorithm will be reduced to a simpletable lookup indexed by the key value closest to the currentstate and the output of the lookup is the optimal solution forthe selected configuration.

In our setting (Figure 5), the state-space is determined bythe following dimensions: (1) current buffer level, (2) previ-ous bitrates chosen, and (3) the predicted throughput for thenext N chunks (i.e., the planning horizon). Thus, FastMPCwill entail enumerating potential scenarios capturing differ-

331

ent values for each dimension and solving the optimizationproblems offline.

Unfortunately, directly using this idea will be very inef-ficient as we have a high dimensional state space. For in-stance, if we have 100 possible values for the buffer level,10 possible bitrates, a horizon of size 5, and 1000 possi-ble throughput values, there will be 1018 rows in the table!4

There are two obvious consequences of this large state space.First, it may not be practical to explicitly store the full tablein the memory. Note that this is not just a hypothetical con-cern. If we need a practical implementation of this tablelookup in the dash.js player [1] it will mean very highmemory footprint along with large startup delay as the ta-ble needs to be downloaded to the player module. Second,it will incur a non-trivial offline computation cost that mayneed to be rerun as the operating conditions change.

5.2 Optimizing FastMPC PerformanceNext, we present two key optimizations to make the tableenumeration approach tractable.

Compaction via binning: First, to address the offline ex-ploration cost, our insight is that we may not need very fine-grained values for the buffer and the throughput levels. Asa consequence these values may be suitably coarsened intoaggregate bins. Moreover, with binning we do not needto explicitly store the row keys as these are directly com-puted from the bin row indices. The challenge here is tobalance the granularity of binning and the loss of optimalityin practice. In practice, we find that using 100 bins for bufferlevel and 100 bins for throughput predictions works well andyields near-optimal performance.

Table compression: Our second insight is that the decisiontable learned by the offline computation will have signifi-cant structure. Specifically, the optimal solutions for severalsimilar scenarios will likely be the same. Thus, we can ex-ploit this structure in conjunction with the binning strategy toexplore a simple lossless compression strategy using a run-length encoding to store the decision vector. The optimaldecision can then be retrieved online using binary search.In practice, we see that with compression the table occupiesless than 60 kB with 100 bins for buffer levels, 100 bins forthroughput predictions and 5 bitrate levels.

6 ImplementationIn this section, we describe our implementation of the MPCapproach in the dash.js framework. Our implementationis based on the dash.js master branch (v1.2.0 release) asit was the stable version at the time of development. We be-lieve that our implementation can be easily adapted to futureversions as we require minimal modifications (≈ 800 linesof JavaScript). For more information on the source code anddemo please visit our demo page [14].

Choice of player: Many prior adaptive bitrate players wereprototyped using the Adobe OSMF framework [34, 3, 12]4100 buffer levels × 10 bitrates × 1000 throughput 1 values× · · ·× 1000 throughput 5 values = 1018 entries.

and this seemed a natural choice. However, our conversa-tions with industry personnel revealed that almost all con-tent providers are switching to HTML5-based players basedon the MPEG-DASH standard [16] and thus OSMF (basedon Flash and with decreasing market share) is unlikely to bea platform with real-world impact. Having chosen a DASHplayer, we qualitatively evaluated several implementationsof the DASH standard (e.g., [23, 8, 43]). Unfortunately,these rely either on custom clients or niche video player plat-forms. Given these considerations, we chose the dash.jsframework as it is the reference open-source implementationfor the MPEG-DASH standard and is actively supported byleading industry participants [7]. We believe our prototypeefforts will also inform the evolution of these standardizationefforts. For instance, a key requirement for any control algo-rithms is to know the size (in bytes) of each video chunk, butthe standard does not mandate the manifest to report chunksizes, which may be a key shortcoming of the current speci-fication.

dash.js overview: To understand our implementation andmodifications, we begin with some brief background on thearchitecture of the dash.js player. The key componentsare highlighted in Figure 6.

At a high level, the dash.js implementation separateshigh-level video streaming functionalities from low-level spe-cific DASH standard related components. As we are not par-ticularly interested in standard-specific implementation, weleave the code unmodified and only focus on the adaptivestreaming related functions.

The classes and functions that are key to bitrate adaptationand video streaming logic are as follows:• BufferController: This class provides functions to

manage buffer levels of the player by requesting new seg-ments and making bitrate change decisions. Specifically,function validate is periodically invoked and callsgetPlaybackQuality function in AbrControllerclass to find optimal bitrate. It also maintains a variablebufferLevel to record the current buffer occupancyof the player, which can be used for bitrate decisions.• AbrController: This class contains the core bitrate

adaptation logic. In the original dash.js implementa-tion, a rule-based decision logic is employed to find thebitrate. Specifically, DownloadRatioRule selects bi-trate based on the “download ratio” (play time of lastchunk divided by its download time); On the other hand,InsufficientBufferRule chooses bitrate depend-ing on whether the buffer level has reached a lower limitrecently to avoid rebuffers. Priorities are assigned to eachrule to resolve conflicts and make final bitrate decisions.

Modifications and extensions: We observed two imple-mentation details in dash.js that were problematic. First,the code periodically calls the validate function to checkthe status of the buffer and call functions in AbrControllerto decide if the current bitrate should be changed. Notethat this implies the bitrate decisions are not always madeat chunk boundaries, which may lead to delay of executionof bitrate decisions, or even redownloading previous chunks.

332

BufferController

validate

AbrController

getPlaybackQuality

Rule-Based

Decision Logic

FastMPClogging

RB, BB, FESTIVE

ThroughputPredictor

Original dash.js Additional class/function

Figure 6: dash.js code structure and our modifications

Second, the dash.js downloads multiple chunks in paral-lel even though chunks that are earlier in the video streamshould ideally be prioritized.

To address these concerns, we changed the bitrate de-cision and chunk download process in dash.js code bymaking two key changes to BufferController class:1) bitrate decisions are made at the start of each chunk, 2)chunk download is completely sequential, i.e., no concur-rent downloads of multiple chunks are allowed. This allowsa basic implementation framework which is consistent withour model and other proposed algorithms.

With these fixes, we implemented different bitrate adap-tation algorithms (e.g., FastMPC, BB, RB) by replacing theoriginal rule-based bitrate adaptation logic by our own im-plementation. The FastMPC implementation has a static ta-ble that is used to index control decisions. We also imple-mented a harmonic mean based throughput prediction schemebased on prior work [34], as well as additional logging func-tions in the BufferController class to record a com-plete log of the state of the player, including buffer level,bitrates, rebuffer time, predicted/actual throughput.

7 EvaluationIn this section, we compare our approach against existingrate- and buffer-based approaches using a combination ofreal player and simulation experiments. We also present mi-crobenchmarks on the CPU and memory overhead of ourFastMPC implementation.

7.1 SetupWe begin by describing key parameters: (1) throughput vari-ability traces; (2) video-specific parameters; (3) configura-tions for various adaptation algorithms; and (4) definition ofa normalized QoE metric that we use throughout this section.

7.1.1 Input Parameters

Throughput traces: Our goal is to evaluate various bitrateadaptation approaches using realistic network variability con-ditions. Given the paucity of large-scale sustained through-put measurements over several tens of seconds, however, weuse a combination of existing datasets and synthetic models:1. Broadband dataset (FCC) [9]: The FCC dataset consists

of more than 1 million sets of throughput measurements,where each set contains six data points each represent-ing average throughput during a 5s interval. We extractthroughput traces of the same server and client IP addressand concatenate these to match the length of the video.For experiments we randomly pick 1000 of the concate-nated traces whose average throughput is between 0 to

3Mbps, to avoid trivial cases where picking the maxi-mum bitrate is always the optimal solution.

2. Mobile dataset (HSDPA) [10]: The HSDPA dataset con-sists of 30min of continuous 1s measurement of videostreaming throughput of a moving device in Telenor’s3G/HSDPA mobile wireless network in Norway. We ran-domly pick 1000 throughput traces from the full dataset.

3. Synthetic dataset: Finally we also use a synthetic datasetto supplement the aforementioned datasets. The through-put is based on some hidden state St ∈ S modelingthe number of users sharing a bottleneck link. The ac-tual throughput Ct follows a Gaussian distribution withmeanms and variance σ2

s , given the value of hidden stateSt = s. We vary both the state transition probability ma-trix as well as the parameters ms, σ2

s to generate traces.Figure 7 shows the throughput characteristics of all three

datasets. Among three datasets, throughput is the most sta-ble in broadband network and the most variable in mobilenetwork. In other words, the HSPDA dataset is a good stresstest for our MPC approach that assumes the throughput ispredictable on short timescales.

Video parameters: We use the “Envivio” video from DASH-264 JavaScript reference client test page [6] which is 260slong, consisting of 65 4s chunks. The video is encoded byH.264/MPEG-4 AVC codec in the following bitrate levels:R = {350kbps, 600kbps, 1000kbps, 2000kbps, 3000kbps}.This is consistent with the requirement for YouTube videobitrate levels for 240p, 360p, 480p, 720p and 1080p respec-tively [15]. We set the buffer size to Bmax = 30s. We as-sume q(·) is an identity function. As a default QoE function,we use the weights λ = 1, µ = µs = 3000, meaning 1-secrebuffer/start-up time receives the same penalty as reducingthe bitrate of a chunk by 3000 kbps. We also run sensitivityexperiments that vary the QoE weights.

7.1.2 Algorithms and Metrics

Adaptation algorithms: Determining the optimal algorithmwithin each class is difficult as it involves optimizing overan infinite-dimensional functional space. To this end, wechoose a widely adopted function form for each class ofalgorithms from prior work, and optimize the free param-eters by empirical simulations based on a training datasetcontaining 100 throughput traces randomly picked across alldatasets. We evaluate the following algorithms:1. RB: The bitrate is picked as the maximum available bi-

trate which is less than p = 1 times throughput predictionusing harmonic mean of past 5 chunks;

2. BB: We employ the function suggested by Huang et al [33],where bitrate Rk is chosen to be the maximum avail-able bitrate which is less than rk = f(Bk) with reservoirr = 5s and cushion c = 10s.

3. FastMPC: We use a look-ahead horizon h = 5 withthroughput predictions using harmonic mean of past 5chunks; We use 100 bins for throughput prediction and100 bins for buffer level. We also evaluate the exact MPCwith perfect throughput prediction for the next 5 chunksin simulations (denoted as MPC-OPT).

333

0 1000 2000 3000 4000 50000

0.2

0.4

0.6

0.8

1

Mean Throughput (kbps)

CD

F

FCCHSDPASynthetic

0 500 1000 1500 20000

0.2

0.4

0.6

0.8

1

Standard Deviation of Throughput (kbps)

CD

F

FCCHSDPASynthetic

−0.1 0 0.1 0.2 0.3 0.40

0.2

0.4

0.6

0.8

1

Average Percentage Prediction Error

CD

F

FCCHSDPASynthetic

Figure 7: Characteristics of datasets

−0.5 0 0.5 10

0.2

0.4

0.6

0.8

1

Normalized QoE

CD

F

RBBBFastMPCRobustMPCdash.jsFESTIVE

(a) FCC dataset

−0.5 0 0.5 10

0.2

0.4

0.6

0.8

1

Normalized QoE

CD

F

RBBBFastMPCRobustMPCdash.jsFESTIVE

(b) HSDPA dataset

−0.5 0 0.5 10

0.2

0.4

0.6

0.8

1

Normalized QoE

CD

F

RBBBFastMPCRobustMPCdash.jsFESTIVE

(c) Synthetic dataset

Figure 8: Real experiment results with different throughput traces

4. RobustMPC: We assume that the throughput lower boundis Ct = Ct/(1 + err), where Ct is obtained using har-monic mean of past 5 chunks, while prediction error erris the maximum absolute percentage error of the past 5chunks.

5. dash.js: The original implementation adopts a rule-based bitrate decision logic as shown in Section 6. Wekeep the original bitrate adaptation logic unmodified, butdisable the multi-chunk downloading and allow the bi-trate to switch only at chunk boundaries.5

6. FESTIVE [34]: This rate-based algorithm balances bothefficiency and stability, and incorporates fairness acrossplayers but that is not a concern in this paper. We assumethere is no wait time between consecutive chunk down-loads, and implement FESTIVE without the randomizedchunk scheduling. Note that this does not negatively im-pact the player QoE in single player case. Specifically,FESTIVE calculates the efficiency score depending onp = 1 times throughput predictions using harmonic meanof past 5 chunks, as well as a stability score as a functionof the bitrate switches in the past 5 chunks. The bitrateis chosen to minimize stability score plus α = 12 timesefficiency score.

Throughput predictor: Note that RB, *-MPC, and FES-TIVE need a good throughput predictor. Developing goodpredictors for different scenarios is outside the scope of thepaper. Building on insights from prior work, we use the har-monic mean of the observed throughput of the last 5 chunksbecause it is robust to outliers in per-chunk estimates [34].We revisit this issue in Section 8.5This enables a consistent comparison of the algorithmsrather than conflate it with other artifacts because of paral-lel downloads. We also tested the original dash.js with-out any modification, but its performance is worse than ourmodified version (not shown).

Normalized QoE metric: We define a normalized QoE met-ric as follows. For a given throughput trace {Ct, t ∈ [t1, tK+1]},the offline optimal QoE, denoted byQoE(OPT ), is the max-imum QoE that can be achieved with perfect knowledge offuture throughputs over the entire horizon. It can be cal-culated by solving problem QOE_MAXK

16 and provides

a theoretical upper bound of achievable QoE. On the otherhand, a real online algorithm A selects bitrate Rk based oncurrent throughput predictions {Ct, t > tk} without know-ing the entire future. We denote the online QoE achieved byalgorithmA byQoE(A) and define normalized QoE of A (n-QoE(A)) for an algorithm A as: n-QoE(A) = QoE(A)

QoE(OPT ) .

7.2 Real Player EvaluationFirst, we present emulations with the real player setup com-paring our FastMPC approach against several prior approaches.Our basic experiment setup consists of two computers (Ubuntu12.04 LTS) with a 100Mbps direct network connection emu-lating a video client and server. The video client is a Google-Chrome web browser for linux (version 39) with V8 JavaScriptengine while the video server is a simple HTTP server basedon node.js (version 0.10.32). We use the linux tc toolto throttle the throughput of the link between two computersaccording to the throughput traces employed. We use Emu-lab [49] to carry out several such experiments in parallel.

Figure 8 show the CDF of normalized QoE over the threesets of throughput traces. First, we see that existing algo-rithms achieve only 60-70% of optimal QoE confirming thatthere is still large room to improve video QoE. Second, Ro-bustMPC outperforms non-MPC algorithms in all datasetswith an improvement in median normalized QoE of 15%,10%, and 5% in the FCC, HSDPA, and Synthetic datasets6To make it tractable to compute this offline optimal,we assume it can pick bitrates from a continuous range[Rmin, Rmax].

334

0 500 1000 1500 2000 2500 30000

0.2

0.4

0.6

0.8

1

Average Bitrate (kbps)

CD

F

0 500 1000 15000

0.2

0.4

0.6

0.8

1

Average Bitrate Change (kbps/chunk)

CD

F

0 5 10 15 20 25 300

0.2

0.4

0.6

0.8

1

Total Rebuffer Time (s)

CD

F

RBBBFastMPCRobustMPCdash.jsFESTIVE

Figure 9: Detailed performance for FCC dataset

0 500 1000 1500 2000 2500 30000

0.2

0.4

0.6

0.8

1

Average Bitrate (kbps)

CD

F

0 500 1000 15000

0.2

0.4

0.6

0.8

1

Average Bitrate Change (kbps/chunk)

CD

F

0 5 10 15 20 25 300

0.2

0.4

0.6

0.8

1

Total Rebuffer Time (s)

CD

F

RBBBFastMPCRobustMPCdash.jsFESTIVE

Figure 10: Detailed performance for HSDPA dataset

respectively. Third, we see significant improvement (60+%median normalized QoE) compared with the original dash.jsplayer. Finally, we see that the basic FastMPC is more sen-sitive to prediction errors than RobustMPC. While there isno difference between Fast- and RobustMPC on FCC andSynthetic results, the difference is especially visible in theHSPDA result where regular FastMPC suffers and presentsno gains versus RB and BB.

To better understand the impact of prediction error, Fig-ure 7 shows the CDF of per-session average percentage pre-diction errors for the datasets. In FCC dataset, the averageerror of our harmonic mean throughput predictor is less than5%, while in HSPDA dataset, the worst-case prediction er-ror can be as high as 40%. We also observe that the predictorover-estimates the true throughput for more than 20% of thetime in HSPDA dataset which leads to significant rebuffer-ing. As such, inaccurate prediction can ruin the decisionmaking of regular FastMPC, while RobustMPC is less af-fected as it incorporates prediction error to avoid choosingbitrate too aggressively when predictions are inaccurate.

The earlier normalized QoE result shows the aggregatecombination of different QoE factors. Next, we zoom in onthe individual quality factors to explain the QoE improve-ments in Figures 9 and 10. In the FCC dataset, all algo-rithms achieve similarly low rebuffer time as throughput ispredictable. The performance difference essentially stemsfrom reducing unnecessary bitrate switches. RobustMPC,FastMPC and BB achieve similar average bitrates, but Ro-bustMPC uses fewer bitrate switches. In the HSPDA re-sult, rebuffer time becomes a more important issue. WhileFastMPC achieves similar average bitrate and fewer switchescomparing to BB, it suffers from large rebuffer time. On theother hand, RobustMPC achieves significant less rebuffertime but at a slightly lower average bitrate: Zero rebufferin 65% of all cases, versus 40% for BB and FastMPC. Asa result, RobustMPC still outperforms other algorithms inoverall QoE.

Doing a cross-dataset analysis, we see that the tail distri-butions of the overall QoE show different characteristics. Inthe FCC result, only 1% users experience normalized QoE<0 while in HSPDA this occurs in 10% of all cases.7 Again,the main reason is that the high variability of mobile networkinduces long rebuffering which affects the overall QoE.

Finally, even though FESTIVE is a rate-based algorithm,it performs slightly worse than regular RB in our datasetsbecause it puts a higher weight on stability and switches upbitrate slowly even when the available throughput is increas-ing.8 On the other hand, the dash.js heuristic rule-basedadaptation achieves low rebuffer time, but incurs many un-necessary switches. Thus, its overall QoE is significantlyworse than all algorithms.

7.3 Sensitivity AnalysisFor sensitivity analysis we evaluate different algorithms us-ing a custom simulation framework. As before, the simula-tion takes as input a throughput trace and models the videodownload/playback process and the buffer dynamics. Attime tk when the bitrate of chunk k is needed, the simula-tion calls the bitrate controller embedded with different al-gorithms to get Rk. Using this framework, we study thesensitivity of the approaches to key factors such as: (1) pre-diction error, (2) choice of QoE function, (3) playout buffersize, (4) number of bitrate levels, and (5) startup delay.Throughput prediction: Here, we want to study the impactof prediction error of general predictors rather than analyzea particular one (e.g., harmonic mean). To this end, we usethe average error level to characterize the performance of athroughput predictor and model the prediction output as be-ing a combination of the true throughput with added randomnoise according to the average error level. Figure 11a shows7The QoE can be negative when rebuffer time is too long orthere are too many switches.8This is not a flaw, but a deliberate choice for achievingmulti-player fairness [34].

335

0.1 0.2 0.3 0.4 0.50.65

0.7

0.75

0.8

0.85

0.9

0.95

1

Prediction Error

n−

QoE

MPCBBRB

(a) Prediction error

Balanced Avoid Instability Avoid Rebuffering0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

QoE Preference

n−

Qo

E

MPC−OPTFastMPCBBRB

(b) QoE preferences

10 20 30 40 500

0.2

0.4

0.6

0.8

1

Buffer Size (s)

n−

QoE

MPC−OPTFastMPCBBRB

(c) Buffer size

2 4 6 8 100.5

0.6

0.7

0.8

0.9

1

Startup Time (s)

n−

QoE

MPC−OPTFastMPCBBRB

(d) Startup time

Figure 11: Sensitivity analysis vs. operating conditions

how the throughput prediction errors influence the perfor-mance of bitrate adaptation algorithms. As expected, BBis unaffected as it does not use any throughput information.When throughput predictions are accurate, MPC has largeradvantage over BB algorithms. As prediction error growsbeyond 25%, MPC can be even worse than BB. This sug-gests that if the actual prediction error is very large, then thevideo player should drop RB or MPC and use pure BB al-gorithms. In contrast with regular MPC, robust MPC is lessaffected by prediction error as it takes into possible error intoaccount and maximizes the worst case QoE.

Users’ QoE preferences: We compared the performanceof the algorithms under 3 sets of QoE weights, “Balanced”(λ = 1, µ = µs = 3000), “Avoid Instability” (λ = 3, µ =µs = 3000), “Avoid Rebuffering” (λ = 1, µ = µs = 6000).As shown in Figure 11b, as users put more penalty weights tobitrate instability, the MPC algorithms show more advantageover RB and BB. This is because MPC algorithms explicitlymodel the bitrate vs. bitrate instability tradeoff in the QoEfunction, while RB and BB do so in ad-hoc ways. However,when rebuffering time is a more important factor, BB algo-rithms perform similarly with FastMPC algorithms becauseof two key reasons. First, BB algorithms keep a minimumbuffer level so that the player has a better chance surviv-ing low throughput with less/no rebuffering time. Second,while MPC algorithms do a good job with perfect through-put prediction, they can suffer from long rebuffering timesince harmonic mean predictor is imperfect. As such, MPCcan be improved by maintaining a minimum buffer level andemploying a more accurate predictor.

Buffer size and startup delay: Figure 11c analyzes theimpact of playout buffer size. First, when buffer size issmall (<25s in play time), increasing buffer size improvesthe performance of all algorithms. A larger buffer protectsthe player against rebuffering events and also provides moredegrees of freedom to optimize performance. As buffer sizereaches a certain level (25s of play time), the performancesof all algorithms stay constant even buffer size is further in-creased. Finally, RB is the least affected by buffer size be-cause it does not consider buffer level in its decision logic.

While our approach optimizes startup delay automatically,we analyze how overall QoE (except the startup delay term)is affected if the startup delay is fixed. As shown in Fig-ure 11d, as startup time increases, the performance of allalgorithms improves, as the player accumulates more video

in the buffer at the start-up phase making it easier to managerebuffering events.Bitrate levels: We also study how number of bitrate levelsinfluences the performance (not shown). With BB and MPC,we can achieve better performance using finer-grained set ofbitrate levels. With RB, however, the performance of RBfirst improves as we add more bitrate levels, but decreaseswhen there are too many bitrate levels. The reason is that RBstarts changing bitrate more frequently, leading to increasedbitrate instability. One caveat with MPC is that finer-grainedbitrate levels also require more discretization levels for theFastMPC implementation. Understanding this tradeoff is aninteresting direction for future work.

7.4 MPC Configuration and OverheadOverhead: As discussed earlier, FastMPC might increaseplayer overhead relative to BB and RB style algorithms. Wecompare the CPU and memory usage of our implementa-tion of FastMPC, BB, and RB algorithm with the defaultdash.js player. We find that FastMPC, BB, and RB allconsume similar amount of CPU, while FastMPC uses only60 kB more memory (not shown).FastMPC discretization: Recall that the number of dis-cretization levels is an important design parameter for FastMPC.More discretization levels increase FastMPC performancebut require more player memory and may also increase startupdelay. We study this performance vs. overhead tradeoffin Figure 12a and Table 1. From Figure 12a, we see thatmore discretization levels imply larger performance gainsfor FastMPC but the improvement shows diminishing return;e.g., FastMPC achieves 90% of optimal QoE with 100 levelswhile this drops to 70% if there are only 5 levels. Second,the gain vs. discretization level also has some dependencyon the throughput predictor especially with very coarse dis-cretization. Table 1 shows that while the memory overhead

Discretization levelsExtra JavaScript code size

Full table Run length coding

50 25.0 kB 19.1 kB100 100 kB 56.4 kB200 400 kB 141 kB500 2.50 MB 451 kB

Table 1: FastMPC table size

336

5 10 50 100 5000

0.2

0.4

0.6

0.8

1

FastMPC Discretization Levels

n−

QoE

FastMPC + Perfect PredictionFastMPC + Harmonic Mean

(a) Discretization

2 3 4 5 6 7 8 90.88

0.89

0.9

0.91

0.92

0.93

0.94

0.95

Look−Ahead Horizon (chunk)

n−

QoE

MPC, Error = 10%MPC, Error = 15%MPC, Error = 20%

(b) Look-ahead horizon

Figure 12: MPC configuration parameters

increases with more levels, the simple compression schemewe discussed earlier can reduce the memory overhead espe-cially when number of levels is large. For instance, with 100levels the compression rate is 0.5 while with 500 levels it canreduce the table size by 82%. Even with 500 levels, the tablesize is quite reasonably low.

Look-ahead horizon: Figure 12b shows how planning hori-zon impacts the performance of MPC algorithms. As thelook-ahead horizon increases, MPC performances grow andstay stable since more information of future throughput istaken into account. However, as we look further into the fu-ture, prediction accuracy can reduce. The performance ofMPC can even drop if the horizon is too large.

7.5 Summary of ResultsOur main findings are summarized as follows:

1. RobustMPC outperforms existing algorithms in both broad-band (FCC) and cellular (HSDPA) datasets, while regularFastMPC does not show advantage in cellular networkdue to high throughput instability;

2. Our implementation of FastMPC algorithm incurs verylow overhead: near-zero CPU overhead and 60 kB in-crease in memory usage compared to original dash.js;

3. Sensitivity analysis shows that FastMPC has advantagesover BB and RB in wide parameter ranges. However,there is still room for improvement by increasing FastMPCdiscretization granularity and employing more accuratethroughput predictors.

8 DiscussionBefore concluding, we revisit two outstanding issues.

Multi-player effects: In this paper, we focused purely onimproving the design of a single video player. A naturalquestion is to extend these insights to multiple players andinteraction with cross traffic [34, 32]. To fully consider multi-player interaction and fairness, we can extend our control-theoretic model to explicitly consider a fairness term in theQoE function and model the effects of TCP on throughputallocation. For instance, we might be able to reason aboutfairness from the perspective of game theory or distributedcontrol theory in this context. This is an interesting directionfor future research.

Throughput prediction: As observed by other researchers,better throughput prediction can improve video performancein cellular networks [52]. A key limitation of our work isthat we do not have accurate algorithms for throughput pre-diction and the literature is surprisingly scarce and dated [30,51, 20]. Two interesting directions of future work are in us-ing crowdsourced approaches based on measurements fromother clients [41] and developing a better understanding ofthroughput predictability and stability in the wild.

9 ConclusionsOur paper was motivated by recent debates surrounding thedesign of dynamic adaptive streaming over HTTP (DASH)algorithms. To bring some rigor to this space, we developeda control-theoretic problem formulation that allowed us toexplore the design space systematically and evaluate quan-titatively different classes of solutions through well-definedQoE metrics. With the key insights that a broader designspace is available compared to existing solutions, we de-signed and implemented a model predictive control approachto optimally combine buffer occupancy and throughput pre-dictions in order to maximize the user’s QoE. We demon-strated a practical implementation of MPC using the dash.jsreference video player. Our trace-driven emulations usingrealistic throughput variability traces confirmed the advan-tages over state of the art solutions in a wide range of oper-ating conditions with negligible increase in computation andmemory requirements. As future work, we plan to incor-porate more accurate throughput predictions and explicitlycapture multi-player interactions.

AcknowledgmentsThis work was supported in part by the National ScienceFoundation under awards ECCS-0925964 and CNS-1345305.We thank our shepherd Keith Winstein for helping us im-prove the final version. We thank Aditya Ganjam and DavidOran for useful discussions regarding industry player plat-forms that informed our implementation.

10 References

[1] Dash-Industry-Forum, dash.js .https://github.com/Dash-Industry-Forum/dash.js/wiki.

[2] Adobe HTTP Dynamic Streaming.www.adobe.com/products/hds-dynamic-streaming.html.

[3] Adobe OSMF player. http://www.osmf.org.[4] Akamai HD network. www.akamai.com/hdnetwork.[5] Apple’s HTTP Live Streaming.

https://developer.apple.com/streaming/.[6] DASH-264 JavaScript reference client landing page 1.4.0.

http://dashif.org/reference/players/javascript/1.4.0/samples/dash-if-reference-player/index.html.

[7] DASH Industry Forum members. http://dashif.org/members/.[8] DASH VLC plugin.

http://www-itec.uni-klu.ac.at/dash/?page_id=10.[9] FCC dataset.

https://www.fcc.gov/measuring-broadband-america.Accessed: 2014-12-01.

337

[10] HSDPA dataset.http://home.ifi.uio.no/paalh/dataset/hsdpa-tcp-logs.Accessed: 2014-12-01.

[11] Netflix. http://www.netflix.com/.[12] OSMF 2.0 release code. http:

//sourceforge.net/projects/osmf.adobe/files/latest/download.[13] Smooth Streaming protocol.

http://go.microsoft.com/?linkid=9682896.[14] The demo page for our MPC-based bitrate adaptation.

http://users.ece.cmu.edu/~vsekar/mpcdash.html.[15] YouTube live encoder settings, bitrates and resolutions.

https://support.google.com/youtube/answer/2853702?hl=en.[16] I. Sodagar. The MPEG-DASH Standard for Multimedia

Streaming Over the Internet. IEEE Multimedia, 2011.[17] S. Akhshabi, L. Anantakrishnan, C. Dovrolis, and A. C.

Begen. What Happens when HTTP Adaptive StreamingPlayers Compete for Bandwidth? In Proc. NOSSDAV, 2012.

[18] S. Akhshabi, L. Ananthakrishnan, A. Begen, andC. Dovrolis. Server-Based Traffic Shaping for StabilizingOscillating Adaptive Streaming Players. In Proc. ACMSIGMM NOSSDAV, 2013.

[19] A. Balachandran, V. Sekar, A. Akella, S. Seshan, I. Stoica,and H. Zhang. Developing a Predictive Model of Quality ofExperience for Internet Video. In Proc. ACM SIGCOMM,2013.

[20] H. Balakrishnan, M. Stemm, S. Seshan, and R. H. Katz.Analyzing Stability in WideArea Network Performance. InProc. ACM SIGMETRICS, 1997.

[21] D. P. Bertsekas, D. P. Bertsekas, D. P. Bertsekas, and D. P.Bertsekas. Dynamic Programming and Optimal Control,volume 1. Athena Scientific Belmont, MA, 1995.

[22] E. F. Camacho and C. B. Alba. Model Predictive Control.Springer, 2013.

[23] L. D. Cicco, V. Caldaralo, V. Palmisano, and S. Mascolo.TAPAS: a Tool for rApid Prototyping of Adaptive Streamingalgorithms. In Proc. CoNext VideoNext workshop, 2014.

[24] F. Dobrian, V. Sekar, A. Awan, I. Stoica, D. A. Joseph,A. Ganjam, J. Zhan, and H. Zhang. Understanding theImpact of Video Quality on User Engagement. In Proc. ACMSIGCOMM, 2011.

[25] G. F. Franklin, J. D. Powell, and M. L. Workman. DigitalControl of Dynamic Systems, volume 3. Addison-wesleyMenlo Park, 1998.

[26] A. Ganjam, F. Siddiqui, J. Zhan, X. Liu, I. Stoica, J. Jiang,V. Sekar, and H. Zhang. C3: Internet-Scale Control Plane forVideo Quality Optimization. In Proc. NSDI, 2015.

[27] M. Ghobadi, Y. Cheng, A. Jain, and M. Mathis. Trickle: RateLimiting YouTube Video Streaming. In Proc. USENIX ATC,2012.

[28] S. Gouache, G. Bichot, A. Bsila, and C. Howson. Distributedand Adaptive HTTP Streaming. In Proc. ICME, 2011.

[29] D. Havey, R. Chertov, and K. Almeroth. Receiver DrivenRate Adaptation for Wireless Multimedia Applications. InProc. MMSys, 2012.

[30] Q. He, C. Dovrolis, and M. Ammar. On the Predictability ofLarge Transfer TCP Throughput. In Proc. ACM SIGCOMM,2005.

[31] R. Houdaille and S. Gouache. Shaping HTTP AdaptiveStreams for a Better User Experience. In Proc. MMSys, 2012.

[32] T.-Y. Huang, N. Handigol, B. Heller, N. McKeown, andR. Johari. Confused, Timid, and Unstable: Picking a VideoStreaming Rate is Hard. In Proc. IMC, 2012.

[33] T.-Y. Huang, R. Johari, N. McKeown, M. Trunnell, andM. Watson. A Buffer-Based Approach to Rate Adaptation:

Evidence from a Large Video Streaming Service. In Proc.ACM SIGCOMM, 2014.

[34] J. Jiang, V. Sekar, and H. Zhang. Improving Fairness,Efficiency, and Stability in HTTP-based Adaptive VideoStreaming with FESTIVE. In Proc. CoNext, 2012.

[35] S. S. Krishnan and R. K. Sitaraman. Video Stream QualityImpacts Viewer Behavior: Inferring Causality usingQuasi-Experimental Designs. In Proc. IMC, 2012.

[36] R. Kuschnig, I. Kofler, and H. Hellwagner. Evaluation ofHTTP-based Request-Response Streams for Internet VideoStreaming. Multimedia Systems, pages 245–256, 2011.

[37] L. De Cicco, S. Mascolo, and V. Palmisano. FeedbackControl for Adaptive Live Video Streaming. In Proc. of ACMMultimedia Systems Conference, 2011.

[38] Z. Li, X. Zhu, J. Gahm, R. Pan, H. Hu, A. Begen, andD. Oran. Probe and Adapt: Rate Adaptation for HTTP VideoStreaming at Scale. Selected Areas in Communications,IEEE Journal on, 32(4):719–733, 2014.

[39] C. Liu, I. Bouazizi, and M. Gabbouj. Parallel AdaptiveHTTP Media Streaming. In Proc. ICCCN, 2011.

[40] H. Liu, Y. Wang, Y. R. Yang, A. Tian, and H. Wang.Optimizing Cost and Performance for Content Multihoming.In Proc. ACM SIGCOMM, 2012.

[41] X. Liu, F. Dobrian, H. Milner, J. Jiang, V. Sekar, I. Stoica,and H. Zhang. A Case for a Coordinated Internet VideoControl Plane. In Proc. ACM SIGCOMM, 2012.

[42] R. K. P. Mok, X. Luo, E. W. W. Chan, and R. K. C. Chang.QDASH: A QoE-aware DASH system. In Proc. MMSys,2012.

[43] C. Mueller, S. Lederer, J. Poecher, and C. Timmerer. Libdash- An Open Source Software Library for the MPEG-DASHStandard. In Proc. ICME, 2013.

[44] L. Popa, A. Ghodsi, and I. Stoica. HTTP as the Narrow Waistof the Future Internet. In Proc. HotNets, 2010.

[45] R. Rejaie and J. Kangasharju. Mocha: A Quality AdaptiveMultimedia Proxy Cache for Internet Streaming. In Proc.NOSSDAV, 2001.

[46] S. Akhshabi, A. Begen, C. Dovrolis. An ExperimentalEvaluation of Rate Adaptation Algorithms in AdaptiveStreaming over HTTP. In Proc. MMSys, 2011.

[47] G. Tian and Y. Li. Towards Agile and Smooth VideoAdaption in Dynamic HTTP Streaming . In Proc. CoNext,2012.

[48] Y. Wang and S. Boyd. Fast Model Predictive Control usingOnline Optimization. Control Systems Technology, IEEETransactions on, 18(2):267–278, 2010.

[49] B. White, J. Lepreau, L. Stoller, R. Ricci, S. Guruprasad,M. Newbold, M. Hibler, C. Barb, and A. Joglekar. AnIntegrated Experimental Environment for DistributedSystems and Networks. Proc. OSDI, 2002.

[50] X. Yin, V. Sekar, and B. Sinopoli. Toward a PrincipledFramework to Design Dynamic Adaptive StreamingAlgorithms over HTTP. In Proc. ACM SIGCOMM HotNets,2014.

[51] Y. Zhang and N. Duffield. On the Constancy of Internet PathProperties. In IMW, 2001.

[52] X. K. Zou, J. Erman, V. Gopalakrishnan, E. Halepovic,R. Jana, X. Jin, J. Rexford, and R. K. Sinha. Can AccuratePredictions Improve Video Streaming in Cellular Networks?In Proc. ACM HotMobile, 2015.

338