AVOIDING QUALITY OSCILLATIONS DURING ADAPTIVE STREAMING OF VIDEO

8/12/2019 AVOIDING QUALITY OSCILLATIONS DURING ADAPTIVE STREAMING OF VIDEO

1/20


2/20

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

timedia data at the user and play the video when

the buffer has sufcient data; because the bufferempties, the user will be confronted to manyplay/pause during the streaming. Both cases areunpleasant to the user eye: the rst has the ad-vantage to watch a uid 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 network characteristics, hence to improve the video qual-ity perceptible by the nal 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 bitrate

control 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 zigzag

quality switching .Few papers treat this issue, and they do

not solve it completely. This paper presentsa solution, called ZAAL ( Z igzag AvoidanceAlgorithm), to this problem 1. 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 2

formulates 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-

TIONThe zigzag quality switching is the fact that an adaptive video streaming sender applicationkeeps switching the video quality between twovalues, especially when one value is greater and the 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 nal 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


3/20


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 qualityuctuation, 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 lls 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 ow on the sender side.

video adaptation method. It uses transport pro-tocol buffer overow as a method to nd 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 bandwidth

and 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 rst 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


4/20


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 Methods

One 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:

EF R =N 1

i =1

fps i P qchanges (max (i W, 0), i )N (1)

where fps i 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 of quality 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 of the jerkiness. For example, 10 quality changesin the rst 2 seconds of a video of 1 minute

129


5/20


are worse visually than 10 quality changes dis-

persed through the whole video. The goal of EWMA, 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 xed (same size), while in our casewe use a sliding and dynamic window.

Finally, our goal is not to limit the number of quality changes, but to avoid quality increaseswhich lead to quality decreases right afterwards.For all these remarks, the formula in this paper

is 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 R

l , 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 of the transmission rate for AIMD, and it is Rsmaller 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 signicantly reduced. Fi-nally and most importantly, this formula doesnot really solve the zigzag quality switching, butmerely reduces the bitrate articially.

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 rst andsecond packet respectively.The accuracy of this technique depends on sev-eral assumptions. The most important one is

130


6/20


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 themselves

are used for this, receiver must distin-guish them from other data, for example byadding a new eld in the packet header.

2. Probing packets should be specically dis-persed, i.e. they need a specic timingwhen they are sent. This makes the use of the video data packets themselves difcultfor probing purposes.

3. If a new connection is used for probing

packets, sender/receiver should send/listento a different socket (port).

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

Changing both endpoints is known to be

difcult 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 ne-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


7/20


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 this

time. 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-cic algorithm can be used, such as ZAAL.

ZAAL algorithm works by avoiding constantly

using 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 S i > . 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 Algorithm

ZAAL algorithm uses the successfulness value

each 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 S i , 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; nally, when a bitrate is usedfor a long time, the successfulness values corre-sponding to higher bitrates are slowly increased.

132


8/20


As a general rule, the smaller the successfulness

average value, the more the corresponding bit-rate causes failed packets and application mustavoid using it.

The average successfulness S i (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:

S i = (1

/d )S i + 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, or

because 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 S i 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:

S i | i j = (1 )S i + (4)2. Second, when the application maintains the

bitrate. 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 (S k )is low and application avoids using it. S value increases for all qualities but withdifferent division factor values (different

speeds). So:

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


9/20


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

S j = (1 / 2)S j + / 2 (6)

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

S k (k = j +1) = (1 / 4)S k + / 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:

S j = (1 )S j (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 to

1. 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 rst time this occurs, S i =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 S i =0.7 + and it leads to failed pack-ets. So, its new S value is equal toS i = 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 of S k = 0.49 + (see previous point)and ends when S k becomes > 0.7.Using equation 7, this corresponds to

134


10/20


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 implementalgorithm. Indeed, ZAAL consists of 3 if

clauses with a loop over all bitrates inside

each 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 receiver 2.

2We preferred to add an intermediate machine sincemaking the trafc 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


11/20


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 to

the 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 rstseries (trafc shaping series), just one ow 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 rst minute, 2300kb/s for the secondminute, and trafc shaping was stopped for thelast minute (hence the output bandwidth is the

original 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 ows are present during the whole trans-mission: ve and ten ows. In fact, veows 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 10ows clearly exceed the bandwidth. This allowsto see what happens when multiples ows sensethe available bandwidth, especially to check if this leads to a wide oscillation in performance.In fact, as the number of ows increases fromve to ten, the number of video adaptation deci-sions will increase, allowing thus to better verifythe usefulness of ZAAL.

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

The series above consist in executing thesame experiments ve times. In fact, dependingon the network conditions one method can takeadvantage over the others just because during its

experiment the network conditions were better;with ve 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 Avoidance

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

136


12/20


180s, the duration of a video transmission, and

the y-axis shows the video bitrate (with or with-out ZAAL).

5.1.1 One ow in case of trafc shaping

As expected, ZAAL minimises the zigzag ef-fect: during the rst 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 nally allows this bit-rate.

Further analysis of Fig. 4(b) (with ZAAL)conrms 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 -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 rst 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 of zigzags during the rst and the second minutefor the ve repetitions done with and with-

out ZAAL (there is no difference during the

third minute). It is clear that ZAAL leads tomuch fewer zigzags in each of the repetitions,for example in the rst repetition the numberof zigzags is 4 for ZAAL against 13 withoutZAAL in rst minute, and 0 against 12 in secondminute, so 84% less in total. In average for of all the ve repetitions, ZAAL leads to between75% (the third repetition) and 86% (the fth 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: ve and ten concurrentows

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

Five ows:In these experiments the server is transmit-

ting ve concurrent ows at the same time, andthe available bandwidth is theoretically higherthan the data rate needed for all ows 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


13/20


(a) without ZAAL: many zigzags occur

(b) with ZAAL: few zigzag occur

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

138


14/20


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

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 conrms this idea wherethe total number of zigzags with and withoutZAAL is between 0 and 2 for nearly all owsin all repetitions except for ows without us-ing ZAAL in the rst repetition where the to-tal number of zigzags reaches 31. This means

that 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 ows:This test is similar to the previous one but

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

tests with ve ows. Second, using ZAAL leads(as for the rst series with trafc 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 ows we no-

ticed that all ows have the same tendency whenchoosing video bitrates. Fig. 5 shows the ten-dency of one ow out of the ten concurrentows. We can see that the bitrate changes of-ten between 1Mb/s and 2Mb/s, which indicatesthat one ow does not stay all the time at a highbitrate (e.g. 3Mb/s); if this happened, it wouldreduce the available bandwidth for other ows.Also, like in the previous test with trafc 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


15/20


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

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 ows) with and without ZAAL for the ve repetitions incase of ten concurrent ows.

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


16/20


Figure 5: Quality adaptation with ZAAL for ow number 1 in ten concurrent ows test.

Flow1

Flow2

Flow3

Flow4

Flow5

Flow6

Flow7

Flow8

Flow9

Flow1

Figure 6: Percentage of sent packets by eachow 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 ow at application layer when usingZAAL. It shows that ZAAL maintains the fair-ness among concurrent ows on server (i.e. allows 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 gures, 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


17/20


Note that, even if all the curves are put on the

same graph, the execution is done at differenttimes. Also, even if the curves use lines for bet-ter visualisation, the ows are independent.

5.2.1 One ow in case of trafc 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 ow 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 video

quality perceived too.

5.2.2 Five ows

Results of this test are shown in Fig. 8. Thisgure 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 sufcientfor all ows, the quantitative results are nearlyequal with and without ZAAL.

5.2.3 Ten ows

The average number of sent and received pack-ets of the ten concurrent ows gives yet betterresults for ZAAL (see Fig. 9). Except for rep-etition 2, all repetitions have higher number of received packets when ZAAL is used. More-over, packet loss rate is smaller for ZAAL in allrepetitions, even for 2. In average, number of received 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 conrm that with our so-

142


18/20


Figure 7: VAAL vs ZAAL in trafc shaping test.

Figure 8: VAAL vs ZAAL in ve concurrent ows test.

143


19/20


Figure 9: VAAL vs ZAAL in ten concurrent ows 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 bandwidth

estimation 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 421435, 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 15,Recife, Brazil, October 2010.

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

[4] Wu-chi Feng. On the efcacy of quality, framerate, and buffer management for video stream-

ing across best-effort networks. Journal of High Speed Networks , 11:199214, 2002.

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

144


20/20


streaming video. In 11th International Packet

Video Workshop , Kyongiu, Korea, April 2001.

[6] V. Jacobson. Congestion avoidance and con-trol. SIGCOMM Computer Communication Review , 18:314329, August 1988.

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

[8] Srinivasan Keshav. Packet-pair ow 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/ACM Transactions on Networking , 12:963977,December 2004.

[10] Raj Jain and Shawn A. Routhier. Packet trains:Measurements and a new model for computernetwork trafc. IEEE Journal on Selected Ar-eas in Communications , 4:986995, 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 specication, September2008. RFC 5348.

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

A Experiment parameters

The 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-3

Technology Gigabit ConnectionVendor Intel CorporationPC2 (shaper machine): Wireless cardProduct BCM4312Technology 802.11b/gVendor Broadcom CorporationPC2 (shaper machine): Wired cardProduct RTL8111/8168BTechnology Gigabit ConnectionVendor Realtek PC3 (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