Mobile Video Streaming with Video Quality and Streaming Performance Guarantees

Transcription

1 Mobile Video Streaming with Video Quality and Streaming Performance Guarantees Victor K. C. Wu, Yan Liu, and Jack Y. B. Lee Department of Information Engineering The Chinese University of Hong Kong Hong Kong {wkc012, liuyan, that playback continuity can be maintained, albeit at the expense of video quality. This approach has been under intensive research in recent years [3,,5,6] and several commercial implementations [7,8,9] have been deployed widely. Abstract Mobile video streaming has become a mainstream application due to vastly improved smartphone hardware and mobile network capacity in recent years. Nevertheless, mobile video streaming remains challenging in practice due to mobile network s inherent bandwidth fluctuations. This work tackles two long-standing challenges in mobile video streaming, namely to provision streaming services with predictable streaming performance and guaranteed video quality. In contrast to existing approaches based on adaptive video streaming, we show that today s mobile networks, despite the seemingly random bandwidth fluctuations, do exhibit statistically significant correlations over short and long time-scales. By developing a new framework to correlate the statistical correlations between video bitrate, streaming performance, and startup delay, we show that it is both possible and practical to achieve the above two goals by adaptively configuring the startup delay. Trace-driven simulations based on bandwidth traces captured from production 3G networks show that the proposed framework can readily achieve both streaming performance and video quality guarantees in today s mobile networks. Existing adaptive streaming protocols share two common properties. First, while these protocols are designed to adapt to bandwidth fluctuations to maintain playback continuity, or to prevent playback rebuffering suspension of playback to wait for data, their actual streaming performance is highly dependent on the network condition and can vary significantly from time to time, and location to location. Second, in actual deployment content providers often have to provide a version of the video with very low bitrate, e.g., at 10 kbps or even less, to allow the adaptive streaming protocol to prevent playback rebuffering during periods of poor network conditions. While the above properties are inherently consequences of mobile networks bandwidth variations, they also render the provisioning of premium streaming services, which demand predictable streaming performance and high video quality, difficult, if not impossible. Motivated by Liu and Lee s study [10] this work tackles these two challenges by developing a new Post-Streaming Prefetch-Buffer Analysis (PSPBA) framework to enable service providers to capture the statistical behavior of mobile networks through passive measurements; to correlate it to key system parameters including video bitrate and startup delay; so that they can provision mobile streaming services with predictable streaming performance and guaranteed video quality. To our knowledge this is the first work which can offer performance guarantees on the two previously-mentioned conflicting goals. Keywords Mobile, video, streaming, performance I. INTRODUCTION Video streaming has grown tremendously in recent years. For example, Netflix together with YouTube already accounts for 7% of North America downstream traffic during peak periods in 2H-2013 [1]. Similar rapid growth in video traffic are also happening in mobile networks. According to the data from Cisco, 72% of the world s mobile data traffic will be video by the year 2019 [2]. Streaming services over fixed networks have already evolved beyond user-generated contents and there are now many services offering entertainment-level streaming contents such as on-demand movies and shows. Unlike causal contents provided for free (or ad-supported), users subscribing to these paid premium services understandably have a much higher expectation on video quality as well as streaming performance. The rest of paper is organized as follows: Section II reviews some previous related works; Section III demonstrates the inherent tradeoff between video quality and streaming performance in existing streaming algorithms; Section IV presents the proposed PSPBA framework; Section V evaluates its performance through extensive trace-driven simulations; and Section VI concludes the study. In contrast to fixed networks, mobile networks generally exhibit much wider bandwidth fluctuations which make it challenging for streaming video as the latter is bandwidthsensitive. One approach to this challenge is to adapt the video quality dynamically in response to bandwidth changes such /15/$ IEEE 7

2 II. TABLE I. BACKGROUND AND RELATED WORKS Resolution Bitrate (kbps) A key turning point in mobile video streaming is the migration from UDP-based streaming protocols such as RTP towards TCP-based protocols such as Apple s HTTP Live Streaming protocol [7]. This is motivated by the needs to maintain compatibility with firewall/nat; piggyback on the existing web infrastructure, and so on. As a result, recent researches have largely refocused on challenges unique in a TCP/HTTP-based streaming environment. VIDEO RESOLUTAION AND BITRATE LEVELS 1p 10 20p p p p p 200 III. ADAPTIVE VIDEO STREAMING REVISITED As discussed in Section II, current streaming platforms often encode video content into multiple bitrate versions [15,16] (e.g., Table I) and then either allow the user to manually select the desired version or dynamically switch between them in response to network bandwidth fluctuations. Naturally higher bitrate version is more desirable from video quality point of view but the higher bandwidth demand will likely impact streaming performance. In particular, if too high a bitrate is selected then the network may not be able to deliver video data to keep up with playback, resulting in playback rebuffering while the player waits for video data to resume playback. Clearly, frequent playback rebuffering can significantly degrade the user experience even if the video quality is very high. A key challenge in streaming video over the Internet in general and mobile network in particular, is the lack of QoS control in the network layer. In other words, the amount of network bandwidth available at any time is generally unpredictable and there is no mechanism to request for more bandwidth when needed. To compensate for this limitation researchers developed various techniques such as multipath data transfer to improve bandwidth availability [11,12]. However many of these techniques bypassed TCP and hence are not directly applicable to current HTTP-based streaming services. Alternatively, researchers as well as the industry explored another mean to improve streaming performance over networks without QoS control adaptive streaming algorithms [11,12], where the video bitrate is dynamically adjusted to match the network bandwidth available, i.e., as the supply cannot be regulated the solution is to regulate the demand. Moreover, users subscribing to premium streaming services will demand a minimum level of video quality. A straightforward solution to fulfill this requirement would be to limit the choices of encoding bitrates to be not lower than the minimum quality level. This can be easily implemented in today s streaming platforms as only the set of encoding bitrates needs to be changed. The challenge is its impact to streaming performance which we investigate in this section. We can classify adaptive streaming algorithms into three classes: bandwidth-driven, buffer-driven, and hybrid. In bandwidth-driven approaches the principle is to estimate the network bandwidth, or more precisely, TCP throughput in HTTP/TCP-based streaming, and then adjust the video bitrate dynamically to prevent playback rebuffering. Examples include the studies by Li et al. [5], Jiang et al. [13], and so on. A. Streaming Protocols There are several adaptive streaming protocols in common use today, including the HTTP Live Streaming (HLS) protocol developed by Apple [7] and is in use by all ios devices and also supported by Android devices from version.1, the Microsoft Smooth Streaming protocol [8] developed by Microsoft in used by Silverlight and Windows Phone, and the emerging Internet standard called Dynamic Adaptive Streaming over HTTP (MPEG-DASH) [9] which currently has limited support. In contrast, Huang et al. [1] argued that bandwidth estimation is far from trivial as there can be multiple streaming users sharing a network and in such cases the users own adaptation actions could impact the bandwidth available to others, leading to unexpected interferences between the competing users. As an alternative researchers developed a different class of adaptation algorithms designed to be driven by the client s buffer occupancy instead of estimated bandwidth. Examples include the works by Huang et al. [3], Akhshabi et al. [6], etc. As the majority of these implementations are proprietary, their exact adaptation algorithms are not openly available. In this experiment we employed two streaming protocols with known adaptation logics: the Buffer-based Algorithm (BBA) proposed by Huang et al. [3] and the adaptive streaming algorithm implemented by the Android Open Source Project (implemented in LiveSession.cpp within the httplive module [17]). The former is a buffer-driven adaptation algorithm while the latter, from analysis of the source codes, is a bandwidthdriven algorithm. Finally, researchers have also developed hybrid adaptation algorithms which incorporated both bandwidth and buffer information. For example, Tian et al. [] introduced a rate selection algorithm based on both network capacity and client buffer occupancy. They proposed an algorithm that used the estimated bandwidth capacity to select target video quality level but employed client buffer occupancy to regulate the final video quality level selection. We re-implemented both streaming algorithms in a tracedriven simulator developed using C++ (c.f. Section III-B). Obviously neither of the two streaming algorithms supports the notion of video quality guarantee as they were designed to use all the available video bitrates provided by the server to compensate for network bandwidth variations. To implement different levels of video quality guarantee we simply remove bitrate versions lower than the guaranteed level from the playlist (e.g., m3u8 file in HLS [18]). Existing adaptive streaming algorithms can all improve streaming performance in the presence of network bandwidth variations. Nevertheless, by design these algorithms cannot provide any guarantees, even statistical ones, on either streaming performance or video quality both of which are essential for successful provisioning of high-quality streaming services. We demonstrate this limitation in the next section. 75

3 TABLE II. PERFORMANCE OF ANDROID HLS AND BBA STREAMING Specifically, we developed a custom measurement platform to measure the actual TCP throughput available in mobile networks by means of sending data over TCP to a mobile receiver. The packet arrival times are then recorded into a trace file which is then fed into the simulator to replicate the exact TCP throughput variations as in the real network. At the time of writing we collected a total of 11 weeks of throughput trace data. The trace data have an overall average throughput of 5.73Mbps which suggests good streaming performance potential. However, when analyzed at a shorter time-scale it tells a different story, e.g., their 10s-averaged throughput can vary from 0.8kbps to 11.3Mbps, revealing the wide range of bandwidth variations common in mobile networks precisely the reason for the wide adoption of adaptive streaming in mobile networks. ALGORITHMS A-HLS BBA τ=s τ=10s τ=s τ=10s Rebuffering probability 0.% 0.2% 2.3% 1.6% Bandwidth efficiency 5.9% 5.8% 7.3% 7.% Avg. bitrate (Mbps) % of sessions with <720p segments 95.5% 88.7% 67.6% 58.0% % of duration <720p 11.3% 11.3%.9% 5.0% Avg. no. of quality downswitches to below 720p Avg. no. of rebuffering events per session Avg. no. of bitrate switches per session In the first experiment we simulated the original Android adaptive streaming player (A-HLS) [17] and the original Buffer-based Algorithm (BBA) [3] for streaming video with a duration of 2 hours. All 6 bitrate versions listed in Table I are made available to the algorithms. Both streaming algorithms divide a video into fixed-duration segments so that a different bitrate can be chosen at segment boundaries. We simulated two segment durations of τ={s, 10s}. We assume the player begins playback once the first segment is completely received. Table II summarizes various performance metrics for the two algorithms evaluated. Rebuffering probability is computed from the proportion of streaming sessions suffered from at least one rebuffering during playback. Both algorithms achieved good streaming performance with low rebuffering probability. In comparison BBA did exhibit slightly higher rebuffering probability. This is explained by its higher bandwidth efficiency proportion of available bandwidth that is utilized for transferring video data, which resulted in higher average video bitrate compared to Android s player. Note that the average video bitrates of both algorithms are higher than that of 720p (3.0~3.8Mbps compared to 720p s 2.2Mbps) so it may appears that the video quality is also level (i.e., 720p). Now if a content provider offers a premium streaming service with a minimum video quality of 720p, then how well did the two streaming algorithms perform? Fig. 1. Mean throughput and percentage of video duration lower than 720p for individual streaming sessions using BBA with -second segments. For example, the server is equipped with all 6 versions of a video as listed in Table I. If we want to guarantee a minimum video quality of 80p at 1.1Mbps then the corresponding playlist will only include bitrate versions at or above the minimum, i.e., 80p, 720p, and 1080p. In this way the video quality is guaranteed to be 80p or better. This extension does not require any modification to the streaming protocol and can easily be implemented at the server side by dynamically generating the playlist based on the desired minimum quality level (e.g., based on subscriber profile). To answer this question we counted the proportion of video sessions which have one or more segments dropping below the minimum video quality level, i.e., 720p, and listed the results in Table II. Surprisingly, a large proportion of streaming sessions failed to meet the minimum quality level, e.g., 58%~67% for BBA and 88%~95% for Android HLS, despite the high average video bitrate. This is due to bandwidth fluctuations in mobile networks where a period of low bandwidth may cause the streaming algorithms to switch to a lower bitrate version to prevent playback rebuffering. This is confirmed by the relatively small proportion of video duration that are below 720p, i.e.,.9%~5.0% and 11.3% for BBA and Android respectively. B. Video Quality Variations To enable performance comparison of streaming with and without video quality guarantee we need a setup that can replicate and reproduce real-world network conditions in a repeatable manner. To this end we developed a trace-driven simulator where the network link bandwidth varies according to bandwidth trace data captured from a production 3G mobile network. Nonetheless for a premium streaming service such video quality degradation is far from desirable. A more significant problem is that such degradation is not evenly distributed among the video sessions. Fig. 1 plots the quality degradation and the mean throughput for individual streaming sessions 76

4 TABLE III. using the BBA streaming algorithm. It is clear that some streaming sessions suffered significantly larger video quality degradation than others, in some cases over 80% of the video duration is below 720p. These are clearly undesirable for a premium streaming service. PERFORMANCE OF ANDROID HLS AND BBA WITH MINIMUM VIDEO QUALITY OF 720P. A-HLS C. A Brute-force Approach to Guarantee Video Quality The video quality issues in the previous experiments are primarily due to the existence of video bitrate versions which are below the target minimum quality (i.e., 1p to 80p). Thus a brute-force solution to guarantee video quality would be to eliminate all bitrate versions below the target minimum. τ=s τ=10s τ=s τ=10s Rebuffering probability 9.7% 10.06% 12.88% 11.80% Bandwidth efficiency 60.2% 61.7% 7.% 7.6% Avg. bitrate (Mbps) Avg. no. of rebuffering events Avg. no. of bitrate switches We conducted precisely such an experiment by including only video bitrate versions which meet the target minimum of 720p (i.e., 720p and 1080p) and simulated the two streaming protocols using the same set of throughput trace data. Table III summarizes the results. We did not include the statistics on video quality dropping below the target minimum as there is none. Compare to the results in Table II we can observe that the rebuffering probability increased significantly, e.g., from 0.2%~0.% to 9.7%~10.06% in A-HLS. This is expected as the lack of lower bitrate versions of the video hindered the streaming protocol s ability to compensate for periods of low throughput. Note that the average number of rebuffering events per streaming session increased sharply from less than 0.01 to over 0. This is clearly unacceptable even for non-paying streaming services, let alone premium streaming services. Interestingly, the average video bitrates were only marginally higher than the unconstrained case in Table II. This suggests that the average video quality is similar to the unconstrained case despite the fact that video quality choices are limited to 720p or better. BBA Accumulated data received/consumed (bytes) Video size for r2 (e.g. 720p) Video size for r1 (e.g. 80p) Data reception curve r2 r1 D1 D2 This experiment demonstrated the conflicting tradeoff between video quality and streaming performance improving one will necessary degrade the other, rendering the problem of guaranteeing both video quality and streaming performance a seemingly impossible goal. We tackle this challenge in the next section from an entirely new angle. Time T T Fig. 2. Relation between throughput variations, maximum supportable video bitrate, and startup delay. In this work we propose to exploit the prefetch buffer to solve the challenge of guaranteeing both video quality and streaming performance. The principle is that the prefetch buffer size has a direct impact on streaming performance. Specifically, if one increases the prefetch buffer size then the streaming performance will likely improve (e.g., lower rebuffering probability). In the extreme case if the player prefetches the whole video stream before commencing playback (i.e., download) then playback rebuffering will not occur. IV. POST-STREAMING PREFETCH-BUFFER ANALYSIS A common feature in all video players is that they all buffer up a certain amount of video data before commencing playback known as prefetch buffering. There are two purposes. First, the player may need a certain minimum amount of video data before it can determine the video format to configure the decoding parameters accordingly. Second, the buffered video data can serve as a cushion to absorb short-term network bandwidth degradations. Naturally the tradeoff for larger prefetch buffer is longer startup delay. We argue that while longer startup delay is undesirable, it is more tolerable if the startup delay is made known to the user ahead of time. For example, once a user selected a video for playback, the system will inform the user that the playback can commence in a given time, e.g., 30 seconds. The user can then carry out other tasks while waiting and by the time playback can begin both video quality and streaming performance can be guaranteed. Current video players are often designed to either prefetch a fixed amount or duration of video data, or in some designs, dynamically adjust the prefetch buffer size depending on the measured data throughput. In any case the prefetch buffer size is often small to reduce the delay incurred by prefetch buffering known as startup delay. A. Startup Delay, Video Bitrate, and Rebuffering To illustrate the relation between startup delay, video bitrate, and rebuffering, we plot in Fig. 2 the accumulated amount of video data received/consumed at the client over time. 77

5 In a previous work [10] Liu et al. developed a statistical framework called Post Streaming Rate Analysis (PSRA) to capture and model mobile networks statistical relations between maximum streamable bitrate and past throughput statistics. In this study we extend the PSRA framework to incorporate dynamically configured startup delay so that video quality can also be guaranteed we call it Post-Streaming Prefetch-Buffer Analysis (PSPBA). We divide the video session into fixed-duration segments of Δ seconds. Let Ci,j be the throughput of interval j in session i, and Ci be the average throughput of the entire video session i. Video playback commences after a startup delay of D seconds and video playback lasts for a total of T seconds. Once playback is started the player will consume data according to the video encoding bitrate r. Assuming the use of constant-bitrate encoding then the accumulated amount of video data consumed by the player can be represented by a straight line as depicted by r1 and r2 in Fig. 2, with the slope of the straight line representing the video bitrate. PSPBA comprises two processes analysis and prediction. These are to be implemented by the service provider. The analysis process has two goals. First, it captures the throughput series for all streaming sessions. Second, it processes the captured throughput data periodically, e.g., daily, to construct a statistical model relating startup delay, video bitrate, and rebuffering probability. The key to avoiding playback rebuffering is to prevent the player from running out of video data during playback, i.e., to prevent the playback curve (i.e., r1) from crossing the accumulated data reception curve. Consequently, given the startup delay, e.g., D=D1 we can determine the maximum video bitrate that can be sustained without rebuffering as depicted by playback curve r1 in Fig. 2. Specifically, given the throughput series for past streaming sessions {Ci,j} we first compute the maximum video bitrate that, using (1). Ultimately we want to can be supported, i.e., Rimax,D predict the video bitrate for use in future streaming sessions so we employ a metric called maximum-rate-to-throughput-ratio (MRTR), defined as: Mathematically, if the throughput series {Ci,j} is known for streaming session i, then we can compute the maximum video bitrate that can be supported, denoted by Rimax, from,d Rimax,D t / Δ = max r Ci, j Δ r max{0, t D}, 0 t T + D (1) j = 0 where the summation term on the L.H.S. of the inequality represents the accumulated amount of video data received by time t (j=0 is the first video segment) and the R.H.S. represents the accumulated amount of video data consumed by playback at time t. Thus the inequality sets the condition for continuous video playback and the maximization operator finds the maximum video bitrate satisfying this constraint. Rimax +1, D / Ci (2) The physical interpretation of (2) is the maximum video bitrate that can be supported in session i+1 with D seconds startup delay divided by the average throughput in session i. The key here is the use of the average throughput of the previous session i in relating to the maximum video bitrate in the future session i+1. By computing the MRTR metric for past throughput trace data we can then generate its probability distribution, denoted by FD( ). To support runtime configurable startup delay we compute (2) for a series of startup delays, denoted by Dk, where k=1,2, K and Dk<Dk+1, k. The corresponding CDFs for different initial startup delay Dk is denoted by FDk ( ). Now if we increase the startup delay from D1 to D2 as depicted in Fig. 2 then the longer startup delay will allow more video data to be prefetched and as a result the maximum supportable video bitrate will be increased. In other words, even though the network throughput is the same, we can support a higher video bitrate by increasing the startup delay. This offers a solution to the challenge discussed in Section III as the requirement to meet a minimum video quality can now be solved by a suitable choice of startup delay, without negatively impacting rebuffering performance. To further capture the network behavior at different throughput levels (e.g., higher mean throughput sessions generally exhibit smaller throughput variations due to good signal condition and vice versa) we divide the throughput series into L throughput levels, with throughput level l, L>l 0, comprising sessions with mean throughput within (lcmax/l, (l+1)cmax/l]. A separate MRTR distribution, denoted by Fl, Dk ( ), is then generated for each throughput level. These However, a problem remains the throughput series {Ci,j} for a video session can only be known after streaming is completed and hence one cannot determine the required startup delay before streaming begins. We address this challenge in the next section. MRTR distributions capture the mobile network s characteristics, relate the tradeoffs between startup delay, video bitrate, and playback rebuffering. In the next section we use the MRTR distributions to inform the choice of startup delay. B. Post-Streaming Analysis Clearly without knowledge of future network throughput it is simply not possible to provide deterministic streaming performance guarantee, even in principle. However, our extensive measurements of bandwidth and TCP throughput in mobile networks [10] strongly suggest that the latter do exhibit statistically consistent behaviors over a timescale of days. C. Startup Delay Selection The second part of the PSPBA framework is startup delay selection given the mean throughput of the previous streaming session and the desired target minimum video quality. The objective is to choose the minimum startup delay that can support the streaming of the video at the minimum guaranteed video bitrate rmin with a probability of playback rebuffering given by α. The latter represents streaming performance and is 78

6 chosen by the service provider according to its service requirements. Generally, choosing a lower target rebuffering probability improves streaming performance at the expense of longer startup delay, and vice versa. This differs from PSRA [10] where reducing the target rebuffering probability will result in lower video quality. D1 CDF D2(>D1) Fig. 3 illustrates the process of startup delay selection. The figure plots the MRTR CDFs for two startup delays D1 and D2. First, given the target rebuffering probability α and the mean throughput of the previous session Cx, we can determine the maximum video bitrate (i.e., r) that can be supported as shown at point X. X Feasible region α MRTR Now if r rmin then the minimum video quality requirement is met. Otherwise it means that the startup delay of D1 seconds is not sufficient to sustain the required minimum video quality at the target rebuffering probability. In this case we need to increase the startup delay to D2 where its CDF is shifted to the right as depicted in Fig. 3. With the longer startup delay we now have parts of the curve falling inside the feasible region. r rmin Cx Cx Fig. 3. Startup delay and bitrate selection in PSPBA. Mathematically, the expected rebuffering probability for streaming at the guaranteed minimum video bitrate rmin with startup delay Dk, denoted by αˆ Dk, is given by rmin, Cx αˆ D = Fl, D k x k k = 1, 2,..., K (3) Given the target rebuffering probability α, we can then find the required startup delay, denoted by D, from Dˆ = arg min α αˆ Dk () Dk Note that () does not guarantee that the resultant rebuffering probability αˆ Dl is exactly equal to the target α. This Fig.. Actual rebuffering probability tends to be lower than the target when the target video bitrate is low and the target rebuffering probability is high. is why the minimization is done over the absolute value of the difference in the R.H.S. of () so that the errors will not become systematic (i.e., consistently lower/higher than the target). Experimental results show that this not only improves the video quality, but also increases the accuracy in achieving the target rebuffering probability. Note that PSPBA is nonadaptive in the sense that once the video bitrate is chosen at startup, it will not change during the streaming session. Conceivably PSPBA may also be applied to adaptive streaming which is currently being investigated by the authors. A further refinement is that rmin specifies only the minimum guaranteed video quality. If the network throughput is high then even with the minimum startup delay the expected rebuffering probability may still be lower than the target. This is illustrated in Fig.. We observe that at lower target video bitrates and higher target rebuffering probabilities, the actual rebuffering probability ended up lower than the target. V. In this section we evaluate the performance of the proposed PSPBA framework and compare it against two existing streaming platforms, namely Android s HLS [17] and BBA [3]. The results are obtained from the trace-driven simulator discussed in Section III-B, using 11 weeks throughput trace data collected from a production 3G network. In these cases it is in fact feasible to support a video bitrate higher than the target minimum while still meeting the target rebuffering probability with minimum startup delay. To exploit this, if () computes D = D1, i.e., minimum startup delay, then we explore higher video quality levels to choose the bitrate with the least expected error in rebuffering probability: r Rˆ = arg min Flx, D1 r rmin Cx α PERFORMANCE EVALUATION A. Experiment Setup For PSPBA we implemented its analysis process using a sliding window scheme where the MRTR distribution is computed once a day, using trace data of the past 7 days as inputs. The computed MRTR distribution is then applied to configure the bitrate and startup delay of new streaming (5) 79

7 sessions throughout the new day as presented in Section IV-C. At the end of the day the process repeats by computing a new set of MRTR distributions for the next day, and so on. Note that a separate MRTR distribution is computed for each throughput level and startup delay. There are 10 throughput levels, ranging from 1, 2,, 10 Mbps. For startup delay there are 597 steps for 5-min videos:, 5,, 600 s. For 2-hr videos we employ a three-tiered division to reduce the number of distributions needed: {, 5,, 10 s}, {15,20,, 1000 s}, and {1100, 1200,, s}, for a total of 358 steps. There are 6 video quality levels with resolution and bitrates listed in Table I. We simulated two scenarios, one for short videos with video duration of 5 minutes (e.g., music videos), and the other for long videos with video duration of 2 hours (e.g., movies). Fig. 5. Average actual video quality versus target minimum video bitrate and actual rebuffering probability (PSPBA 2-hour videos). For PSPBA there are two parameters that can be controlled by the service provider, namely target rebuffering probability and target minimum video bitrate. Given these two parameters then the PSPBA algorithm determines the actual bitrate and startup delay to use for each new streaming session. B. Performance Guarantees PSPBA is designed to provide deterministic guarantee on video quality and statistical guarantees on streaming performance. The former guarantee is achieved automatically in calculating the startup delay as described in Section IV-C. Obviously the actual quality is never lower than the target minimum, and in cases where the target quality is low and/or the target rebuffering probability is high, the actual video quality selected could end up higher than the target minimum (c.f. (5)). Fig. 5 plots the actual average video bitrate versus the target minimum bitrate. It clearly shows that PSPBA can and do exploit extra available network bandwidth, especially at low target minimum bitrate and high rebuffering probability, to raise the video quality above the target minimum. Fig. 6. Actual rebuffering probability versus target for PSPBA. For streaming performance we plot in Fig. 6 the actual rebuffering probability achieved versus the target rebuffering probability set by the service provider. The actual rebuffering probability is averaged over all 6 target minimum video bitrates. The results show that the actual streaming performance is reasonably close to the target, especially the one for 5-min videos. Fig. 7 further analyzes the streaming performance by plotting it separately for each target minimum video bitrate. First, compare to the results in Fig. we can clearly see that the large deviations at lower target video bitrates have been corrected by the upward bitrate exploration in (5) as described in Section IV-C. Note that at high target bitrates (e.g., 1080p at.2mbps) and high target rebuffering probabilities (e.g., 0.1), the actual rebuffering probability is still lower than the target. This is because the target video bitrate is already the highest one, and so even if the high target rebuffering probability could allow an even higher bitrate to be streamed none is available to take advantage of that. Therefore if more (higher) video bitrate versions are available then the deviation could be reduced. Fig. 7. Actual rebuffering probability versus target rebuffering probability and target minimum video bitrate (PSPBA 2-hour videos). C. Startup Delay The key to PSPBA s ability to control both video quality and streaming performance is its dynamic configuration of the startup delay. Note that in PSPBA the startup delay is determined and fixed before streaming begins so the user can 80

8 be informed of the exact time playback can commence. By contrast, existing streaming protocols often rely on downloading a certain amount of video data before commencing playback, resulting in variable startup delay that is determined by the bandwidth available at the time. We argue that having a known and fixed startup delay can improve user experience and increase user s tolerance of the delay. On the other hand, in a small fractions (<2%) of the streaming sessions, the video could have been completely downloaded before the predicted startup delay expires, e.g., due to higher than expected network bandwidth. Obviously in such cases there is no benefit to keep waiting until the startup delay expires and so we implemented a variation called early start (PSPBA-ES) which begins playback as soon as the video is completely downloaded. Fig. 8. Mean startup delay versus actual rebuffering probability. Fig. 8 plots the mean startup delay versus actual rebuffering probability for two target video qualities of 80p and 720p. We observe that the mean startup delay remains reasonably short for actual rebuffering probabilities around 0.05, e.g., about 5 mins even for a minimum video quality of 720p for 2-hr videos (see Table IV). The startup delay is significantly lower for 5min videos, e.g., less than 18 seconds for 720p target video quality. The early start scheme is also effective in reducing the mean startup delay, especially for 2-hr videos. TABLE IV. PERFORMANCE OF PSPBA AND PSPBA-ES. Metric 720p, 2hrs 80p, 2hrs 720p, 5mins 80p, 5mins Actual rebuffering probability 5.68% 5.30% 5.32% 5.18% % 0.2% 0.23% Average minimum startup delay with a priori throughput 19.8 knowledge (s) Average startup delay achieved by PSPBA (s) Average startup delay 29.3 achieved by PSPBA-ES (s) Percentage of early start 1.5% sessions 80-percentile of startup delay achieved by PSPBA & 7 PSPBA-ES (s) 90-percentile of startup delay achieved by PSPBA & 90 PSPBA-ES (s) 95-percentile of startup delay achieved by PSPBA & 620 PSPBA-ES (s) Table IV compares the startup delay for cases where the actual rebuffering probabilities are around 5% - a reasonable target. There are three observations. First, for comparison purpose we computed the average minimum startup delay from a priori knowledge of the exact throughput trace data for the video sessions. This represents the absolute minimum startup delay required to prevent rebuffering if the entire future throughput trace data are known before streaming begins. While this is clearly not realizable even in principle, it does offer insights into the costs in startup delay due to uncertainties in future network throughput. As expected the average minimum startup delays are lower than the actual ones, and the differences widens for the longer 2-hr videos as there are significantly more uncertainties further into the future. Second, the simple early-start scheme is effective in reducing the mean startup delay, especially in 2-hr video cases. Moreover there is no additional cost to implement this scheme. Third, we observe that the 90-percentile startup delay is only 90 s for the {2-hr, 720p} case and reduces to the minimum delay of s for the rest of the three cases. These are significantly lower than what the mean suggests. The reason, as depicted in Fig. 9, is due to the distribution of the startup delays where the majority of them are at or near the minimum (i.e., s) but with a long tail spanning to long delays which inflated the numerical average. Overall, the majority of the streaming sessions experienced relatively short startup delays. It is worth reiterating that PSPBA computed the startup delay before streaming begins and thus it can be displayed to the user. In practice, it is also possible to present the user with the startup delay associated with different quality levels (e.g., a shorter one for 80p and a longer one for 720p) so that the user can choose between video quality and waiting time. Fig. 9. Distribution of startup delay with minimum video quality set to 720p and rebuffering probability ~5% for PSPBA streaming 2-hr videos. 81

9 respectively. By contrast, PSRA was explicitly designed to support control of the rebuffering performance. However the results clearly show that the actual rebuffering probability deviated significantly from the target. This is because video bitrate versions lower than the target minimum of 720p were no longer available to PSRA, preventing it from choosing a sufficiently low bitrate video version in low network throughput scenarios. In comparison PSPBA can configure the startup delay to compensate for low network throughput to meet the minimum video bitrate target. Thus the resultant actual rebuffering probabilities more closely track the target ones. In Fig. 11 we investigate the impact of target video bitrate on rebuffering performance. We fixed the target rebuffering probability to α=0.05 for both PSRA and PSPBA. We observe that the rebuffering performance of the three competing algorithms vary widely depending on the target video bitrate. In particular, when the target video quality is set to 1080p all three algorithms performance deteriorate significantly, with rebuffering probabilities exceeding 0.2 which are unlikely to be acceptable in a premium streaming service. In contrast, only PSPBA can maintain the rebuffering performance to close to the target for the complete range of target video bitrates all the way from 10kbps to.2mbps. Fig. 10. Streaming performance comparison for streaming 2-hr videos with minimum video quality of 720p. VI. CONCLUSION Fig. 11. Comparison of streaming performance over different target minimum video quality (2-hr videos). Despite the lack of QoS guarantees in the current mobile networks, we show that it is still possible to provide deterministic guarantee to video quality and statistical guarantee to streaming performance using the PSPBA framework. With the rapid migration to network-based video delivery, more and more paid streaming services will demand quality as well as streaming performance guarantees. The proposed PSPBA framework offers a practical solution to address this challenge. D. Comparisons In this section we compare the performance of PSPBA with three existing algorithms, namely PSRA [10], Android HLS [17], and BBA [3]. PSRA is the precursor to PSPBA which was designed to provide statistical guarantee on streaming performance but not video quality. It is configured with a fixed startup delay of seconds. Android HLS and BBA on the other hand are configured to begin playback after seconds of video data have been received. This study focused on constant-rate streaming where the video bitrate, once selected at the start of the session, remains constant throughout the streaming session. This is in fact desirable from the user s point-of-view as fluctuating video quality can degrade the user experience [13,19]. Nonetheless if the gain in video quality can compensate for the loss due to bitrate switching, it may still offer an overall better experience to the user. The authors are now investigating an extended framework to apply PSPBA to rate-adaptive streaming applications. It is worth noting that PSPBA and PSRA are non-adaptive streaming algorithms while Android HLS and BBA are adaptive streaming algorithms. As the three competing algorithms were not explicitly designed to guarantee video quality we implemented it by means of limiting the video bitrate choices to those not lower than the target minimum as described in Section III-C. ACKNOWLEDGEMENTS The authors wish to thank the anonymous mobile operator contributing the trace data for the simulations in this work. This work is funded in part by a research grant (GRF120371) from the HKSAR Research Grant Council. REFERENCES We first compare streaming performance in Fig. 10 with a target minimum video quality of 720p. Android HLS and BBA do not support configurable target rebuffering probability so their rebuffering performance is determined by their rate adaptation algorithms. Android HLS and BBA achieved average rebuffering probabilities of and [1] Sandvine Inc., "Global Internet Phenomena Report (1H201)," 201. [Online]. [2] Cisco Inc., "Cisco Visual Networking Index: Global Mobile Data Traffic Forecase Update, ," Feb [Online].

10 [3] TY Huang, R. Johari, N. McKeown, M. Trunnell and M. Watson, "A Buffer-Based Approach to Rate Adaptation:Evidence from a Large Video Streaming Service," in Proc. 201 ACM Conf. SIGCOMM (SIGCOMM'1), Chicago, Illinois, USA., Aug. 201, pp [] G. Tian and Y. Liu, "Towards Agile and Smooth Video Adaptation in Dynamic HTTP Streaming," in Proc. 8th Int. Conf. Emerging Networking Experiments and Technologies (CoNEXT'12), Nice,France, Dec. 2012, pp [5] Z. Li, X. Zhu, J. Gahm, R. Pan, H. Hu, A. C. Begen and D. Oran, "Probe and Adapt: Rate Adaptation for HTTP Video Streaming at Scale.," Selected Areas in Communications, IEEE Journal on, vol. 32, no., pp , April 201. [6] S. Akhshabi, A.C. Begen and C. Dovrolis, "An Experimental Evaluation of Rate-adaptation Algorithms in Adaptive Streaming over HTTP," in Proc. 2nd Annual ACM Conf. Multimedia Syst. (MMSys'11), San Jose, USA, Feb. 2011, pp [7] Apple. HTTP Live Streaming Overview: Introduction. [Online]. rnet/conceptual/streamingmediaguide/introduction/introduction.html [8] Microsoft. Microsoft Smooth Streaming. [Online]. [9] Dashif. Overview of MPEG-DASH Standard. [Online]. [10] Y. Liu and J.Y. B. Lee, "Providing Predictable Streaming Performance in Mobile Video Streaming," in Communications (ICC), 201 IEEE Int. Conf., Sydney, 201, pp [11] J. Wu, B. Cheng, C. Yuen, Y. Shang and J. Chen, "Distortion-Aware Concurrent Multipath Transfer for Mobile Video Streaming in Heterogeneous Wireless Networks," Mobile Computing, IEEE Transactions on, vol. 1, no., pp , April [12] J. Wu, B. Cheng, C. Yuen, Y. Shang and J. Chen, "Goodput-Aware Load Distribution for Real-Time Traffic over Multipath Networks," Parallel and Distributed Systems, IEEE Transactions on, vol. 26, no. 8, pp , Aug [13] J. Jiang, V. Sekar and H. Zhang, "Improving Fairness, Efficiency, and Stability in HTTP-based Adaptive Video Streaming with FESTIVE," in Proc. 8th Conf. Emerging Networking Experiments and Technologies (CoNEXT'12), Nice, France, Dec. 2012, pp [1] T.Y. Huang, N. Handigol, B. Heller, N. McKeown and R. Johari, "Confused, Timid, and Unstable:Picking a Video Streaming Rate is Hard," in Proc ACM Conf. Internet Measurement Conf. (IMC'12), Boston, USA, Nov. 2012, pp [15] Netflix. Internet Connection Speed Recommendations. [Online]. [16] YouTube. Advanced encoding settings. [Online]. [17] Android. Android HLS adaptive algorithm source code in LiveSession.cpp. [Online]. edia/libstagefright/httplive/livesession.cpp [18] Apple. HTTP Streaming Architecture. [Online]. rnet/conceptual/streamingmediaguide/httpstreamingarchitecture/ HTTPStreamingArchitecture.html [19] Y. Liu, S. Dey, D. Gillies, F. Ulupinar and M. Luby, "User Experience Modeling for DASH Video," in Proc. 20th Int. Packet Video Workshop (PV), San Jose, CA, USA, Dec. 2013, pp