Avoiding quality oscillations during adaptive streaming of video

INTERNATIONAL JOURNAL OF DIGITAL INFORMATION AND WIRELESS COMMUNICATIONS (IJDIWC) 1(1): 126–145THE SOCIETY OF DIGITAL INFORMATION AND WIRELESS COMMUNICATIONS, 2011 (ISSN 2225-658X)

Avoiding quality oscillations during adaptive streamingof video

Wassim Ramadan Eugen Dedu∗ Julien Bourgeois

Laboratoire d’Informatique de l’Universite de Franche-ComteNumerica, Cours Leprince-Ringuet, BP 21126, 25201 Montbeliard, France{Wassim.Ramadan,Eugen.Dedu,Julien.Bourgeois}@pu-pm.

univ-fcomte.fr

ABSTRACT

A high number of videos, encoded in several bi-trates, are nowadays available on Internet. A highbitrate needs a high and stable bandwidth, so a lowerbitrate encoding is usually chosen and transferred,which leads to lower quality too. A solution is toadapt dynamically the current bitrate so that it al-ways matches the network bandwidth, like in a clas-sical congestion control context. When the bitrate isat the upper limit of the bandwidth, the adaptationswitches constantly between a lower and a higherbitrate, causing an unpleasant oscillation (zigzag) inquality on the user machine. This paper presents asolution to avoid such oscillations. It uses an EWMA(Exponential Weighted Moving Average) value foreach bitrate, which reflects its history. The evalu-ation of the algorithm shows that loss rate is muchsmaller, bitrate is more stable, and so received videoquality is better.

Keywords: Real time content, Video streaming,Rate control, Congestion control

∗Corresponding author.

1 INTRODUCTION

Nowadays, the number of videos encoded inseveral bitrates and accessible for everyone in-creases significantly day by day. Their con-tents are generally delivered to final user usingstreaming services over Internet. These servicesas well as the demand for high video quality(e.g. HD and 3D videos) are in constant pro-gression. They require more and more band-width, hence available bandwidth variation mustbe taken into account to shorten buffering timeat the receiver.

Currently, one video bitrate is chosen at thebeginning of a video streaming; the transmis-sion is controlled at the network layer (TCPor UDP) and application is not involved at all.Hence, two choices exist when playing streamedvideo content. The first is to choose a low videobitrate, and the video is played directly, with-out interruption. The second is to choose a bit-rate higher than average bandwidth, buffer mul-

126


timedia data at the user and play the video whenthe buffer has sufficient data; because the bufferempties, the user will be confronted to manyplay/pause during the streaming. Both cases areunpleasant to the user eye: the first has the ad-vantage to watch a fluid video but with low qual-ity, while the latter allows to have a good qualitybut with either short or long waiting time andwith frequent interruptions. Users wishing tohave an instant access without delay to multi-media content and with the best possible qualitycan use a new kind of multimedia streaming ser-vices, multimedia content adaptation.

For video streaming in a network with highlyvariable bandwidth, a content adaptation is away to adapt the video bitrate to the networkcharacteristics, hence to improve the video qual-ity perceptible by the final user. A coopera-tive approach between application layer and net-work layer can be used. Transport protocol han-dles the congestion control on the network side,while the application handles the video bitratecontrol on the server side. Bitrate can be con-trolled by changing the quantisation parameters,or the FPS (frames per second) or other param-eter.

An undesirable effect which appears whenmultiple video qualities are available and whenbandwidth changes, is that the bitrate controlleads to constant switching between two quali-ties (bitrates); one is smaller than the bandwidthand the second is greater. For example, when auser is connected to Internet through a 2.5Mb/slink and the video is available in 2 and 3Mb/squalities, then an adaptive streaming algorithmwill constantly switch between these two qual-ities; obviously, the best solution would be tostay with 2Mb/s much more time before retry-

ing 3Mb/s quality. We call this problem zigzagquality switching.

Few papers treat this issue, and they donot solve it completely. This paper presentsa solution, called ZAAL (Zigzag AvoidanceAlgorithm), to this problem1. It uses a success-fulness value of each bitrate, and its average isconstantly updated. This average is used to takethe decision whether a next higher quality canbe chosen or not, thus preventing the zigzag.

This paper is organized as follows. Section 2formulates the problem which we try to solve,and section 3 compares it to similar existingproblems. Section 4 presents our ZAAL algo-rithm as a solution to the problem, and its per-formance is evaluated through real experimentsin section 5. Finally, section 6 concludes thisarticle and presents some perspectives.

2 PROBLEM FORMULA-TION

The zigzag quality switching is the fact thatan adaptive video streaming sender applicationkeeps switching the video quality between twovalues, especially when one value is greater andthe other is smaller than the bandwidth capac-ity.

In a network with highly variable bandwidth,video adaptation is very important. It aims toadapt the video bitrate to the network character-istics and thus to improve the video quality per-ceptible by the final user. The adaptation can bedone at several OSI layers, but we take the appli-

1This article is an extension of one of our previouspapers [1].

127


cation layer to exemplify. To adapt video to net-work conditions, the sender application controlssome video parameters, such as the bitrate, FPS(Frames per second) or image size; for example,if more bandwidth is available, application in-creases the video bitrate, and if less bandwidthis available, application decreases it. To reachthis goal, application should constantly retrievethe bandwidth (each 100ms, each 2 sec. or eachI image for MPEG video for example) and adaptits bitrate accordingly. To minimise the qualityfluctuation, it is not preferable, in our opinion,to change quality each tiny period (at each sentpacket for example). Sometimes the applicationhas the choice among multiple available videoqualities (e.g. many videos on Internet are en-coded with several qualities). This video adap-tation is known in the literature as “rate adaptivevideo control”.

Fig. 1 presents an example which allows tobetter understand how video adaptation works.The transport protocol has a congestion con-trol which gives the rate at which the pack-ets leave the socket buffer (and afterwards themachine, and enter the network). When cur-rent bandwidth is smaller than video bitrate,the socket buffer fills with packets. When thebuffer becomes full, exceeded packets generatedby application will fail to be written. We callthese packets “failed packets”. The goal of anadaptive video content application is to readjustvideo bitrate in this case by choosing a lowervideo quality. When new bitrate does not causefailed packets, application will retry a higherquality to match again the available bandwidthand to enhance the video quality.

Our previous paper VAAL (Video Adapta-tion at Application Layer) [2] is an example of

Figure 1: Video data flow on the sender side.

video adaptation method. It uses transport pro-tocol buffer overflow as a method to find outthe available bandwidth and to adapt video con-tent bitrate to the discovered bandwidth. Each2 seconds, the server application computes thenumber of failed packets. This number is usedto control the video bitrate afterwards. A highnumber means smaller bandwidth and smallerbitrate. Zero error indicates either a stable ormore bandwidth, so bitrate of sent video can beincreased. The experiments presented in this pa-per use VAAL.

An adaptive application, such as the onepresented above, keeps switching between twoqualities: one with bitrate higher than bandwidthand with failed packets, and another one withbitrate smaller than bandwidth and with no er-ror. We noticed this phenomenon in our ex-periments (see Fig. 4(a) for a clear example,where during the first minute the video bitrate iscontinuously toggling between 0.5 and 1 Mb/s).This is what we called “zigzag quality switch-ing” problem; it has two undesirable effects:

• Numerous bitrate changes, leading to un-stable video quality. It is preferable to keepthe video quality stable as much as possiblewhile maximising it.

• Many lost packets (when bitrate is higherthan bandwidth), leading to lower videoquality and wasted ressources (CPU and

128


network) for these lost packets. Indeed,videos are generally more affected bypacket losses than lower bitrate.

Note that the problem to be solved is not to re-duce the number of quality changes, for examplewhen such changes use much resources (CPU,disk etc.) It is neither to use the highest avail-able quality at a certain moment (which can po-tentially lead to zigzag, for example when rightafterwards the bandwidth decreases). The prob-lem to be solved is the zigzag oscillations, i.e.avoiding to reuse a quality which has recentlybeen used (one or more times) and has provedunsuccessful. As such, a method which doesnot take into account the recent history some-how cannot solve this problem.

3 POSITIONING COM-PARING TO RELATEDWORK

We found that our problem has similarities withother problems, and with two techniques alreadyfound in the literature.

3.1 Similar MethodsOne method which can be used to solve zigzagquality switching is presented in [3]. It is pro-posed for multicast streaming video but can beadapted to unicast transmissions too. The sendersends several layers (base and enhancement),and the receiver subscribes dynamically to oneor several of them. The receiver uses a timer foreach level of subscription (layer). At the begin-ning the timer is short. When the timer expires

and no loss was experienced, the receiver sub-scribes to the next new level and the timer forthat level is started. If on the contrary the levelled to lost packets, the receiver goes back to pre-vious level and the timer for the level with lossesis multiplicatively increased.

In this method, there is no superior limit forthe timer, which means that the quality increas-ing can be forbidden for a very long time, evenif bandwidth becomes greater in the meantime.Also, each time, only the timer of the currentbitrate is updated, which means that good con-ditions for higher levels do not ameliorate thetimer of lower levels. Both these characteristicsare unrealistic. On the contrary, our EWMA-based algorithm does not have these drawbacks.

A metric to evaluate the jerkiness of a video,given by the number of quality changes, is givenin [4]. It uses a formula to calculate the EffectiveFrame Rate (EFR) of a video:

EFR =

N−1∑i=1

(fpsi − P ∗ qchanges(max(i−W, 0), i)

N

)(1)

where fpsi is the number of frames deliveredin the ith second of the video, W is the win-dow size, P is a weighting factor for variationin frame rate, and qchanges(max(i −W, 0), i)is the number of quality changes in the rangei−W to i.

This formula is used to limit the number ofquality changes during each window (W ). Assuch, it counts the number of quality changes,no matter where they appear inside the window,which is however an important parameter ofthe jerkiness. For example, 10 quality changesin the first 2 seconds of a video of 1 minute

129


are worse visually than 10 quality changes dis-persed through the whole video. The goal ofEWMA, used in our solution, is exactly to takeinto account the time of the change too. More-over, in [4] the window is static (coarse-grainedmoving) and fixed (same size), while in our casewe use a sliding and dynamic window.

Finally, our goal is not to limit the number ofquality changes, but to avoid quality increaseswhich lead to quality decreases right afterwards.For all these remarks, the formula in this paperis not interesting in avoiding the zigzag problemwe want to tackle.

The adaptation video method described in [5]does not cope directly with zigzag problem butpresents a way for smoothing sent video bit-rate and reducing the frequency of video qual-ity changes. The main idea is that the applica-tion does not switch to a higher video quality(or video layer in a hierarchical video encoding)until the sender is certain that the video will con-tinue playing even after a reduction of the con-gestion window.

This paper presents results for AIMD andSQRT congestion controls for video streaming.To guarantee the continuous video playing, thesent video quality should be the highest qualitywhich verify: C < R − βRl, where C is thebitrate at which the video is encoded, R is thetransmission rate and β = 1/2 and l = 1 forAIMD based congestion control and l = 1/2for SQRT based one. This formula implies thatthe highest video quality does not exceed half ofthe transmission rate for AIMD, and it is β

√R

smaller than the bandwidth for SQRT.Results given in [5] show that this formula

works well for AIMD based congestion con-trol streaming application but the video bitrateis most of the time very low compared to avail-able bandwidth. On the other hand, it has a littleimpact on SQRT based algorithm, i.e. the qual-ity changes are not significantly reduced. Fi-nally and most importantly, this formula doesnot really solve the zigzag quality switching, butmerely reduces the bitrate artificially.

3.2 Comparison With BandwidthEstimation Techniques

These techniques aim to estimate the availablebandwidth at the time of the measurement.

A well-known technique is packet pair [6].The basic idea is that the sender sends a pairof packets of the same size to a destination (itcould be a specialised server or simply an awarereceiver). The destination host then responds bysending an echo for each received packet. Bymeasuring the changes in the time spacing be-tween the two packets, the sender can estimatethe available bandwidth of the network path asfollowing:

bw =s

t2 − t1(2)

where:

• bw is the bandwidth of the bottleneck link

• s is the packet size

• t1 and t2 are the arrival time of the first andsecond packet respectively.

The accuracy of this technique depends on sev-eral assumptions. The most important one is

130


that the two packets should be enqueued one af-ter the other at the bottleneck link, which is notguaranteed when a router has a non FIFO queueor when another packet is inserted between thetwo packets. Other variants of packet pair tech-nique are developed [7, 8, 9] to mitigate this ef-fect.

Another known technique is packet train [10].A burst of packets is sent between source anddestination. Only packets in the same train areused for measurement. A train is formed bypackets for which the spacing between two con-secutive received packets does not exceed someinter-packet (inter-train) gap. Like in packetpair, inter-arrival times between packets in thesame train are used for estimating the availablebandwidth.

All these methods have several drawbacks:

1. Sending/receiving additional data packetsis needed to estimate the available band-width. If video data packets themselvesare used for this, receiver must distin-guish them from other data, for example byadding a new field in the packet header.

2. Probing packets should be specifically dis-persed, i.e. they need a specific timingwhen they are sent. This makes the use ofthe video data packets themselves difficultfor probing purposes.

3. If a new connection is used for probingpackets, sender/receiver should send/listento a different socket (port).

4. Not only the sender application but also thereceiver application must be modified to beable to respond to those probing packets.

Changing both endpoints is known to bedifficult to realise in practice.

Finally, and the most important, these tech-niques have a different goal than ours. As theydo not take into account the bitrates used in thepast, they cannot avoid the zigzag.

The previous cited reasons show that cur-rent bandwidth estimation techniques are notappropriate to solve the zigzag quality switch-ing problem.

3.3 Comparison With NetworkCongestion Control

Our problem is similar to classical network con-gestion control problem, but not identical. Weconsider both window-based (written as TCP[11] in the following) and equation-based (writ-ten as TFRC [12] in the following) congestioncontrols.

In fact, both TCP/TFRC and our ZAALmethod try to solve a multi-criterion optimisa-tion problem, but the criteria involved to achievethis goal are not really identical.

Zigzag: ZAAL aims to avoid the zigzag be-tween two consecutive qualities, which occurswhen (1) the inferior quality is lower than band-width, hence no loss, hence the quality is in-creased, and (2) the superior quality is higherthan bandwidth, hence a few losses, hencethe quality is decreased to the inferior qual-ity again. TCP/TFRC have fine-grained send-ing rate; TCP, being a data transport protocol,does not pay attention to such zigzag, whileTFRC smooths the sending rate, without tryingto avoid the zigzag.

131


Losses: TCP/TFRC aim to send at the maxi-mum rate, even if this yields a few losses. On thecontrary, ZAAL aims to avoid losses as muchas possible. In reality, losses cannot be com-pletely avoided unless a very low bitrate is used.So for ZAAL it is better to maintain a qual-ity without or with few losses, instead of thenext higher quality with high loss rate. In fact,ITU.T G.1070 [13] recommends that the end-to-end IP packet loss rate in video streamingshould be less than 10%. As an example, dur-ing a video transmission ZAAL prefers a 2Mb/ssending rate without losses to a 3Mb/s sendingrate (50% more packets) with 20% losses.

Sending rate: TCP/TFRC aim to send atthe highest possible rate. This is why theyconstantly increase sending rate (using variouslaws, which differ from one TCP variant to an-other). A video adaptation method aims that too,but does not increase quality if ZAAL considers,for zigzag/loss avoidance as shown above, thatthe next higher quality should not be tried at thistime. Thus an adaptation method can be seenas quality increasing/decreasing proposition andZAAL as quality increasing-only blocker.

This comparison shows that classical con-gestion control algorithms have different goals,hence they are not an appropriate to solve thezigzag problem.

4 ZIGZAG-AVOIDING AL-GORITHM OVERVIEW

To solve the zigzag quality switching generatedby a video adaptation method, an additional spe-cific algorithm can be used, such as ZAAL.

ZAAL algorithm works by avoiding constantlyusing bitrates higher than the available band-width. For that, it maintains an average valuefor each bitrate, called successfulness in the fol-lowing. When the adaptive algorithm considersto increase bitrate (and only in this case), ZAALchecks if the successfulness of the higher bitrateis lower than a threshold, called β; if this is thecase, a higher bitrate cannot be chosen. Other-wise said, application uses a higher bitrate i onlyif its successfulness Si > β. After this process,the average successfulness is updated.

Note that ZAAL is not an adaptation method.It is used only to prevent an adaptation methodfrom frequently switching the video quality.The only information ZAAL needs comes fromthe adaptation method, whether some bitratecauses lost packets or not.

4.1 AlgorithmZAAL algorithm uses the successfulness valueeach time an adaptation period ends, which de-pends on the adaptation algorithm (e.g. 2 sec.in case of our VAAL adaptation method). Aver-age successfulness value is calculated separatelyfor each bitrate (with different weights), denotedby Si, which indicates if bitrate of index i canbe used for the next period or not. As such,this average value expresses the application lastattempts to use the corresponding bitrate. Inbrief, when a bitrate generates failed packets tothe transport protocol buffer, corresponding suc-cessfulness value is greatly reduced; when a bit-rate was successful, the successfulness value isgreatly increased; finally, when a bitrate is usedfor a long time, the successfulness values corre-sponding to higher bitrates are slowly increased.

132


As a general rule, the smaller the successfulnessaverage value, the more the corresponding bit-rate causes failed packets and application mustavoid using it.

The average successfulness Si (where i is bit-rate index) of each bitrate, which changes ac-cording to the history of that bitrate, is calcu-lated using an EWMA algorithm (ExponentialWeighted Moving Average). Using EWMA al-lows to give greater weight to recent historycompared to older history, since obviously cur-rent bandwidth is better expressed by recent bit-rate usage than by older ones. Additionally, dif-ferent weights are used, based on the bitrate in-volved.

At the beginning of a video transmission, allS values are set to 1. Then they are calcu-lated each time the application wants to adaptthe video bitrate to the available bandwidth, us-ing the following general formula:

Si = (1− α/d)Si + s(α/d) (3)

where:

• s is the successfulness at the time of mea-surement (the current “observation”) andcan be either 0 or 1. 0 value is used whenthe bitrate did not give good results (henceits successfulness average value will de-crease). 1 value is used when the bitrategave good results, either because the bit-rate did not cause failed written packets, orbecause the bitrate was not used recently(hence its successfulness average value willincrease).

• α is the degree of weighting in-crease/decrease, a constant smoothing

factor between 0 and 1. A higher αdiscounts older successfulness valuesfaster.

• d is a division factor allowing to speed upor slow down the average value increasingdepending on the bitrate involved. In ouralgorithm, d has three values: 1, 2 and 4.For s = 1, the greater the d, the slower theincreasing of the average Si value. Theywill be explained more later.

S values are arithmetic reals between 0 and 1.They can change in three cases:

1. First, when the application increases thevideo bitrate, i.e. the new bitrate k is higherthan the actual one j. This appears whenthe application does not sense lost packetsfor a while with actual video quality. Inthis case S should increase (s = 1) for allbitrates i lower than or equal to the cur-rent bitrate. Increasing speed must be high(d = 1). So:

Si|i≤j = (1− α)Si + α (4)

2. Second, when the application maintains thebitrate. This happens either when somepacket losses occur but their rate is accept-able to maintain the current quality j, orsuccessfulness of the higher bitrate k (Sk)is low and application avoids using it. Svalue increases for all qualities but withdifferent division factor values (differentspeeds). So:

• d = 1 and s = 1 (big increase) for allbitrates i lower than the current one j:

Si|i<j = (1− α)Si + α (5)

133


• d = 2 and s = 1 (small increase) forcurrent bitrate j:

Sj = (1− α/2)Sj + α/2 (6)

• d = 4 and s = 1 (very small increase)for the bitrate k = j + 1 higher thanthe current one j:

Sk(k=j+1) = (1−α/4)Sk +α/4 (7)

3. Third, application decreases the video bit-rate. This appears when the available band-width is not enough anymore for the actualbitrate (i.e. bandwidth decreases during thecurrent period), or when the applicationtries a bitrate higher than the bandwidth.In this case, average value must be reducedfor the current bitrate j, other bitrates av-erage values do not change. Hence, s = 0and d = 1 (big decrease). So:

Sj = (1− α)Sj (8)

In our experiments we intuitively set α = 0.3and β = 1 − α = 0.7. Other values were anal-ysed but either they lead to high number of adap-tation iterations for the algorithm to converge, orthey minimize its effects. Determining the bestvalues of α and β and how they affect the sta-bility and the adaptivity of ZAAL is still futurework.

4.2 DiscussionWe present in this section some characteristicsof zigzag-avoiding algorithm. To simplify re-sults, we use α = 0.3 and β = 0.7. We cannotice the following:

1. At the beginning, average values are set to1. They are greater than β = 0.7, so thereis no restriction using any bitrate, i.e. appli-cation is authorised to use all bitrates.

2. Studying the decreasing phase of the algo-rithm we can notice:

• As mentioned previously, when a bit-rate is greater than the available band-width, application avoids to use it fora while by decreasing its successful-ness average value. Based on equa-tion 8, the first time this occurs, Si =1 − 0.3 ∗ 1 = 0.7. Hence, a bitratewhich causes failed writing packetscannot be used two consecutive times.

• The smallest S value for a bitrate ican appear when it is used with Si =0.7 + ε and it leads to failed pack-ets. So, its new S value is equal toSi = 0.7 ∗ (0.7 + ε) = 0.49 + ε.

• A higher bitrate does not necessarilymean a smaller S value. When reduc-ing an S value for a bitrate i, higherbitrates do not change.

3. Studying the increasing phase of the algo-rithm we can notice:

• The maximum number of timesZAAL prevents an application to in-crease bitrate occurs when the higherbitrate k has the minimal S value ofSk = 0.49 + ε (see previous point)and ends when Sk becomes > 0.7.Using equation 7, this corresponds to

134


0.528

0.563

0.596

0.626

0.654

0.68 0.704

0.491 0.528 0.563 0.596 0.626 0.654 0.68 0.704

New

suc

cess

fuln

ess

valu

e

Current successfulness value

Successfulness value

Figure 2: Successfulness average increasingduring the biggest period of time.

7 unsuccessful attempts by the appli-cation for the higher bitrate k, fol-lowed by an 8th successful attempt.Fig. 2 shows the evolution of thisvalue: there are 7 unsuccessful at-tempts between 0.49 + ε and a valuegreater than 0.7.

• S values between 0.7 and 1 are onlypossible when the bitrate does notcause failed packets in two cases:it increases slowly beyond 0.7 whenthe quality is stable (see equation 6),or it increases quickly beyond 0.7when higher qualities are possible(see equation 5).

4. Finally, using an exponential average ratherthan a linear average allows to rememberpast values for a longer time when increas-ing average values S, and to give moreweight to recent history than to old history.

4.3 ZAAL Complexity• ZAAL is a simple and easy to implement

algorithm. Indeed, ZAAL consists of 3 if

clauses with a loop over all bitrates insideeach clause.

• ZAAL is scalable, since it has a linear com-plexity in number of bitrates (a loop onall bitrates), and also in number of clients(ZAAL is executed independently for eachof them). Moreover, it has a negligibleexecution time. Indeed, it needs to cal-culate just one value per available bitrateduring each adaptation period (e.g. each 2sec.), using a simple formula, as shownabove. Hence, using ZAAL does not reallyaffect the server processing capacity whenthe number of clients increases. The smalladditional impact of ZAAL can be easilycompensated by its other positive side (i.e.when using ZAAL, the server avoids pro-cessing packets which would otherwise belost on the network).

5 EXPERIMENTAL RE-SULTS

Fig. 3 shows the real network used to realiseexperiments with the program presented in theprevious section. A video streaming connectionis made between a sender and a receiver withwired interface for both. An intermediate ma-chine (called shaping machine in the following)is added between the sender and the receiver2.

2We preferred to add an intermediate machine sincemaking the traffic shaping on DCCP sender is not work-ing currently (see thread “DCCP BUG called” on DCCPmailing list, available at http://www.spinics.net/lists/dccp/msg04264.html), making it onthe access point is not interesting either, because it has an

135


Figure 3: Network topology used for experi-ments.

This shaping machine has two interface cards:a wired interface connected to the sender anda wireless one (54Mb/s) connected to an ac-cess point (AP). The receiver is connected tothe same AP via its wired interface. We chose awireless network in order to be nearer the real-ity, since wireless networks are commonly usedtoday to access Internet and such networks aremore challenging for the algorithms involvedin video adaptation. The video streaming usesa real video, available in four qualities 3Mb/s,2Mb/s, 1Mb/s and 512kb/s, as mentioned be-fore. The video has 180s. Detailed informa-tion about experiment parameters are given inappendix A.

Two series of tests are done. For the firstseries (traffic shaping series), just one flow ispresent at any moment during the video trans-mission, which can thus use all the availablebandwidth. On the other hand, the output band-width of the shaping machine is changed threetimes to simulate a variable bandwidth: 600kb/sfor the first minute, 2300kb/s for the secondminute, and traffic shaping was stopped for thelast minute (hence the output bandwidth is theoriginal wireless bandwidth). This series allowsto see the effect of ZAAL in a network wherebandwidth changes over time.

older linux kernel, and making it on the receiver machinedoes not give accurate results.

For the second series, two numbers of concur-rent flows are present during the whole trans-mission: five and ten flows. In fact, fiveflows at maximum bitrate are comparable to thebandwidth of the network (5*3Mb/s = 15Mb/s,which is about the bandwidth provided by aclassical 54Mb/s wireless network), while 10flows clearly exceed the bandwidth. This allowsto see what happens when multiples flows sensethe available bandwidth, especially to check ifthis leads to a wide oscillation in performance.In fact, as the number of flows increases fromfive to ten, the number of video adaptation deci-sions will increase, allowing thus to better verifythe usefulness of ZAAL.

All the flows use VAAL [2] as adaptation al-gorithm. Additionally, either all the flows useZAAL, or none of them.

The series above consist in executing thesame experiments five times. In fact, dependingon the network conditions one method can takeadvantage over the others just because during itsexperiment the network conditions were better;with five repetitions, the chance for somethingto happen again and again is very small. Theoverall average of all experiment repetitions ispresented here. Note that there is no retransmis-sion for lost packets in all our tests (as given byDCCP).

This section aims to check if ZAAL avoidszigzag quality switching, and using ZAAL leadsto worst, similar or better quantitative results.

5.1 Zigzag AvoidanceIn this section we present the quality variationwith and without ZAAL. In the following fig-ures, the x-axis represents the time from 0 to

136


180s, the duration of a video transmission, andthe y-axis shows the video bitrate (with or with-out ZAAL).

5.1.1 One flow in case of traffic shaping

As expected, ZAAL minimises the zigzag ef-fect: during the first minute in Fig. 4(a) (whereZAAL is not used), the video bitrate is con-tinuously toggling between 0.5 and 1Mb/s (thebandwidth is 600kb/s), while when ZAAL isused, in Fig. 4(b), application uses 0.5Mb/s bit-rate most of the time. The same conclusions canbe drawn from the second minute. During thelast minute, bandwidth is wide enough to sup-port 3Mb/s, and ZAAL finally allows this bit-rate.

Further analysis of Fig. 4(b) (with ZAAL)confirms the useful properties of ZAAL algo-rithm. First, application waits for at least 2 pe-riods of time before trying a bitrate which hasrecently caused losses (e.g. at the beginning,1Mb/s did not work between 0s and 2s, henceit was retried not at 4s, but at 6s). Second, whena bitrate causes losses for several consecutivetimes, application waits more and more time toretry it (e.g. 1Mb/s at 32s, then at 46s, and fi-nally at 64s). Third, the maximum period dur-ing which the video quality was prevented to in-crease is 14s, as shown in section 4.2, point 3(e.g. the first unsuccessful attempt at 50s fol-lowed by the next successful attempt at 64s);during that time there were no losses (bandwidthmuch higher than bitrate), however ZAAL cor-rectly prevented the bitrate increasing.

More precisely, Tab. 1 presents the number ofzigzags during the first and the second minutefor the five repetitions done with and with-

out ZAAL (there is no difference during thethird minute). It is clear that ZAAL leads tomuch fewer zigzags in each of the repetitions,for example in the first repetition the numberof zigzags is 4 for ZAAL against 13 withoutZAAL in first minute, and 0 against 12 in secondminute, so 84% less in total. In average for ofall the five repetitions, ZAAL leads to between75% (the third repetition) and 86% (the fifth rep-etition) fewer zigzags number during the trans-mission. Naturally, this has a very big impact onthe video quality perceived.

5.1.2 Second series: five and ten concurrentflows

In the second series of tests the bandwidth is notlimited in any manner. Results of the five rep-etitions of these experiments are presented inTab. 2 for five concurrent flows and Tab. 3 forten concurrent flows. These tables give the to-tal number of zigzags (the sum for all the flows)during the first, second and third minute of thevideo transmission. Dividing the time in thisway allows to confirm that the zigzags are dis-tributed and not concentrated in one interval oftime.

Five flows:In these experiments the server is transmit-

ting five concurrent flows at the same time, andthe available bandwidth is theoretically higherthan the data rate needed for all flows with thehighest available bitrate of our experiments. Asthe video adaptation method senses the avail-able bandwidth, the highest bitrate is used mostof the time (the bitrate is rarely changed) and

137


0

0.5

1

1.5

2

2.5

3

0 20 40 60 80 100 120 140 160 180

0

20

40

60

80

100

120

Bitr

ate

of tr

ansm

itted

vid

eo (

Mb/

s)

Time (s)

adapted video bitrate

(a) without ZAAL: many zigzags occur

0

0.5

1

1.5

2

2.5

3

0 20 40 60 80 100 120 140 160 180

0

20

40

60

80

100

120

Bitr

ate

of tr

ansm

itted

vid

eo (

Mb/

s)

Time (s)


(b) with ZAAL: few zigzag occur

Figure 4: Quality adaptation for one flow in case of traffic shaping, under the same network con-ditions.

138


Table 1: Number of zigzags with and without ZAAL for the five repetitions in case of trafficshaping.

Repetition number Method First minute Second minute Total Reduction1 Without ZAAL 13 12 25

With ZAAL 4 0 4 84%2 Without ZAAL 13 11 24




With ZAAL 3 0 3 86%Total Without ZAAL 65 51 116

With ZAAL 19 2 21 82%

the received video does not suffer from qual-ity switching. Tab. 2 confirms this idea wherethe total number of zigzags with and withoutZAAL is between 0 and 2 for nearly all flowsin all repetitions except for flows without us-ing ZAAL in the first repetition where the to-tal number of zigzags reaches 31. This meansthat when the available bandwidth is higher thanthe data rate, using a zigzag avoiding algorithmsuch as ZAAL is not really necessary; it is how-ever useful especially if the algorithm does notconsume CPU or network resources, which isthe case for ZAAL.

Ten flows:This test is similar to the previous one but

with ten concurrent flows; the available band-width is smaller than the data rate of all flowswith the highest available bitrate. Compari-son of zigzags number with and without usingZAAL is presented in Tab. 3. This table showsfirst that video quality is not stable anymore andthe number of zigzags is much greater than the

tests with five flows. Second, using ZAAL leads(as for the first series with traffic shaping) to be-tween 83% and 87% fewer zigzags and about85% in average when ZAAL is used. As a con-clusion, ZAAL minimises the unnecessary os-cillation in video quality.

In these experiments with ten flows we no-ticed that all flows have the same tendency whenchoosing video bitrates. Fig. 5 shows the ten-dency of one flow out of the ten concurrentflows. We can see that the bitrate changes of-ten between 1Mb/s and 2Mb/s, which indicatesthat one flow does not stay all the time at a highbitrate (e.g. 3Mb/s); if this happened, it wouldreduce the available bandwidth for other flows.Also, like in the previous test with traffic shap-ing, application adapts often video quality whileavoiding bitrates causing lost packets (e.g. inFig. 5, 3Mb/s bitrate causes lost packets at 26s,then it is not used until 68s). At the same time,it avoids frequent changes in video bitrate dur-ing transmission while improving the use of thebandwidth.

139


Table 2: Number of zigzags (total for all flows) with and without ZAAL for the five repetitions incase of five concurrent flows.

Repetition num Method First minute Second minute Third minute Total1 Without ZAAL 7 7 17 31

With ZAAL 0 0 0 02 Without ZAAL 0 0 0 0




With ZAAL 0 0 0 0Avg Without ZAAL 7 8 18 33

With ZAAL 3 1 0 3

Table 3: Number of zigzags (total for all flows) with and without ZAAL for the five repetitions incase of ten concurrent flows.

Repetition Method First minute Second minute Third minute Total Reduction1 Without ZAAL 89 102 94 285

With ZAAL 18 6 11 35 87.7%2 Without ZAAL 83 95 91 269




With ZAAL 18 18 15 51 83.5%Total Without ZAAL 431 506 491 1428

With ZAAL 94 53 62 209 85.4%

140


0

0.5

1

1.5

2

2.5

3

3.5

0 20 40 60 80 100 120 140 160 180

0

20

40

60

80

100

120B

itrat

e of

tran

smitt

ed v

ideo

(M

b/s)

Time (s)


Figure 5: Quality adaptation with ZAAL for flow number 1 in ten concurrent flows test.

Page 1

Flow1Flow2Flow3Flow4Flow5Flow6Flow7Flow8Flow9Flow10

Figure 6: Percentage of sent packets by eachflow at application layer using ZAAL: the per-centages are nearly equal.

This test also checks the fairness of ZAAL.Fig. 6 shows the percentage of sent packetsby each flow at application layer when usingZAAL. It shows that ZAAL maintains the fair-ness among concurrent flows on server (i.e. allflows have nearly equal percentage of sent pack-ets). On the other hand, the fairness on thenetwork is guaranteed by using a TCP-friendlycongestion control.

5.2 Performance Comparison

Even if reducing packet loss rate is not the maingoal of ZAAL, we investigate how ZAAL af-fects it. For that, we compare again the sameapplication with ZAAL and without ZAAL. Weconsider that if a new transmission method, likeours, is able to maximise the number of re-ceived packets while minimising the differencebetween the number of sent and received pack-ets, it will ameliorate the received video quality.Thus, we compare on the one hand the numberof received packets, and on the other hand thenumber of lost packets, in average. It should benoted that, as already known, video quality overnetwork transmission is more affected by packetlosses rather than video bitrate value.

In the following figures, the x-axis representsthe repetition number, followed by the averageof all repetitions. The number of sent and re-ceived packets is put on the y-axis (and they usethe same point type to distinguish them moreeasily; of course, the curve of received packetsis always lower than the curve for sent packets).

141


Note that, even if all the curves are put on thesame graph, the execution is done at differenttimes. Also, even if the curves use lines for bet-ter visualisation, the flows are independent.

5.2.1 One flow in case of traffic shaping

Fig. 7 presents results of this series of exper-iments. It is clear that the number of receivedpackets is smaller when ZAAL is used (byabout 6% in average, 40460 received packets forZAAL compared to 42961 without ZAAL), be-cause of ZAAL preventing high bitrate for someperiod. On the other hand, when ZAAL is usedthe flow has in average 38% fewer lost pack-ets (6104 with ZAAL compared to 3819 with-out ZAAL, under the same network conditions).In general, it is much better to receive 6% fewerpackets and have 38% fewer losses, so we canconsider that using ZAAL improves the videoquality perceived too.

5.2.2 Five flows

Results of this test are shown in Fig. 8. Thisfigure shows that ZAAL is clearly better in someexperiments (e.g. 1 and 5), while without ZAALis clearly better in others (e.g. 2 and 4). Lookingat the average, ZAAL is slightly better in termsof the number of received packets and packetsloss rate. As a conclusion of this test, we can saythat when the available bandwidth is sufficientfor all flows, the quantitative results are nearlyequal with and without ZAAL.

5.2.3 Ten flows

The average number of sent and received pack-ets of the ten concurrent flows gives yet betterresults for ZAAL (see Fig. 9). Except for rep-etition 2, all repetitions have higher number ofreceived packets when ZAAL is used. More-over, packet loss rate is smaller for ZAAL in allrepetitions, even for 2. In average, number ofreceived packets are about 7% greater in caseof ZAAL (32477 compared to 30280), and lossrate is about 57% smaller too (4236 comparedto 9825). As a conclusion, ZAAL is better interms of sent and received packets, avoiding thezigzag in the same time.

From the results of this section we can con-clude that ZAAL is better and, even if some-times its number of received packets is smaller,it reduces the rate of lost packets while maximis-ing the use of the bandwidth.

6 CONCLUSIONS ANDPERSPECTIVES

This article has presented a simple brandnew method to avoid the undesirable constantswitching in quality occurring during a videostreaming using content adaptation. It is a gen-eral solution, since it can be integrated to anyadaptation method, and no matter if the video isencoded in multiple qualities or in multi-layers.The proposed solution uses a history of qual-ity successfulness to infer if a quality shouldbe chosen at a given time. It is a non intrusivemethod, i.e. it does not change the video trans-mission and does not need feedbacks from thenetwork. Experiments confirm that with our so-

142


0

10000

20000

30000

40000

50000

60000

70000

1 2 3 4 5 Avg

Num

ber

of s

ent a

nd r

ecei

ved

pack

ets

Repetition number

VAAL sent packetsZAAL sent packets

VAAL recv packetsZAAL recv packets

Figure 7: VAAL vs ZAAL in traffic shaping test.

0

10000

20000

30000

40000

50000

60000

70000

1 2 3 4 5 Avg

Num

ber

of s

ent a

nd r

ecei

ved

pack

ets

Repetition number



Figure 8: VAAL vs ZAAL in five concurrent flows test.

143


0

10000

20000

30000

40000

50000

60000

70000

1 2 3 4 5 Avg

Num

ber

of s

ent a

nd r

ecei

ved

pack

ets

Repetition number



Figure 9: VAAL vs ZAAL in ten concurrent flows test.

lution the zigzag quality switching appears veryrarely, and that it has positive results on videoquality.

A perspective of our work is to considera hybrid solution, which uses a bandwidthestimation method (to decide whether to in-crease or not the quality) when the maximumperiod of non-increasing with our method isreached. However, a very interesting futurework is to analyse a more general algorithmwith VAAL/ZAAL constraints, but applicable tothe whole class of network congestion controlmethods.

References[1] Wassim Ramadan, Eugen Dedu, and Julien

Bourgeois. Avoiding zigzag quality switchingin real content adaptive video streaming. In In-ternational Conference on Digital Informationand Communication Technology and Its Appli-

cations (DICTAP), 1, pages 421–435, Dijon,France, June 2011. CCIS 167.

[2] Wassim Ramadan, Eugen Dedu, and JulienBourgeois. VAAL, video adaptation at appli-cation layer and experiments using DCCP. InWPMC, 13th Int. Symposium on Wireless Per-sonal Multimedia Communications, pages 1–5,Recife, Brazil, October 2010.

[3] Steven McCanne, Van Jacobson, and MartinVetterli. Receiver-driven layered multicast.SIGCOMM Computer Communication Review,26:117–130, August 1996.

[4] Wu-chi Feng. On the efficacy of quality, framerate, and buffer management for video stream-ing across best-effort networks. Journal ofHigh Speed Networks, 11:199–214, 2002.

[5] Nick Feamster, Deepak Bansal, and Hari Bal-akrishnan. On the interactions between layeredquality adaptation and congestion control for

144


streaming video. In 11th International PacketVideo Workshop, Kyongiu, Korea, April 2001.

[6] V. Jacobson. Congestion avoidance and con-trol. SIGCOMM Computer CommunicationReview, 18:314–329, August 1988.

[7] Robert L. Carter and Mark E. Crovella.Measuring bottleneck link speed in packet-switched networks. Performance Evaluation,27-28:297–318, October 1996.

[8] Srinivasan Keshav. Packet-pair flow con-trol. IEEE/ACM Transactions on Networking,February 1995.

[9] Constantinos Dovrolis, Parameswaran Ra-manathan, and David Moore. Packet-dispersion techniques and a capacity-estimation methodology. IEEE/ACMTransactions on Networking, 12:963–977,December 2004.

[10] Raj Jain and Shawn A. Routhier. Packet trains:Measurements and a new model for computernetwork traffic. IEEE Journal on Selected Ar-eas in Communications, 4:986–995, 1986.

[11] Jon Postel. Transmission control protocol,September 1991. RFC 793.

[12] Sally Floyd, Mark Handley, Jitendra Padhye,and Joerg Widmer. TCP Friendly Rate Con-trol (TFRC): Protocol specification, September2008. RFC 5348.

[13] ITU-T. Opinion model for video-telephony ap-plications, April 2007.

A Experiment parametersThe real network parameters used for the exper-iments are presented in table 4.

Parameter name Parameter valueExperiments place In buildingPacket size 1024 bytesPC1 (sender): Wired cardProduct 82567LM-3Technology Gigabit ConnectionVendor Intel CorporationPC2 (shaper machine): Wireless cardProduct BCM4312Technology 802.11b/gVendor Broadcom CorporationPC2 (shaper machine): Wired cardProduct RTL8111/8168BTechnology Gigabit ConnectionVendor RealtekPC3 (receiver): Wired cardProduct BCM5755MTechnology Gigabit ConnectionVendor Broadcom CorporationPC1,2&3 Wired bandwidth 100Mb/sPC1,2&3 OS Linux (Ubuntu 64bits)PC1,2&3 OS kernel 2.6.35 genericDCCP Included in the kernelWireless bandwidth 54Mb/sDistance (AP↔ PC2) 50cmShared with other users no

Table 4: Experiment parameters.

145

Documents

Avoiding quality oscillations during adaptive streaming of video