Bandwidth Estimation and Rate Adaptation in

HTTP Streaming
Bing Zhou, Jingyuan Wang, Zixuan Zou and Jiangtao Wen
State Key Laboratory on Intelligent Technology and Systems
Tsinghua National Laboratory for Information Science and Technology (TNList)
Department of Computer Science and Technology,
Tsinghua University, Beijing, China
Email: zhoubing09@mails.tsinghua.edu.cn, wangjingyuan06@mails.tsinghua.edu.cn,
zouzixuan@huawei.com, jtwen@tsinghua.edu.cn
AbstractHTTP Streaming is one type of video streaming
technology, delivering multimedia data using HTTP/TCP. Due to
the strict boundaries between layers of the OSI communication
model, HTTP Streaming client at the Application Layer can only
see the bandwidth that TCP at the Transport Layer supplies. How
to estimate the upcoming bandwidth in the future according to
the bandwidth history HTTP Streaming client has seen is the
rst problem this paper wants to address. Since the network
bandwidth represents the data producing rate for the media
player at the client and the media bitrate represents the data
consuming rate of the media player, the quality of user experience
of HTTP Streaming would be at a low level, if there is mismatch
between the network bandwidth and the media bitrate. How to
make rate adaptation for HTTP Streaming system based on the
bandwidth estimation results is the second problem this paper
wants to address. From the experimental results, we can see our
bandwidth estimation and rate adaptation algorithm proposed to
tackle the above two problems can provide a better enhancement
for the prevalent HTTP Streaming system, comparing with the
rate adaptation algorithm using common throughput smoothing
strategy.
KeywordsHTTP Streaming, Bandwidth Estimation, Rate
Adaptation
I. INTRODUCTION
Unlike the traditional mode that client couldnt play back
the media content until nishing downloading the entire media
le from server, multimedia streaming technology makes both
data transferring and media playing back simultaneously[1].
HTTP Streaming (henceforth called HS) is one type of mul-
timedia streaming technology delivering media data using
HTTP/TCP. Although the inner retransmission and conges-
tion control mechanism within TCP makes the end-to-end
throughput uctuate irregularly, which is not desirable for HSs
smoothness of playback[2][3], because the media distribution
system is simple to be deployed, HS has been widely used
in todays internet applications. In HS system, HTTP as a
traditional Application Layer protocol running over TCP just
distributes the media le as the traditional hypertext le and
doesnt provide any specic functionality for media streaming.
To make adaptation to the network bandwidth, as specied in
TS26.234[4], one Media Presentation (MP) stored at HS server
consists of several Periods split from an original media le,
each Period contain Representations, which further contains
Segment(0,0)
Period 0 Period 1 Period N-1
Segment(0,1)
Segment
(0,N-1)
Segment(1,0) Segment(1,1)
Segment
(1,N-1)
Segment
(M-1,0)
Segment
(M-1,1)
Segment
(M-1,N-1)

BR 0
BR 1
BR M-1

Media Presentation
Fig. 1. MP Organization Stored at the HTTP Streaming Server.
one or more Segments from the same media content but
with different bitrates, and each Segment can be referenced
by a unique http-URL. A schematic representation for MP
organization matrix is shown in Fig.1, in which there are N
Periods contained in an entire Media Presentation and each
Period contains M Segments with different bitrates (denoted
as BR). The rate adaptation problem in HS system refers
to the two problems that when to start the data transferring
for each Period of MP and how to select the Segment with
appropriate bitrate version for each Period, and we call the
former problem as download-rate adaptation problem, the
latter bitrate adaptation problem. This paper mainly focuses
on the problem of bitrate adaptation; for completeness, we
use a simple strategy for download-rate control that a new
Period starts downloading when and only when the data of
the previous Period is fully loaded and is being playbacked
(consumed) by the clients media player, that is, at most one
extra Period data is allowed to be stored at the clients buffer.
Chenghao Liu[5] has proposed an algorithm to calculate
the smoothed throughput (SMT) using the media segment size
(MSS) and segment fetch time (SFT) that SMT=MSS/SFT
and deployed a step-wise switch up and aggressive switch
down method for rate adaptation with SMT. Measuring the
TCP throughput with a smoothed value is a common strategy
to coarsely indicate the network bandwidth level, which cant
International Conference on Computing, Networking and Communications, Multimedia Computing and Communications
Symposium
978-1-4673-0009-4/12/$26.00 2012 IEEE 734
Network
BUFFER
HTTP Streaming
MP
HS Server HS Client
PlayBack
Producer Consumer
Fig. 2. System Architecture for HTTP Streaming.
express the uctuation of the TCP throughput. In this paper, we
construct an array of values to illustrate the TCP throughput
according to the bandwidth history and each value of the
array represents the data amount estimated that HS client can
download from the HS server via network bandwidth during a
certain length of time in the future. With the aid of the array
of bandwidth estimated, HS client selects a Segment with an
optimal bitrate for each Period (except the rst Period) using
the principal that guaranteeing the media buffer at HS client
wouldnt get underow during the playback process of the
Period.
The rest of this paper is organized as follows. Section
2 details our receiver-driven bandwidth estimation and rate
adaptation algorithm for HS system, section 3 demonstrates
the experimental evaluation for our rate adaptation method,
comparing with the algorithm proposed by [5], and section 4
concludes this paper.
II. RECEIVER-DRIVEN BANDWIDTH ESTIMATION AND
RATE ADAPTATION ALGORITHM FOR HTTP STREAMING
HS client plays back the media content transferred from
HS server via network bandwidth. The producer-consumer
model for HS system is shown in Fig.2[6], where the network
bandwidth represents the producing rate and media contents
bit-rate represents the consuming rate to the playback buffer
of the client. Assuming at the playback time T
c
the current
Period
i
being playbacked is fully loaded, the next Periods
playback time is from T
s
to T
e
, as shown in Fig.3, and B(t)
denotes the network bandwidth, the the bitrate (henceforth
called BR) R
i+1
for the following Period
i+1
to guarantee
there is no playback interruption during the future interval
[T
s
, T
e
] could be described by the following inequation,

t
Ts
R
i+1
dt

t
Tc
B(t)dt, t [T
s
, T
e
]. (1)
We cant restrict the value of R
i+1
for t [T
s
, T
e
] actually,
since there are innite number of time-points in the continuous
interval [T
s
, T
e
]. For a practical solution, a series of discrete
time-points from [T
s
, T
e
] are picked out every other the time
spacing of one second, denoted as {T
1
, ..., T
n
} [T
s
, T
e
], as
shown in Fig.3, and we approximately consider there would
be no playback interruption from playback time T
s
to T
e
, if
the value of R
i+1
meets the following inequation,

t
Ts
R
i+1
dt

t
Tc
B(t)dt, t {T
1
, ..., T
n
}. (2)
The bandwidth function B(t) in the future interval [T
s
, T
e
]
Bandwidth
( Bitrate )
Periodi
Periodi+1 Periodi+2

Time
Ri
Tc Ts Te
T1 T2 Tn
BWE(Tc,Tn)
BWE(Tc,T2)
BWE(Tc,T1)

Bandwidth history
Fig. 3. Producer-Consumer Model Anatomy for HTTP Streaming.
cant be accurately described at the current playback time T
c
.
An estimated value BWE(T
c
, t) is used to substitute for the
integral value of

t
Tc
B(t)dt, and the inequation (2) could be
modied as the following inequation,

t
Ts
R
i+1
dt BWE(T
c
, t), t {T
1
, ..., T
n
}. (3)
According to the inequation (3), taking the bitrate of each
Period as constant one, the nal upper limit for the bitrate of
the following Period
i+1
could be deduced as the following
equation,
R
i+1
= min{
BWE(T
c
, t)
t T
s
, t {T
1
, ..., T
n
}}. (4)
With the aid of the upper limit of the BR R
i+1
, if HS server
provides Segments with BR lower than R
i+1
for Period
i+1
,
HS client would select the one with a maximal bitrate r
i+1
which meets the condition of r
i+1
<= R
i+1
; other wise, HS
client would select the one with a minimal bitrate r
i+1
which
meets the condition of r
i+1
> R
i+1
.
The value of BWE(T
c
, t) which represents the estimated
data amount that HS client can download from HS server
during the future interval [T
s
, t] is calculated as the minimal
data amount that HS client has successfully downloaded from
HS server during an interval with the same length of (t-T
c
).
Let BWE[i] record the minimal data amount HS client has
downloaded from HS server during an interval with the length
of i seconds in data transmission history, the next problem is
focused on the construction of the array BWE. We check the
depth of the playback buffer of the client every other second
and record the newly increased depth as the data amount
that HS client downloaded from HS server during the latest
second, denoted as H[LH], where LH denotes the current
largest length of continuous transmission time since the last
second during which there is no data newly added into the
playback buffer. For each i <= LH, the sum temp of the i
values, H[LH], H[LH1], ..., H[LHi + 1], is calculated as
the data amount that HS client downloaded from HS server
during the latest continuous interval with length of i seconds.
If BWE[i] is NULL, which means there is no bandwidth
history record for an i length interval, we let BWE[i] record the
value of temp and LB++, where LB denotes the thickness
of the bandwidth history; if BWE[i] > temp, we update
735
Algorithm 1 Construction Procedure for BWE Array
bfNew=0; bfOld=0; H[ ]=NULL; BWE[ ]=NULL;
LH=1; LB=0;
for(every other second){
bfNew=The current depth of the playback buffer;
if(bfNew<=bfOld){ //Re-initialize H[ ] and LH
LH=1; H[ ]=0;
} else {
H[LH]=bfNew-bfOld;
for(i=1;i<=LH;i++){
temp=H[LH]+...+H[LH-i+1];
if(BWE[i]==NULL){ BWE[i]=temp; LB++; }
else if(BWE[i]>temp){ BWE[i]=temp; }
}
bfOld=bfNew; LH++;
}
}
BWE[i] as temp, the latest minimal data amount HS client
has downloaded from HS server during an i length interval;
other wise, the value of temp would be discarded. If there
comes a second during which no newly data is downloaded
into the client playback buffer, the array H[ ] and counter LH
would be re-initialized because the continuous transmission
state is interrupted by the idle second which may be caused
by download-rate control. The corresponding pseudocode is
shown in Algorithm 1.
The calculation procedure for R
i+1
is shown in pseudocode
Algorithm 2. For each discrete time-point T
k
[T
s
, T
e
], k=1,
..., n, if (T
k
T
c
) <= LB, where (T
k
T
c
) denotes the length
of interval to be estimated and LB denotes the bandwidth
history thickness, the largest length of the interval recorded
for continuous data transmission, the value of BWE(T
c
, T
k
)
is assigned as BWE[T
k
T
c
] and the corresponding restricted
BR R
k
i+1
can be calculated as BWE[T
k
T
c
]/(T
k
T
s
);
other wise, we consider the value of BWE(T
c
, T
c
) cant be
calculated by the current bandwidth history and time-point
T
k
would be discarded by setting the R
k
i+1
to be +. The
nal upper limit R
i+1
is the minimal value of the n candidate
restricted BR, R
1
i+1
, R
2
i+1
, ..., R
n
i+1
, as described by equation
(4).
Algorithm 2 Calculation Procedure for R (i+1)
for(each time-point T
k
){ //k=1, ..., n
if((T k-T c)>LB)
R
k
i+1
=+;
else
R
k
i+1
=BWE[T
k
-T
c
]/(T
k
-T
s
);
}
R
i+1
=min{R
k
i+1
, k=1, ..., n};
III. EXPERIMENTAL EVALUATION
In our experiments, HS server is constructed using Nginx-
0.7.65, HS client is a common web browser, and the network
LinkTropy Network
Emulator
HS Server HS Client
GU of Linktropy
Fig. 4. Experimental Topology for HTTP Streaming Qos Evaluation.
Fig. 5. GUI of Linktropy Network Emulator.
connecting HS server and HS client is emulated by the
Linktropy network emulator, which can accurately simulate
the network environments with different bandwidth, delay
and packet loss rate characteristics. The experiment network
topology is shown in Fig.4 and the graphical user interface
(GUI) of Linktropy is shown in Fig.5.
Our bandwidth estimation and rate adaptation algorithm for
HS system is implemented into a SWF player under the Adobe
Flash Builder 4.0 IDE using the ActionScript 3.0 language. HS
client starts streaming the MP stored at HS server via visiting
the SWF player which is also stored at HS server. The MP
used for our experiments consists of 7 Periods and each Period
consists of 9 Segments with 200Kbps, 300Kbps, 400Kbps,
500Kbps, 600Kbps, 700Kbps, 800Kbps, 900Kbps, 1000Kbps
Constant Bitrate (henceforth called CBR) respectively. since
the Segment switching delay would impair the Qos of HS
service, for cutting down the switching frequency, each Period
mentioned above is with a comparative long playback duration
of 120 Seconds.
In order to compare the TCP throughput accuracy of our
bandwidth estimation algorithm with that of the common
throughput smoothing strategy, the rate adaptation method
proposed by [5] is implemented into the HS server of our
experiment. [5]s rate adaptation method adjusts the bitrate
according to the ratio of media segment duration (MSD) to
segment fetch time (SFT), denoted as =MSD/SFT. If >
1+, HS client would select the segment with the next higher
bitrate and if < r
d
, HS client would select the segment with
the maximal bitrate r that meets r < SMT, where is the
bitrate switch up factor, r
d
is an empirical value, and SMT is
736
1 2 3 4 5 6 7
200
400
600
800
1000
1200
1400
Perod_id
C
B
R

(
K
b
p
s
)


RA with BWE
RA with SMT
No RA
(a) CBR Evolution
1 2 3 4 5 6 7
1
0.5
0
0.5
1
Period_id
S
t
a
l
l

F
r
e
q
u
e
n
c
y

(
t
i
m
e
s
/
s
)


RA with BWE
RA with SMT
No RA
(b) Stall Frequency Evolution
Fig. 6. Qos of HTTP Streaming Starting with CBR=200Kbps.
1 2 3 4 5 6 7
100
200
300
400
500
600
700
800
900
Perod_id
C
B
R

(
K
b
p
s
)


RA with BWE
RA with SMT
No RA
(a) CBR Evolution
1 2 3 4 5 6 7
0.5
0
0.5
1
1.5
2
2.5
Period_id
S
t
a
l
l

F
r
e
q
u
e
n
c
y

(
t
i
m
e
s
/
s
)


RA with BWE
RA with SMT
No RA
(b) Stall Frequency Evolution
Fig. 7. Qos of HTTP Streaming Starting with CBR=600Kbps.
the smoothed throughput calculated by SMT = MSS/SFT
in which MSS is the media segment size. We calculate as
0.5 according the bitrate versions presented in HS server and
set r
d
as 1 which means MSD is just equal to SFT and there
is no stalling occurring during the media playback. Besides,
the Qos of HS service without rate adaptation would be also
implemented into the our experiments for comparison.
Since HS client doesnt have the bandwidth information to
select Segment for the rst Period, the CBR upper limit for the
rst Period is manually preset using a conguration le stored
at HS server in our experiments. We evaluate the efciency
of different rate adaptation method by checking the Qos of
the Periods after the rst one. Two merits are introduced in
our experiments to measure the Qos of the HS service, one
is the CBR of each Period, the other one is the stalling
frequency of each Period, dened as ST/MSD, where ST
denotes the total stalling times during the Periods playback
process. A larger bitrate usually means a larger PSNR value,
and the lower the stalling frequency is, the more uent the
playback of the Segment means.
HS client selects different starting CBR for the rst Period
may cause different evolutions of CBR and stalling frequency
for the following Periods under different rate adaptation al-
gorithms, for which we design two experiments in which
HS service respectively starts with a relatively small and a
relatively large CBR, compared with the available bandwidth,
for the rst Period. For each experiment case, we record the
Qos of HS service under our rate adaptation algorithm (RA
with BWE), under [5]s algorithm (RA with SMT), and
without rate adaptation operation (no RA).
The rst experiment uses the following network condition:
the link from HS client to HS server and the link from
HS server to HS client respectively holds a 2Mbps channel
capacity, a 100/100/10(ms) normal distribution delay, and
0.5% packet loss rate, where x/y/z(ms) normal distribution
denotes the normal distribution of x(ms) average value, y(ms)
minimal value and z(ms) standard variation (the same below).
In this experiment, HS client selects the Segment with CBR
200Kbps for the rst Period, and the experiment results under
the three rate adaptation strategies mentioned above are plotted
in Fig.6. From the CBR evolution showed in Fig.6(a), we can
see if HS client doesnt adopt any rate adaptation operation,
the 6 Periods following the rst Period would present the
Segments with the same CBR as Period 1 of 200Kbps; if
HS client adopts the rate adaptation algorithm with SMT
proposed by [5], the CBR would step-wise switch up from
Period 1 of 200Kbps to Period 5 of 600Kbps, but would stop
at 600Kbps in Period 6 and Period 7; if HS client adopts
our rate adaptation algorithm with BWE, the CBR would
keenly switch up to 1000Kbps in Period 2, and make CBR
adjusting adaptively to the bandwidth estimated that switch
the CBR down to 800Kbs in Period 5 and up to 1000Kbps in
Period 6 again. From the stalling frequency evolution showed
in Fig.6(b), we can see HS client can keep a uent media
playback no matter which rate adaptation strategy it adopts.
The results of the rst experiment demonstrate that our rate
adaptation algorithm with BWE could well guarantee there is
no interruption during the media playback at HS client and
could tune the CBR from the low level to a higher one to
adapt the good network condition, but provide a better Qos
than does the algorithm with SMT.
The second experiment uses another network condition: the
link from HS client to HS server and the link from HS server
to HS client respectively holds a 2Mbps channel capacity, a
737
100/100/100(ms) normal distribution delay and 0.1% packet
loss rate. HS client selects the Segment with CBR 600Kbps
for the rst Period, and the corresponding experiment results
are plotted in Fig.7. From the CBR evolution showed in
Fig.7(a), we can see that, the rata adaptation algorithm with
SMT can switch down the CBR from 600Kbps which is
larger than the available bandwidth in Period 1 to 200Kbps
in Period 2 and maintain 300Kbps CBR from Period 3 to
Period 7; our algorithm with BWE can also switch down the
CBR to 200Kbps in Period 2, but tune the CBR to a higher
level in Period 3, Period 4, Period 6, Period 7 than does the
algorithm with SMT. From the stalling frequency showed in
Fig.7(b), we can see the rate adaptation with SMT and ours
with BWE both can guarantee a uent media playback from
Period 2 to Period 7. The HS service without rate adaptation
is always in the state of frequent interruption. The results of
the second experiment demonstrate that our algorithm with
BWE could tune the CBR from a high lever to a lower one
to adapt the bad network condition, but provide a better Qos
than does the algorithm with SMT.
IV. CONCLUSION
In this paper, we propose a rate adaptation algorithm based
on bandwidth estimated for HS system. Our bandwidth estima-
tion is to calculate the data amount HS client could download
from HS server during a certain interval in the future as the
minimal data amount that HS client has successfully down-
loaded from HS server during an interval with the same length
in data transmission history. Used for bandwidth estimation,
the array of BWE which records the minimal data amounts
HS client has successfully downloaded from HS server during
different intervals with different lengths can express the uc-
tuation of the TCP throughput. According to the bandwidth
estimated, we additionally calculate the bitrate upper limit for
the following Period using the principal that guaranteeing there
would be no interruption during the playback process of the
Period. The experiment results demonstrate that our algorithm
could provide a better Qos of HS service, comparing with does
the rate adaptation algorithm with the common throughput
smoothing strategy.
REFERENCES
[1] Dapeng Wu, Yiwei Thomas Hou, Wenwu Zhu, Ya-Qin Zhang, and
John M. Peha, Streaming video over the internet: approaches and
directions, Circuits and Systems for Video Technology, vol. 11 Issue
3, pp. 282 300, Mar 2001.
[2] Saugath Joshi and Dushan Aththidiyavidanalage Don, Multimedia
streaming: Can tcp handle it ?, Paper Survey Report.
[3] Bing Wang, Jim Kurose, Prashant Shenoy, and Don Towsley, Multimedia
streaming via tcp: An analytic performance study, ACM Transactions on
Multimedia Computing, Communications, and Applications, vol. 4, May
2008.
[4] 3GPP TS 26.234, Transparent end-to-end packet-switched streaming
service (pss); protocols and codecs, 2010-12, Release 9.
[5] Chenghao Liu, Imed Bouazizi, and Moncef Gabbouj, Rate adaptation for
adaptive http streaming, MMSys 11 Proceedings of the second annual
ACM conference on Multimedia systems, 2011, New York, USA.
[6] Crispin Cowan, Shanwei Cen, Jonathan Walpole, and Calton Pu, Adap-
tive methods for distributed video presentation, ACM Computing Surveys
(CSUR), vol. 27 Issue 4, pp. 580583, Dec. 1995.
738