A Novel Play-out Algorithm for HTTP Adaptive Streaming
aa r X i v : . [ c s . N I] O c t A Novel Play-out Algorithm for HTTP Adaptive Streaming
Arkadiusz BiernackiInstitute of Computer ScienceSilesian University of TechnologyAkademicka 1644-100 Gliwice, PolandE-mail: [email protected] 27, 2018
Abstract
In the paper, we proposed a novel algorithm dedicated to adaptive video streaming basedon HTTP. The algorithm employs a hybrid play-out strategy which combines two popularapproaches: an estimation of network bandwidth and a control of a player buffer. Theproposed algorithm was implemented in two versions which differ in the method of handlingfluctuations of network throughput.The proposed hybrid algorithm was evaluated against solutions which base their play-outstrategy purely on bandwidth or buffer level assessment. The comparison was performed inan environment which emulated two systems: a Wi-Fi network with a single immobile nodeand HSPA (High Speed Packet Access) network with a mobile node. The evaluation showsthat the hybrid approach in most cases achieves better results compared to its competitors,being able to stream the video more smoothly without unnecessary bit-rate switches. How-ever, in certain network conditions, this score is traded for a worse throughput utilisationcompared to other play-out strategies.
Keywords:
Video streaming, Adaptive video, Performance evaluation
During the past years, web based video sharing services like YouTube, Hulu or Dailymotion havebecome very popular. The users of YouTube, which allows for the distribution of user-producedmultimedia content, alone request millions of videos every day [1]. Consequently, popularity ofthis kind results in a drastic shift in Internet traffic statistic, which reports increase in trafficfrom Web-based video sharing services. It is estimated that traffic will account for about 80%to 90% of the global Internet traffic in a next few years, according to the recent report publishedby Cisco [2].Video streaming in the above mentioned services is either web-based or HTTP-based; there-fore, being transported using TCP. HTTP and TCP are general purpose protocols and were notprimarily designed for streaming of multimedia. Thus, attempts are being made to adapt deliv-ery of multimedia content to the Internet environment. One of such attempts tries to introducean additional layer of application control to transmitted video traffic. Since TCP is designedto deliver data at the highest available transmission rate, it may sometimes be reasonable fora sender to provide additional flow control if it is not strictly necessary for application data toreach a receiver as fast as the TCP would otherwise allow. Therefore, an application may limitthe rate at which the data is transmitted, and, if the video bit-rate is lower than the end-to-end1vailable bandwidth, the traffic characteristic will not resemble the characteristics of a standardTCP flow. Furthermore, modern video players implement stream-switching (or multi bit-rate):the content, which is stored at the web server, is encoded at different bit-rate levels, then anadaptation algorithm selects the video level, which is to be streamed, based on a state of anetwork environment or on a state of a video player.When the judgment is based on the state of the network environment, the video clientestimates how fast the server can deliver video (i.e. the available capacity), e.g. by measuringarrival rate of video data. Then the client choses the video bit-rate which corresponds to theestimated network throughput. If it selects a video bit-rate that is too high, the viewer willexperience re-buffering events, i.e. a playback will be suspended because the data transmissionwill not keep pace with a video bit-rate. If it picks a video bit-rate that is too low, a viewer willexperience suboptimal video quality and part of the network bandwidth will be wasted.When the decision is based on the state of the video player, the algorithm tries directly ob-serve and control the playback buffer instead of estimating network capacity, believing that thebuffer occupancy contains a lot of information and is a controllable variable. It is assumed thatthe buffer occupancy reflects the end-to-end system capacity, including current load conditionsof the network and its rate of change reflects the mismatch between the network throughputand the requested video bit-rate.In this work, we propose a new hybrid algorithm which combines the two above approaches:the bandwidth estimation and the buffer control. We assume that the hybrid solution will exploitstrengths of both approaches and it will avoid their weaknesses. We compare performanceof the hybrid solution with the two above described approaches subjecting them to variablenetwork throughput, which is commonly encountered in wireless and mobile networks. Duringthe performance evaluation of the algorithms, we measure how often the player buffer runsout, how long it takes to re-start the video transmission, how efficiently the algorithm utilisesavailable network throughput, and finally, how often the player switches between different videorates.We conduct this performance study using an emulation model. The emulation approachallows us to methodologically explore the behaviour of the examined system over a wide rangeof parameter settings, which would be a challenging task if we conducted such experiments onlyon a real-network. Simultaneously, as the emulation is performed in a laboratory environment,we are able to preserve much of the network realism because we conduct experiments using realhardware and software, which allows us to maintain a high level of accuracy for the obtainedresults.
One of the popular video transmission method is a progressive download, which is simply atransfer of a video file from an HTTP server to a client where the client may begin playbackof the file before the download is completed. However, as the HTTP server progressively sends(streams) the whole video content to the client and usually does not take into account howmuch of the data has been already sent in advance, an abundance of data can overwhelm thevideo player and lead to a large amount of unused bytes if a user interrupts the video play-out[3]. To avoid such undesirable situation, the video file is divided into chunks of fixed lengthand the server pushes them to the client at a rate little higher than the video-bit rate of thetransmitted content. As a result, the transmitted traffic creates an ON-OFF pattern, whereON and OFF periods have constant length. 2 ideoencoder
High quality video
Web server
Multiple bit rate
Web player
Quality feedbackVideo chunksManifest fi le Figure 1: Architecture of a video adaptive system based on HTTPThe extension of this idea is an adaptive streaming, which offers more flexibility when anetwork environment is less stable, e.g. in wireless mobile networks. With this approach, it ispossible to switch the media bit rate (and hence the quality) after each chunk is downloaded andadapt it to the current network conditions [4]. This technique has commenced the developmentof a new generation of HTTP-based streaming applications which implement client-side play-out algorithms, trying to deliver a continuous stream of video data to end users by mitigatingunfavourable network conditions. In this approach, a video stream is also divided into segments,but this time they are encoded in multiple quality levels, called representations, as drafted inFig. 1. The algorithm deciding which segment should be requested in order to optimize theviewing experience is a main component and a major challenge in adaptive streaming systemsbecause the client has to properly estimate, and sometimes even predict, network conditions,e.g. the dynamic of available throughput. Furthermore, the client has also to control a fillinglevel of its local buffer in order to avoid underflows resulting in playback interruptions.The stream-switching technique is employed today less or more in some proprietary videoplayers, among others in Apple HTTP-based streaming [5], Microsoft IIS Smooth Streaming[6] or Adobe Dynamic Streaming [7]. Moreover, the technique is also adopted by the DynamicAdaptive Streaming over HTTP (DASH), which is a new MPEG standard pursuing the inter-operability between devices and servers of various vendors [8].
As it was already mentioned, the bandwidth estimation algorithm tries to adjust a bit-rateof video to the measured network throughput. As the cited in the section 2.1 adaptive videosystems are proprietary and their owners do not give many details about the employed algo-rithms, we used the adaptive streaming algorithm, with some small modifications, which isimplemented in the open-source software described in [9]. The approach is relatively simpleand its main points were summarised in Algorithm 1. The examined algorithm calls a functionwhich measures average network throughput n b in a certain time window ∆ T . This window canbe considered as a parameter of the algorithm and it may be stretched or shortened in order tooptimise streamed video quality. When the video bit-rate v b , which is needed for a smooth videoplay-out, is lower than the computed average network throughput n b reduced by ∆ L , line 2,the algorithm reports that the video quality level q may be increased, i.e. the chunk downloadmodule may ask the server for bigger chunks, encoded in higher quality. When the throughputis not sufficient for the given level of video quality, line 7, the opposite situation takes place: thequality level q is decreased and the download module is instructed to obtain chunks of poorerquality what simultaneously demands less network throughput. The parameter ∆ L marks aregion of network throughput for which there is no need to switch the quality to a higher level.As a result, the parameter plays a stabilising role and prevents switching the quality levels toofrequently, which could have a negative impact on the overall video quality perceived by users.3he constants Q max and Q min define a range of available levels of the quality. Input: q – current video quality level v b – video bit rate∆ T – time window for measurement of network throughput n b ← getNetworkBandwidth(∆ T ) if v b < n b − ∆ L then if q < Q max then q ← q + 1 end if end if if v b > n b then if q > Q min then q ← q − end if end if return q Algorithm 1:
Adaptation based on bandwidth estimationThe rate adaptation algorithm might work fairly well for the case when the player does notshare a connection with other flows, network resources are stable and do not fluctuate. Sincecapacity is measured using an average of recent throughput, the estimate is typically not thesame as the true current available capacity. This mismatch results in undesirable behaviourof the streaming algorithms which can be both too conservative and too aggressive. Recentstudies have reported many examples of an inaccurate bandwidth estimation while a videoclient competed against another video client, or against long-lived TCP flow [10]. In otherstudies, e.g. in [11], it was observed that competing streams behaved instable and unfair amongeach other what led to significant video quality variation over time. Therefore, some researchworks, e.g. [12][13], try to improve the algorithm by predicting the future bandwidth, while theothers, e.g. [14][15][16], propose an algorithm based on measurement of buffer occupancy.
The basic idea of the buffer-based reactive algorithm is to select a video bit-rate based on theamount of data that is available in the buffer of a player. Thus, when the buffer reaches acertain level, the system is allowed to increase the quality. Similarly, when draining the buffer,the selected quality is reduced if the buffer shrinks below the threshold. Hence, the quality nolonger depends directly on bandwidth availability, and during network outages, buffer under-runs and play-out interruptions may be avoided.As it was mentioned, the reactive algorithm upgrades the quality once the buffer durationreaches certain chosen thresholds. However with the increasing quality, the video bit-rate risesnon-linearly, therefore it is not practical for the buffer threshold to depend directly on theamount of data accumulated in the buffer measured in bytes, but rather on the amount of datameasured in video frames, which may be translated into number of seconds of video preloadedin the player buffer.Hence, the approach presented in Algorithm 2 conserves current video bit rate q as long asthe buffer occupancy b remains within the range denoted by B min , line 1 and B max , line 6. Thisbuffer range plays a role of a cushion which absorbs rate oscillations. If either of these high orlow limits are hit, the rate is switched up or down respectively.4 nput: b – current buffer occupancy [s] if B max < b then if q < Q max then q ← q + 1 end if end if if B min < b then if q > Q min then q ← q − end if end if return q Algorithm 2:
Adaptation based on a level of a player bufferAccording to [15], buffer reactive algorithms perform fine in many cases, but sometimesthey have tendency to too frequent oscillation between video bit rates. Therefore, the authorsrecommend optimisation of the buffer range confined by B min and B max and its adjustment tocurrent network conditions. In order to overcome the drawbacks of the solutions presented in Algorithms 1 and 2, we joinedtheir functionality obtaining a hybrid solution, proposed in Algorithm 3, which utilises allinformation available to the bandwidth estimation based and buffer reactive algorithms. Whenswitching the video bit-rate up, the algorithm is cautions and takes into account both the bufferoccupancy and the network throughput, refer to the line 1.Furthermore, to protect users from video-bit rate oscillations, we added a countermeasurein line 2 in which we check if the number of video-bit rate switches s during the last period ∆ T is within the specified limit S max . When network fluctuations are frequent, the induced by thealgorithm changes of the bit-rate have a tendency to cease, making the algorithm insensitive toa variable network environment for time dependent on S max and ∆ T . In order to avoid bufferunder-runs, this condition is only verified during the change to a higher video bit-rate.We assume that the changes of the video bit-rate are counted and updated in a separatecode. There also no reasons for both the time windows used for bandwidth measurement andcounting of bit-rate switches to be the same length ∆ T . From the user’s perspective, the key performance characteristic of a network is the QoS ofreceived multimedia content. As the video is transmitted through reliable TCP, no data willbe lost. However, there may be play-out interruptions caused by either bandwidth fluctuationsor long delays due to retransmissions after packet loss. Furthermore, when reduced networkthroughput is lower than the playback rate and the buffer will drain, the video playback willpause and wait for new video data. A user expects that delays resulting from content bufferingwill be minimized and will not occur during a normal video play. Any play-out interruptionsare annoying to end users and should be taken into account when estimating the quality of5 nput: q – current video quality level v b – video bit rate b – current buffer occupancy∆ T – time window for measurement of network throughput n b – measured network bandwidth in the period ∆ Ts – number of video-bit rate switches during the period ∆ T if v b < n b − ∆ L and B max < b then if s < S max then if q < Q max then q ← q + 1 end if end if end if if v b > n b or B min < b then if q > Q min then q ← q − end if end if return q Algorithm 3:
Hybrid adaptation based on bandwidth and buffer occupancy estimationexperience (QoE). The QoE is based on popular subjective methods reflecting human perception,as a user is usually not interested in performance measures such as packet loss probability orreceived throughput, but mainly in the current quality of the received content. However, thequality assessment is time-consuming and cannot be done in real time; therefore, we concentrateon these parameters which we believe impact the QoE at most. We rely, among others, onobjective measurement methods, introduced by us in [17][18], which for the assessment takesinto account video interruptions and its total stalling time.The first measurement of the application QoE takes into account relative total stalling time(ST) experienced by a user. Assuming that the video clip is divided into i chunks, each of themhas length ∆ t i we define: ST = X i (∆ t ′ i − ∆ t i ) , (1)where ∆ t ′ i was the time needed in the reality to play-out the i th video chunk and we assumethat t ′ i ≥ t i . It is desirable to minimize the value of the ST by a network operator or a serviceprovider.The application QoS defined in Eq. (1) did not differentiate between the cases in whicha user can experience one long stalling period or several shorter stalling periods. Thus in ouranalysis, we also use a second, complementary measurement which quantifies the number ofre-buffering events (RE) associated with every stalling period:RE = X i sgn(∆ t ′ i − ∆ t i ) . (2)In practice, if any re-buffering events occur, they will take place before the play-out of the i thvideo chunk when a player waits for its download as presented in Fig. 2.In Eq. (2), we exclude an initial buffering event which takes place at the beginning of videoplay, which is used to accommodate throughput variability or inter-packet jitters happening atthe beginning of a video play. 6nterruption ∆ t ′ i ∆ t i Figure 2: Re-buffering events during a play-out of video chunksThe measurements defined in Eqs. (1) and (2) could quite good characterise performanceof non-adaptive video system. However in our case, we can imagine an algorithm that willplay-out the stream at the minimum available bit-rate, thus minimising the values of Eqs.(1) and (2), what will lead to a relatively low video quality and poor utilisation of availablenetwork throughput. Hence, we introduce a third measurement which assesses how effectivelythe algorithm utilises available network resourcesTE = P i ( q i /Q i )∆ t i P i ∆ t i . (3)Eq. (3) computes the relation between a quality level q played by an examined algorithmto a theoretical quality level Q which is possible to achieve for given network conditions. Thecomputations take place within discrete time units ∆ t i , into which the video clip is divided,and then are averaged through the duration P i ∆ t i of the video clip.The play-out algorithm may try to maximise the measurement presented in Eq. (3) byadjusting the play-out quality to the given network conditions as frequent as it is possible. Suchbehaviour will result in rapid oscillations of the video quality, what will be negatively perceivedby users [19, 20]. For this reason, we introduce the last measurement, which counts the totalnumber of quality switches (SN) during a video play-outSN = X i | q i +1 − q i | . (4)The design goal of a play-out algorithm is to simultaneously minimise values of the mea-surements defined in Eqs. (1), (2), (4), and maximise the value of the measurement defined inEq. (3). In order to capture performance of the adaptive play-out algorithms, we prepared a test environ-ment emulating standard Internet connections encountered in Wi-Fi and HSPA networks. Theenvironment consists of: a web server, video players, a network emulator and a measurementmodule implemented in the video player, as shown in Fig. 3. The role of the web server playsApache [21], which stores the video clips as a set of chunks. As the video player, we chose VLCmedia player with the DASH plug-in [9]. Both the player and the plug-in have an open-sourcecode, thus it was possible for us to manipulate and completely change the adaptation logic with-out affecting the other components. As a consequence, the plug-in allowed us to implement andintegrate Algorithms 1, 2 and 3 and compare their performance. As the network environmentmodel, we used the network emulation node based on the built-in Linux Kernel module netem [22]. The module is capable of altering network QoS parameters such as network bandwidth orits delays; thus, it allows to test data transmission in different network environments.We transmitted several video files, acquired from [23] and presented in Table 1, throughthe simulation environment with variable network throughput. The bandwidth traces were7 mulator of networkenvironmentWeb server
Figure 3: Laboratory environment employed for the experimentsTable 1: Video clips used during the experiments
Name Genre Bitrate levelsBig Buck Bunny animation 150 kbit/s – 320x240,300 kbit/s – 480x360,600 kbit/s – 854x480,1.2 Mbit/s – 1280x720,2.5 Mbit/s – 1920x1080Elephants Dream animationRed Bull Playstreets sportThe Swiss Account sportValkaama movieOf Forest and Men movie obtained from measurements conducted in WiFi and HSPA networks. For this purpose, weimplemented a custom made analysis tool that transferred data at a fixed, configurable rateusing UDP packets. Every transmitted packet had its sequence number, enabling the receiver toprecisely detect packet loss, and a time-stamp showing when the package left the receiver. Thepackets were sent at a fixed rate, and the packet reception rate was logged. The tests measuredthe download performance as it seems to be more important than upload performance for aone-way video streaming scenario.The captured log was used as a template for the bandwidth shaper implemented in thementioned earlier netem module. In addition to bandwidth throttling, the netem module alsoadds a delay of 20 ms to WI-FI connection and 100 ms to HSPA connection to emulate theaverage latency which was experienced and measured during gathering of the throughput traces.In order to obtain desirable, average network throughputs, which were used in the experiments,the traces were rescaled. Thus, having identical bandwidth trace we were able to perform aquite fair and realistic comparison of the play-out algorithms.We believe that the above described methodology provides an attractive middle groundbetween simulation and real network experiments. To a large degree, the emulator should beable to maintain the repeatability, reconfigurability, isolation from production networks, andmanageability of simulation while preserving the support for real video adaptive applications.Using our laboratory environment, we compared the three presented solutions with theparameters specified in Table 2. The hybrid solution was applied in two versions: the base one,which tries to take advantage of network conditions in order to increase video quality withouttaking into account the buffer state of a player; and the adaptive one, which is more conservativeand increases video quality after taking not only the network state and the buffer state, but alsofrequency of previous bit-rate switches. Each compared algorithm played first 600 s of everyvideo clips presented in Table 1. 8able 2: Algorithms and their parameters used in the experiments
Algorithm ParametersBandwidth est. (Alg. 1) ∆ T = 4 s , ∆ L = 0 . n b Buffer reactive (Alg. 2) B min = 3 s , B max = 7 s Hybrid, basic (Alg. 3) ∆ T , ∆ L , B min – as above, ∆ T s = 10 s , B max =0 s , S max = infHybrid, adaptive (Alg. 3) ∆ T , ∆ L , B min , B max , ∆ T s – as above, B max =7 s , S max = 10 The output of the experiments performed in the Wi-Fi environment is presented in Fig. 4. Thenetwork throughput oscillates between about 2450 kbps and 2700 kbps with an average set to2600 kbps; however, one must notice that due to TCP/IP and other protocols overhead theeffective throughout available for the video streaming is a few percent lower.As the effective network throughput fluctuates near the highest available in the experimentvideo bit-rate, the play-out algorithm based on bandwidth estimation quite regularly switchesbetween 1200 kbps and 2500 kbps. The switches are correlated with the local minima of thenetwork throughput.The buffer reactive algorithm starts from the lowest available bit rate and, as the buffer isbeing filled with data, gradually increases the quality, reaching 2500 kbps in about 80th s ofthe playback. Then, the playback quality starts to switch between 2500 kbps and 1200 kbps;nevertheless, the oscillations are less regular and more frequent compared to the bandwidthestimation algorithm.Because the hybrid algorithm on the beginning of the play-out measures available through-put, it is able to start with a higher quality level compared to its buffer reactive competitor.Furthermore, the algorithm loses the highest quality rate less frequently, mostly in the times,when the available network throughput achieves local minima. A visual assessment may leadto a conclusion that in this particular experiment, the hybrid algorithm obtains better perfor-mance than its competitors, at least taking into account bandwidth effectiveness, which wasdefined in Eq. (3).The adaptive version of the hybrid algorithm starts its playback similarly to the buffer reac-tive algorithm: from the lowest quality, then gradually reaching the maximum. Because of thisgradual improvement of quality, the algorithm is able to maintain the streaming at 2500 kbps abit longer compared to its base version. Additionally, the algorithm spends more time streaming1200 kbps video compared to its base version, which is a result of the condition defined in line1 of Algorithm 3, which takes into account both network bandwidth and the buffer state of aplayer into consideration when switching the quality rate to higher level. This leads to a dropin throughput efficiency of the algorithm, while the number of bit-rate switches is comparableto the base version of the algorithm.The same experiments were performed for the rest of the movies listed in Table 1 and wereextended to the cases, where the network throughput was set in average to 1 Mbps and 1.5 Mbps.These values were chosen to a certain extent arbitrarily, however we took into account that inthe first case, the effective network throughput falls in the middle of 600 kbps and 1200 kbpslevels of the available video bit-rate; and in the second case, the effective network throughputis theoretically a little above the fifth defined quality level of 1200 kbps.9
Registered trace u − r Bandwidth est. u − r Buffer reactive u − r Hybrid, base u − r Hybrid, adaptive T h r oughpu t [ k bp s ] Time [s]
Figure 4: Transient comparison of the play-out algorithms in an emulated Wi-Fi environment.Average bandwidth set to 2600 kbps, video clip Big Buck Bunny (see Table 1)The averages of the relative stalling time (ST), defined in Eq. (1), are similar for all examinedalgorithms, as it was presented in Fig. 5(a). For the throughput set to 1 Mbps, the average STis between about 3 s and 5 s. With an increase of the throughput, the average ST decreases,taking values between about 3 s and 4 s for the throughput set to 1.5 Mbps, and between about2 s and 3.5 s for the throughput set to 2.6 Mbps. The main observable difference among thealgorithms is that the bandwidth estimation approach has a little higher variation compared tothe other solutions, especially for throughput set to 1 Mbps.The higher variability of the bit-rate in the case of the bandwidth estimation algorithmmay be explained when we examine the number of re-buffering events (RE) defined in Eq. (2)and presented in Fig. 5(b). During the video streaming at the lowest network throughput,the algorithm experienced at least once a re-buffering event, which influenced also the ST. There-buffering was probably caused by an overlap of two unfavourable factors: an overoptimisticestimation of the network throughput and a subsequent burst of the bit-rate in the transmittedvariable bit-rate video stream. Other algorithms did not experience buffer under-runs.The average throughput efficiency, defined in Eq. (3), for all algorithms but the adaptiveversion of the hybrid are comparable, and in most cases ranges between 65% and 80%, as itwas presented in Fig. 5(c). As expected from the transient analysis of quality traces presentedin Fig. 4, the TE for the adaptive hybrid solution is clearly lower, achieving about 65% for theaverage throughput set to 2.6 Mbps or 1.5 Mbps, and less than 60% for the throughput set to1 Mbps.The frequency of the bit-rate switching is the highest for the buffer reactive algorithm: frommore than 30 switches for the throughput set to 1 Mbps to about 25 switches for the throughputset to 1.5 Mbps and 2.6 Mbps, as shown in Fig. 5(d). However, we must note that the cautiousincrease of the bit-rate in the first minute of the play-out, see Fig. 4, influences negatively thealgorithm score. The bandwidth reactive solution achieves significantly better results, rangingfrom about 15 switches for 1 Mbps network throughput, through about 12 for 1.5 Mbps, and10 bps S t a lli ng t i m e Bandwidth est.Buffer reactiveHybrid, baseHybrid, adaptive (a) Delay
Mbps S t a lli ng e v en t s . . . . . . Bandwidth est.Buffer reactiveHybrid, baseHybrid, adaptive (b) Stalling events
Mbps E ff i c i en cy . . . . . . . Bandwidth est.Buffer reactiveHybrid, baseHybrid, adaptive (c) Efficiency
Mbps S w i t c h i ng e v en t s Bandwidth est.Buffer reactiveHybrid, baseHybrid, adaptive (d) Number of switches
Figure 5: Comparison of the play-out algorithms in an emulated Wi-Fi environmentless than 10 for 2.6 Mbps throughput. The hybrid approaches achieve the best results, experi-encing between 6 and 12 switches in the case of the base version of the algorithms, and from7 to 13 switches for the adaptive version of the algorithm. Simultaneously, these scores havethe lowest variation. Similarly to the buffer reactive solution, the score of the adaptive versionof the hybrid approach is negatively biased due to the gradual increase of the video bit-rate onthe beginning of the play-out.The next series of the experiments were performed in an emulated mobile network environ-ment based on captured traces from an HSPA system. Similarly to the Wi-Fi scenarios, on thebeginning we examine the behaviour of the play-out algorithm for a network with an averagethroughput set to 2600 kbps; however, with much wider range of its oscillations, stretchingfrom a level where the network totally collapses (being the result of e.g. signal fading) andthroughput drops to zero kbps, to situations where the throughput is higher than 5000 kbps.The beginning of the play-out, the network throughput is relatively high, therefore, the al-gorithm based on bandwidth estimation is able to serve video above its average quality. Never-theless, with deteriorating network conditions, the algorithm rapidly decreases the transmissionquality, what quite often ends up with congestions – undesired condition not met during theexperiments in the Wi-Fi network. After the network collapses, its throughput has a tendencyto shoot up, what in consequence translates to a rapid increase of the play-out quality. As aresult, the quality record has a fairly high range of oscillations in short periods of time what11
Registered trace u − r Bandwidth est. u − r Buffer reactive u − r Hybrid, base u − r Hybrid, adaptive T h r oughpu t [ k bp s ] Time [s]
Figure 6: Transient comparison of the play-out algorithms in an emulated wireless mobileenvironment. Average bandwidth set to 2600 kbps, video clip Big Buck Bunny (see Table 1)may negatively influence end users’ perception.Similarly to the behaviour of the algorithm based on bandwidth estimation, the bufferreactive algorithm also reacts nervously to the rapid throughput fluctuations. The video qualityjumps several times from 1200 kbps onto 2500 kbps, but the algorithm usually persists in servingthe video at the highest level only for a relatively short period of time. Contrary to the previousalgorithm, the buffer reactive solution handles better network collapses. The first and secondnetwork slips, which happen in about 75th s and 175th s respectively, remain almost unnoticedto users. In other similar critical situations, the algorithm struggles to keep up continuity of theplay-out, however at the cost of reduction of its bit-rate to the lowest possible level. Generally,compared to the bandwidth estimation approach, the oscillation range of the video quality is abit tighter, although the rate of the quality switches remains higher.Compared to its two predecessors, the hybrid algorithm responds more calmly to the through-put fluctuation. The algorithm is able to maintain the highest quality level longer and avoids sofrequent quality switches as the buffer reactive algorithm. Simultaneously, the hybrid solutionhandles better the throughput falls than the play-out regulated by the bandwidth estimationtechnique, being able to escape from stalls during the streaming and sudden plunges of thevideo quality.The introduction of additional hedging against frequent bit-rate switches leads to a smootherquality trace, although we may still observe a few needless tries of quality improvement. Thesmoother quality comes at a certain price: it is traded for a lower average bit-rate what trans-lates to significantly poorer efficiency of network throughput usage.Similarly to the examination of the algorithms in the Wi-Fi environment, we extended ouranalysis to the rest of the movies from Table 1. The network throughput was set in averageto 1 Mbps, 1.5 Mbps and 2.6 Mbps, which are the same values as in the case of the Wi-Fiexperiment, in order to make the comparison of the algorithms easier in these two environments.12 bps S t a lli ng t i m e Bandwidth est.Buffer reactiveHybrid, baseHybrid, adaptive (a) Delay
Mbps S t a lli ng e v en t s . . . . . . . Bandwidth est.Buffer reactiveHybrid, baseHybrid, adaptive (b) Stalling events
Mbps E ff i c i en cy . . . . . . Bandwidth est.Buffer reactiveHybrid, baseHybrid, adaptive (c) Efficiency
Mbps S w i t c h i ng e v en t s Bandwidth est.Buffer reactiveHybrid, baseHybrid, adaptive (d) Number of switches
Figure 7: Comparison of the play-out algorithms in an emulated wireless mobile environment13he ST is roughly comparable for all algorithms, as it was pictured in Fig. 7(a). There aresome noticeable differences for the throughput set to 1 Mbps; although, after closer examination,their absolute values are of about several seconds what should not have much influence on endusers’ experience. As expected, with the increasing network throughput, the ST decreases,dropping from about 9 s - 13 s in the case of 1 Mbps throughput, to about 3 s - 5 s in the caseof 2.6 Mbps throughput.For the average throughput set to 1 Mbps, the bandwidth assessment algorithm experiencesup to 3 stalling events, depending on the video clip played. The buffer reactive algorithm ex-periences in average 1 stalling event. The hybrid solution in its base form experiences up to 1stalling event while its adaptive version is free from stallings. With the increasing throughput,the probability of stalling is lower, however the bandwidth estimation approach still has someproblems with a smooth play-out. Also for the throughput set to 1.5 Mbps, the buffer reac-tive algorithm sporadically experiences breaks during the play-out. In contrast, both hybridsolutions are able to deliver the video without interruptions.When it comes to the assessment of throughput efficiency, the base version of the hybrid algo-rithm clearly outperforms the rest when the throughput is set to 1 Mbps, as shown in Fig. 7(c).When the throughput increases, the hybrid solution loses its advantage over the competitors.The buffer assessment approach notes slightly better result for throughput set to 1 Mbps com-pared to the bandwidth one; nonetheless, when the throughput rises to 1.5 Mbps or 2.6 Mbps,its efficiency drops below the efficiency of the bandwidth assessment approach. The adaptiveversion of the hybrid algorithm obtains the lowest efficiency from all compared solutions. Be-cause the mobile network has more dynamical fluctuation of its throughput, the efficiency ofthe algorithms operating in this environment is in general about 20% worse compared to theseexamined in the Wi-Fi environment, see Fig. 5(c).The bandwidth assessment approach clearly under-performs in the SN experienced duringthe play-out. For the throughput set to 1 Mbps, the SN reaches nearly 70, which is about30% higher than the second score of 45 switches for the buffer reactive algorithm. The hybridsolution achieves less than 45 switches for its base version and less than 25 switches for itsadaptive version. The increase of the network throughput to 1.5 Mbps reduces the SN for thebandwidth algorithm to about 50 switches, which is however still not enough to outperformthe buffer reactive and hybrid algorithms, which achieve even better results than in the case of1 Mbps throughput. Further rise of the throughput to 2.6 Mbps, aligns the results for bandwidthand buffer reactive algorithms to about 50 switches, while the hybrid algorithms still achievesignificantly better score.The evaluation shows that the hybrid approach in most cases achieves better results com-pared to its competitors. In the Wi-Fi environment, where the network conditions are relativelystable and the throughput fluctuation has relatively low amplitude, the differences between theexamined algorithms are mainly visible when we take into account efficiency of utilisation of net-work throughput and frequency of video bit-rate switches. The base hybrid strategy obtainedin some scenarios about about 10% better throughput utilisation compared to the solutionsbased on buffer or bandwidth assessment, thereby it is able to play video of better quality.Simultaneously, the base hybrid solution obtains no worse results than its competitors in otherperformance measurements.When we take into account the mobile network, the hybrid strategy is even more dominant.Except achieving significantly lower switching of the video-bit rate, the hybrid approach is freefrom under-runs of a player buffer which causes a video clip to stall in a middle of a play-out,what takes place in the case of two other strategies. Compared to the aggressive hybrid strategy,its adaptive version achieves usually better results when taking into account the stability of theplay-out, especially in the mobile environment. However, this score is traded for significantly14orse throughput utilisation compared to other strategies.
In the paper we proposed a novel algorithm dedicated for an adaptive streaming based on HTTP.The algorithm employs a hybrid play-out strategy which combines two popular approaches: abandwidth estimation and a buffer control. As a consequence, we assumed that the hybridsolution will exploit strengths of both approaches and it will avoid their weaknesses. Theproposed algorithm was implemented in two versions which differ in the method of handlingthroughput fluctuations. The first, base version tries to aggressively exploit any favourablenetwork conditions in order to increase the bit-rate of played video. The second version isequipped with an adaptive accent: it increases the streamed bit-rate more carefully, taking intoaccount the buffer state of a player and throughput variability.The evaluation shows that in the mobile networks, where network throughput has lots ofvariability, the hybrid approach achieves better performance compared to traditional solutionsbased on bandwidth estimation or buffer assessment. The advantages of hybrid solution are lessvisible in networks where changes in network throughput have lower amplitude. Such a result isa consequence of the construction of the examined algorithms. Single parameters which describevideo systems, like network throughput or amount of buffered video, tend to strictly depend onnetwork conditions. The more variable the conditions are, the more variable the parameters.When the algorithms take into account only a one of these parameters, naturally the qualityof the transmission will strictly depend on the current network condition described by thisparameter. Therefore, an introduction of additional components which the algorithm takes intoaccount when making decisions about a bit-rate adaptation, stabilises and improves a quality ofa play-out. In the proposed solution, the algorithm considers two components and gives themequal weight. However, one can study scenarios, with multiple components describing the stateof a video system, which may not only include network throughput or buffer level, but also theirpace of change, deviations, averages etc. Some of these components may have priorities, whichmay be dependent on the characteristic of a network environment.
References
Cisco Visual NetworkingIndex. White Paper , 2013.[3] S. Alcock and R. Nelson. Application flow control in YouTube video streams.
ACMSIGCOMM Computer Communication Review , 41(2):24–30, 2011.[4] T. Stockhammer. Dynamic adaptive streaming over HTTP: standards and design princi-ples. In
Proceedings of the second annual ACM conference on Multimedia systems , pages133–144, 2011.[5] HTTP Live Streaming Resources - Apple Developer.[6] Microsoft Smooth Streaming.[7] Adobe HTTP Dynamic Streaming. 158] Iraj Sodagar. The mpeg-dash standard for multimedia streaming over the internet.
Mul-tiMedia, IEEE , 18(4):62–67, 2011.[9] Christopher Mller and Christian Timmerer. A VLC media player plugin enabling dynamicadaptive streaming over HTTP. In
Proceedings of the 19th ACM international conferenceon Multimedia , pages 723–726, 2011.[10] T. Y. Huang, N. Handigol, B. Heller, N. McKeown, and R. Johari. Confused, timid,and unstable: picking a video streaming rate is hard. In
Proceedings of the 2012 ACMconference on Internet measurement conference , pages 225–238, 2012.[11] R. Houdaille and S. Gouache. Shaping http adaptive streams for a better user experience.In
Proceedings of the 3rd Multimedia Systems Conference , pages 1–9, 2012.[12] Xuan Kelvin Zou, Jeffrey Erman, Vijay Gopalakrishnan, Emir Halepovic, Rittwik Jana,Xin Jin, Jennifer Rexford, and Rakesh K. Sinha. Can Accurate Predictions Improve VideoStreaming in Cellular Networks? In
HotMobile , 2015.[13] Niels Bouten, Ricardo de O. Schmidt, Jeroen Famaey, Steven Latr, Aiko Pras, and FilipDe Turck. QoE-Driven In-Network Optimization for Adaptive Video Streaming Based onPacket Sampling Measurements.
Computer Networks , 2015.[14] Te-Yuan Huang, Ramesh Johari, Nick McKeown, Matthew Trunnell, and Mark Watson.Using the Buffer to Avoid Rebuffers: Evidence from a Large Video Streaming Service. arXiv preprint arXiv:1401.2209 , 2014.[15] Te-Yuan Huang, Ramesh Johari, and Nick McKeown. Downton abbey without the hiccups:Buffer-based rate adaptation for http video streaming. In
Proceedings of the 2013 ACMSIGCOMM workshop on Future human-centric multimedia networking , pages 9–14. ACM,2013.[16] Florian Wamser, David Hock, Michael Seufert, Barbara Staehle, Rastin Pries, and PhuocTran-Gia. Using buffered playtime for QoE-oriented resource management of YouTubevideo streaming.
Transactions on Emerging Telecommunications Technologies , 24(3):288–302, 2013.[17] Arkadiusz Biernacki, Florian Metzger, and Kurt Tutschku. On the Influence of NetworkImpairments on YouTube Video Streaming.
Journal of Telecommunications and Informa-tion Technology (JTIT) , (3):83–90, 2012.[18] Arkadiusz Biernacki and Kurt Tutschku. Performance of HTTP video streaming underdifferent network conditions.
Multimedia Tools and Applications , pages 1–24, March 2013.[19] Michael Zink, Oliver Knzel, Jens Schmitt, and Ralf Steinmetz. Subjective impressionof variations in layer encoded videos. In
Quality of ServiceIWQoS 2003 , pages 137–154.Springer, 2003.[20] Pengpeng Ni, Alexander Eichhorn, Carsten Griwodz, and P \ aal Halvorsen. Fine-grainedscalable streaming from coarse-grained videos. In Proceedings of the 18th internationalworkshop on Network and operating systems support for digital audio and video , pages103–108. ACM, 2009.[21] Apache Web Server. 1622] S. Hemminger. Network emulation with NetEm. In
Linux Conf Au , pages 18–23, 2005.[23] Stefan Lederer, Christopher Mller, and Christian Timmerer. Dynamic adaptive streamingover HTTP dataset. In