Layer-Assisted Adaptive Video Streaming

Transcription

1 Layer-Assisted Adaptive Video Streaming Afshin Taghavi Nasrabadi, Ravi Prakash The University of Texas at Dallas, U.S.A. ABSTRACT HTTP Adaptive Streaming (HAS) is the widely adopted solution for video streaming over the Internet. When network throughput is highly variable, designing an optimal HAS solution that maximizes Quality of Experience (QoE) becomes challenging. Each chunk should be prefetched at highest possible quality while rebufferings and quality switches are minimized. Scalable Video Coding (SVC), with its layered encoding of video, provides more flexibility for HAS clients. It can reduce the occurrence of rebufferings under variable network conditions. However, SVC introduces at least 10% overhead on video bitrate per layer and increases the number of HTTP requests to fetch video chunks. So streaming SVC video at high qualities is more expensive. We propose a solutions that employs both SVC and non-svc video to improve user s QoE while avoiding the increased bandwidth overhead and HTTP signaling of SVC. Our experiments using real-world bandwidth traces show that this method improves QoE compared to the state-of-the-art adaptation methods under various network conditions. KEYWORDS HTTP Adaptive Video Streaming, QoE, Rebuffering 1 INTRODUCTION HTTP Adaptive Streaming (HAS) is widely accepted as the solution for video streaming over the Internet while being compatible with existing infrastructure and protocols. HAS uses commodity HTTP servers to host the video content and content distribution networks (CDNs) to scale to millions of users. HAS divides the video stream into chunks, each of a fixed duration (few seconds), and makes each chunk available at a set of quality levels on the server. Higher quality chunks are encoded at higher bitrate, requiring higher network throughput to be streamed. Video streaming has to meet strict timing requirements while dynamically adapting to variations in the underlying network conditions. Quality of Experience (QoE) of video streaming is affected by three main metrics: (1) the average quality of video playback, (2) quality changes during playback, and (3) the number and duration of playback stalls, also known as rebuffering [16]. Rebuffering adversely affects QoE [12]. The client decides the quality at which it fetches each chunk. Figure 1 shows the building blocks of a HAS Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from permissions@acm.org. NOSSDAV 18, June 12 15, 2018, Amsterdam, Netherlands 2018 Association for Computing Machinery. ACM ISBN /18/06... $ client. When the client sends a request for a chunk, it waits for that chunk to be downloaded completely, and then puts it in its buffer. Client s buffer holds a number of chunks to provide smooth video playback in spite of network throughput variations. Client should avoid video rebuffering while maintaining the highest possible playback quality with fewest quality switches. If the client chooses a high quality level for a chunk that cannot be delivered before its playback deadline, rebuffering happens. On the other hand, streaming low quality video when the network throughput is high results in bandwidth under-utilization and user dissatisfaction. Moreover, clients should not react to throughput changes too quickly as frequent video quality fluctuation degrades QoE. When transient bandwidth drop happens, the client can use its buffer to provide smooth high quality playback. Many adaptation methods are designed for single-layer encoded video, e.g., H.265/HEVC, since it is the mainstream encoding method, and many devices support its decoding. However, there is some research on the application of Scalable Video Coding (SVC) in HAS [6][4]. SVC layered structure provides more flexibility for clients because they can adapt at finer granularity, i.e, layers instead of chunks, and react better to network conditions. However, encoding overhead of SVC has prevented it from being deployed broadly. An SVC-encoded video has at least 10% higher bitrate per layer compared to non-svc-encoded video at the same quality level [2]. So required throughput for streaming SVC video increases as the number of layers increases. We propose to utilize the advantages of both SVC- and non-svcencoded video for better adaptation. In addition to regular representation set used in non-svc HAS, a set of enhancement layers are made available for each quality level. So, the client should make decision about the base quality for each chunk, similar to regular HAS with non-svc video. When estimated network throughput is low, the client can be conservative and prefetch chunks at lower bitrates to avoid rebuffering. When network conditions improve drastically, the client has the luxury of enhancing the quality of buffered chunks by fetching enhancement layers. Using this method, unlike pure SVC methods, the client does not always start with lowest quality base layer. Thus, the overhead of SVC is not incurred when it is unnecessary. We call this method Layered-Assisted Adaptive Video Streaming (LAAVS). Our experimental results using real-world network throughput traces show that LAAVS outperforms the state-ofthe-art adaptation methods, such as Pensieve [11], under various network conditions. LAAVS is a low complexity algorithm and does not need training, but Pensieve uses machine learning to optimize QoE and needs training. Pensieve performance degrades drastically when it encounters unseen and different scenarios. The rest of this paper is organized as follows. In Section 2, related work is discussed. The proposed method is explained in Section 3. Section 4 presents the experimental results. Finally, Section 5 concludes the paper.

2 Figure 1: Internal components of a HAS client 2 RELATED WORK As depicted in Figure 1, the client uses the following information on its side as inputs to the adaptation logic: (1) Video specs: the number of representations, their quality level, bitrate, and chunk duration, (2) Buffer status: video duration already fetched and stored in the buffer, and (3) Network conditions: perceived network throughput. Existing solutions can be categorized based on how they utilize these information to make pre-fetching decisions, with the goal of optimizing QoE. Throughput-based (TB) methods rely mostly on network throughput estimation. They choose the highest quality that can be streamed, given the estimated throughput [8]. Network bandwidth is dynamic, and bandwidth estimation is done by smoothing recent bandwidth samples to avoid unnecessary quality switches. FESTIVE [7] is one of these solutions that provides a trade-off among fairness, efficiency, and stability where multiple HAS clients are streaming video. However, it is very challenging to predict the future throughput because of interactions between the application layer adaptation and TCP congestion control [1], and highly variable nature of networks, especially mobile wireless networks. Sun et al. [18] have shown that similar video streaming sessions share similar throughput patterns. Based on this observation, they have improved throughput prediction using the Hidden Markov Model. However, exploiting sessions pattern requires large amount of data about the previous sessions. Another challenge for TB methods is Variable Bit-Rate encoded video. The client adapts based on average bitrate, while the size of each segment varies from the average. Buffer-based (BB) methods are proposed to reduce the dependency on bandwidth estimation. Control-theoretic approach in [19] adjusts throughput estimation based on buffer occupancy as a feedback signal. However, Huang et al. [5] observed that this adjustment is very challenging. They proposed a BB approach which maps the instantaneous buffer occupancy to a quality level. But BB methods require longer buffers to have adequate space between buffer thresholds corresponding to quality levels. Otherwise, the frequency of quality switches increases. BOLA [17] is another BB method that tries to maximize QoE by using Lyapunov optimization technique. BOLA also uses download abandonment technique to reduce rebufferings, i.e., when download duration of a chunk is longer than buffer duration. Model Predictive Control (MPC) utilizes buffer occupancy and network throughput estimation to improve QoE under variable conditions [20]. Performance depends on the accuracy of throughput estimation. Machine learning techniques are used in [3][11] for quality adaptation. Pensieve [11] is based on reinforcement learning. It has been shown to outperform other methods by minimizing rebuffering events and maximizing average playback quality. Achievable QoE with Pensieve is approximately within 10% of the offline optimal. However, this method needs training. SVC is a hierarchical encoding method that encodes a video into a base layer and several enhancement layers [2]. Each layer can provide quality/resolution/frame-rate enhancement over lower layers and depends on them. The effectiveness of using SVC in HAS has been studied in [4]. Results show that under stable network conditions, average quality of SVC is lower than non-svc video due to the higher bitrate of SVC. However, for variable network conditions, SVC can perform better since client divides the request per chunk into requests per layer. Using SVC, client has two choices: (1) prefetching a new chunk (base layer), or (2) backfilling: fetching an enhancement layer for an already fetched chunk. Giving priority to prefetching reduces rebufferings. Buffer-based methods are proposed in [14] and [6]. The client starts to fill the buffer with the base layer, and if lower layers for all segments in the buffer were downloaded, it fetches the next enhancement layer for them. Experimental results show that these methods successfully reduce rebuffering events. 3 PROPOSED METHOD 3.1 Video Encoding In HAS, each video chunk is available in a set, S, of representations. Let S = {(q 1, r 1 ), (q 2, r 2 ),..., (q n, r n )}. Each tuple (q i, r i ), 1 i n, is a representation with quality level q i and average bitrate r i. Given j greater than i, we have q j > q i and r j > r i. For each representation i, LAAVS needs enhancement layers to improve the quality of prefetched chunks at quality q i to any quality q j such that i < j n. So for each representation i in S, we will have a set of layers L i = {(bq i,br i ), (eq i,1, er i,1 ),..., (eq i,n i, er i,n i )}, in which (bq i,br i ) is the base layer with quality bq i = q i. Any (eq i, j, er i, j ) is the j th enhancement layer with bitrate of er i, j that can provide quality level equivalent to q i+j, if added on top of all lower layers. So quality level q i can be achieved from all base layers {bq j 1 j i} according to equation 1. i j q i = bq j + eq j,k (1) k=1 i j r i = br j + er j,k (2) k=1 = [1 + (i j)δ] (3) Equation 2 shows that the bitrate of SVC video is times greater than non-svc one. As shown in equation 3, each enhancement layer adds at least δ 10% overhead to the bitrate compared to non-svc video. Figure 2 shows how a video with six quality levels can be represented in LAAVS using a combination of HAS base layer and SVC enhancement layers.

3 from 0.5T e to T e. So, for bitrate selection only in the startup state, T a is used instead of T e. Figure 2: Set of representations for LAAVS 3.2 Adaptation algorithm At each step, the client can take one of these two actions: (1) Prefetching: A new base layer chunk of quality i is requested (bq i ); (2) Backfilling: An enhancement layer is requested for a quality i base layer chunk already in the buffer (eq i, j ). For prefetching, quality of the base layer should be determined. For backfilling, the client should decide which chunk in the buffer should be chosen for quality enhancement, and then the suitable enhancement layer should be requested for that chunk. LAAVS considers both throughput estimation and buffer occupancy level (in seconds) for adaptation. The algorithm has two main states: startup and Prefetching+Backfilling (PB). Assume that the client has a buffer with duration of B seconds, we refer to the current buffer occupancy with B c. We define multiple thresholds on the buffer to switch between states: panic (B p ), backfilling (B b ), and startup (B s ), such that B p < B b < B s. LAAVS starts from initialization and then enters the start-up state. The goal of start-up state is to build up buffer quickly, possibly at a lower quality, to a certain duration (B s ). Then, LAAVS enters the PB state and tries to stream highest possible quality with lowest rebuffering and switches. In this state, both prefetching and backfilling can be done Throughput estimation and bitrate selection. Client estimates throughput from previous chunk downloads: dividing chunk size by download duration. The average of last three throughput samples is taken as the throughput estimate, T e. We use a function that takes T e as input and returns the highest video bitrate lower than T e Initialization. In the beginning of a session, the client does not have sufficient history about network conditions. Although throughput can be estimated from downloading the meta-data at the beginning of a session, we decide to start from a fixed quality level for the first chunk Startup state. Every time buffer occupancy level becomes lower than B p (including in the beginning of a session), the client panics and enters the startup state. It tries to accumulate chunks in the buffer up to B s quickly. Having more chunks in the buffer improves robustness against rebuffering; however, fetching chunks at very low quality reduces QoE. So, proportional to the accumulated chunks and network throughput, we prefetch chunks at lower bitrate. For this purpose, we adjust T e using a linear function according to equation 4, and call it T a. When buffer is less than B p, the client halves T e. From B p to B s, the client linearly increases T a 0.5T e if B c < B p T a = 0.5(B c + B s ) B p (4) T e if B p < B c < B s B s B p Note that, backfilling is not allowed in this state as it does not add any new chunk to the buffer PB state. When buffer occupancy reaches B s, LAAVS enters the PB state, where it tries to get highest possible quality and do backfilling opportunistically. We consider a set of conditions for backfilling. If all conditions are satisfied then an enhancement layer for a specific chunk is fetched; otherwise, prefetching is done. Backfilling does not add any new chunk to the buffer, so if the buffer is shallow, it can increase the risk of rebuffering. So the first condition is that buffer occupancy should be more than a pre-defined threshold B b. To allow backfillings happen from the moment that the client enters PB state, we set B b lower than B s. Then, the client searches the buffer, starting from the most recently downloaded chunk, to find the lowest quality chunk. Let the quality of the found chunk be Q f, while the last prefetched chunk s quality is Q l. Client backfills if Q f < Q l. In other words, the client backfills only up to Q l in order to reduce quality switches and fill the quality gaps between prefetched chunks. Increasing quality to a level higher than Q l is done only during prefetching. Finally, the client checks if the estimated throughput can support streaming of quality level Q f + 1. Assume that the base layer quality of the found chunk is Q b, it checks the following condition: Q f Q b +1 T e > br Qb + er Qb,i. (5) i=1 Note that we consider the cumulative bitrate instead of only that enhancement layer s bitrate; otherwise, download duration of an enhancement layer can be up to that of a complete chunk which results in buffer length reduction. If the conditions for backfilling do not hold, the client determines the quality level for the next chunk to prefetch. In PB state, we make the client more aggressive for getting higher qualities and staying at those quality levels.t e will be given to the bitrate selection function. If chosen quality is higher than current quality level Q l, the client always switches to the higher quality. But, if chosen quality is lower than Q l, the client tries to resist against quality downgrade. The client checks buffer occupancy level B c. If B c is greater than B b, the client tries to be aggressive and resists against quality downgrade. It stays on the current quality level unless br Ql > 1.5T e. If B c is less than B b, the client switches to lower quality level. If the client switched to a lower quality level, it stays at that quality level for the next chunk and does not do any backfilling. In other words, the client backs off from higher quality levels. If the drop is transient, those lower quality chunks will be backfilled later. Whenever the buffer occupancy goes lower than B p, the client switches to the startup state. Considering B = 60s, using experimental analysis, we set the buffer thresholds as follows: B p = 10s, B b = 15s, B s = 20s. Lower

4 Algorithm 1: LAAVS adaptation algorithm This algorithm runs after downloading each chunk or layer if B c < B p then state = star tup ; else if B c > B s then state = P B ; if state is startup then if B < B p then T a = 0.5T e 0.5(Bc +Bs ) Bp else T a = B s B p T e ; i = дet Bitr ate(t a ) //get index of highest bitrate lower than T a return bq i else Q l quality of the most recently prefetched chunk if B c > B b then //find the most recently downloaded chunk with quality < Q l //and return its index, base quality(q b ) and its overall quality(q f ) index,q b, Q f f indchunk(q l ) if index!=null and T e > br Qb + Q f Q b +1 i=1 return eq Qb,f +1 ; end i = дet Bitr ate(t e ) if i > Q l then return bq i else if B c < B b or r Ql > 1.5T e then return bq i else return bq Ql ; end end er Qb,i then values will increase rebuffering probability, and higher values delay switching to higher quality chunks. 4 PERFORMANCE EVALUATION We compare LAAVS with different adaptation algorithms, considering various network conditions and two different video sequences. 4.1 Experimental setup Network Conditions. In our experiments, a client connects to the video source, which is an Apache HTTP server hosting video files, through wireless cellular network. We chose Mahimahi LinkShell [13] for emulating cellular link throughput. Mahimahi emulates cellular link by replaying pre-recorded traces of network packet transmissions. We use 3G and 4G network bandwidth traces. 55 3G/HSDPA traces are taken from the dataset provided by Riiser et al. [15]. It contains bandwidth traces sampled every second from different public transportation mobility scenarios in Norway. We also used 20 4G traces from available traces in Mahimahi emulator. These traces were sampled every millisecond and recorded from major US wireless carriers in car driving scenarios. We considered a round-trip time of 80ms between the client and server Videos. Available bitrates of a video, i.e., bitrate ladder, can affect the performance of adaptation algorithms. Bitrate ladder depends on encoding configuration and the content of the video. If bitrates are close to each other, small bandwidth fluctuations could trigger frequent bitrate switching. An aggressive adaptation algorithm can take advantage of such videos, and opportunistically switch to higher resolutions, while network bandwidth is low and Figure 3: Average bitrate per resolution for YouTube videos ± one standard deviation Table 1: Bitrate ladder for videos (Envivio, TOS) in Mbps Cumulative bitrate up to: Rep. Res. r rep er 1 er 2 er 3 er 4 er p (0.30, 0.25) (0.87, 0.92) (1.56, 1.95) (2.68, 3.48) (4.56, 6.40) (7.53, 17.50) 2 360p (0.75, 0.80) (1.38, 1.73) (2.41, 3.12) (4.13, 5.80) (6.88, 16.00) p (1.20, 1.50) (2.13, 2.76) (3.70, 5.20) (6.23, 14.50) p (1.85, 2.40) (3.28, 4.60) (5.60, 13.00) p (2.85, 4.00) (4.95, 11.50) p (4.30, 10.00) buffer occupancy is high. However, this strategy may not work for a video with wider gaps between bitrates. We consider both scenarios to evaluate how the aggressiveness of different methods can affect QoE. Since YouTube uses an efficient title-based encoding method [10], we studied bitrate ladder of over 200 videos from different categories on YouTube. As shown in Figure 3, from each representation to the next one the bitrate roughly doubles. However, the video sequences used in research papers usually have tighter gaps [11][20]. So we use two video sequences, the first one is EnvivioDASH3 1 which is used in [11] and encoded at lower bitrates with narrower gaps. The second is Tears of Steal (ToS) 2 [9], and we used the bitrates according to its YouTube version 3, encoded at higher bitrate with wider gaps. Each video is available in 6 different resolutions:{240p, 360p, 480p, 720p, 1080p, 1440p}. We selected the first 200 seconds of each video, with chunk duration of 4 seconds, for a total of 50 chunks per video. The bitrates for each video are provided in Table 1. Bitrate of each representation, r rep, is in the third column, and it is the same as the bitrate for the base layer of SVC representations. All other columns to the right are the cumulative bitrates up to a specific enhancement layer for SVC version. SVC encoded videos are generated from the non-svc videos with the assumption of 15% more bitrate per layer compared to non-svc one at the same quality level. With the combination of 3G and 4G traces and two videos, we have 4 different scenarios. We refer to these scenarios with format of (3g/4G-Envivio/ToS) Adaptation algorithms. We have chosen the following adaptation algorithms for comparison: Pensieve: This method uses reinforcement learning to train an algorithm that maximizes QoE [11]. We used the source code and trained model provided by the authors

5 MPC: This method tries to make QoE-optimal decisions by considering throughput measurements of past 5 downloaded chunks and buffer occupancy as feedback signals [20]. We used robustmpc implementation with error prediction in throughput estimation 4. BOLA: We used BOLA [17] implementation available in dash.js version Dash.js: We used the default throughput-based adaptation algorithm of dash.js reference client as a throughput-based method. We used dash.js client version 2.6.2s 5. Buffer-based: The method introduced by Huang et al. [5] is used as a pure buffer-based adaptation algorithm. We used the implementation provided with Pensieve authors 4. The parameters for reservoir and cushion were set to 0.1B and 0.8B, respectively. WQUAD: This is an adaptation method designed for SVC encoded video [6]. We implemented this method in our experimental framework. For all the above methods except WQUAD, the Pensieve automated experimental setup is used to record information about QoE. We implemented LAAVS and WQUAD in Java. The client sends requests to the server through an HTTP connection, and places the downloaded chunks inside its buffer. Playback is emulated, and logs containing all information about downloading chunks, playback quality, and rebuffering events are recorded. All adaptation methods were configured to have a buffer with duration of B = 60s QoE metric. To measure achieved QoE from different adaptation algorithms, we use the QoE metric introduced in [20]. This metric is calculated by assigning weights to overall quality, rebuffering duration, and switches count. In this metric, instead of considering a subjective or objective quality level for each chunk, the average bitrate of each chunk is considered for quality. Let R t denote the bitrate of t th chunk, and RB t denote the duration of rebuffering during downloading that chunk. Equation (6) shows the QoE calculation for a video with N chunks. Rebuffering is penalized by weight of µ which is considered equal to the highest bitrate of a video. Quality switches are penalized by weight of -1. N N N 1 QoE = R n µ RB n R n+1 R n (6) n=1 n=1 n=1 Since the bitrate of SVC video is higher than non-svc one, we consider R t of an SVC video equal to the bitrate of the non-svc videe at the same quality level. For each video streaming session, we calculate the average QoE by dividing the output of equation (6) by the number of chunks. 4.2 Results Figure 4 shows the results for all adaptation algorithms in each scenario. QoE is normalized according to the maximum value. In all scenarios, LAAVS outperforms other methods in terms of QoE by at least 4% and up to 64%. This performance is achieved by streaming highest possible bitrate with less rebuffering events and low switches. In some cases, such as 3G-ToS, although LAAVS has lower bitrate than BB and MPC, it has less rebuffering and switches. 5 Figure 4: QoE and its components for different scenarios In most cases, LAAVS is followed by Pensieve. It has been shown in [11] that Pensieve s QoE is around 10% lower than the offline optimal in 3G-Envivio scenario. LAAVS performs 4% better than Pensieve in this scenario. However, Pensieve has the lowest QoE in ToS-4G scenario. Pensieve is trained with 3G network bandwidth traces that have lower bandwidth capacity compared to 4G traces. Moreover, Pensieve was trained for videos with narrow gaps between bitrates. Considering six quality levels, most of the time Pensieve uses quality levels 1,2,4, and 6. It fills the buffer with low quality chunks, and then jumps to a quality level with bitrate higher than network throughput. Since gaps between bitrates is not wide, it can stay at those quality levels for a while and then switch back to a lower quality level. This approach increases QoE for 3G-Envivio scenario, but fails for videos with higher bitrate gaps. Therefore, although it performs well in the trained scenarios, under other conditions with another video with different bitrate ladder the performance degrades drastically. One of the main reasons behind designing LAAVS is reducing rebuffering. Since client can enhance quality later, when buffer occupancy is low, it switches to lower qualities and stays at those levels. If network conditions improve, client switches to higher quality and backfills lower quality chunks. Otherwise, it has switched to a lower quality earlier, and prevented rebuffering to happen. BB and WQUAD have lower rebuffering than LAAVS in most scenarios, but at the cost of lower bitrate and QoE. LAAVS is able to stream higher bitrate video with low rebuffering. WQUAD streams pure SVC video. As it always starts from the lowest base quality and then backfills, it reduces rebuffering significantly. However, it has the lowest bitrate score in all scenarios. The reason is SVC encoding overhead. For example if the client wants

6 5 CONCLUSION We presented a new technique for HAS, called LAAVS. It has the advantages of SVC video without incurring associated overhead all the time. LAAVS uses both throughput estimation and buffer occupancy information to prefetch and backfill chunks. So it can switch and stay at low quality chunks during bandwidth drops and backfill later. This method reduces rebufferings significantly without compromising quality. Our experimental results using realworld bandwidth traces show that LAAVS can outperform existing solutions such as Pensieve. Figure 5: Heatmap of QoE for 3G-Envivio Scenario Table 2: % of downloaded enh. layers per scenario % of chunks backfilled with Trace-Video enh. layer: G-Envivio G-Envivio G-ToS G-ToS to stream highest resolution, then it has to download the video with 75% higher bitrate. Therefore, it has lower QoE score in general. In terms of switching, whenever LAAVS backfills, not only it enhances the quality, it also reduces the quality variations. So, although LAAVS does not control quality switches in start-up state, and has some unnecessary down switches in the PB state, backfilling enables it to have relatively low switching frequency in all scenarios. Figure 5 presents the heatmap of QoE results for 3G-Envivio scenario. Each heatmap demonstrates how QoE for an adaptation method changes according to average throughput and throughput variation of a bandwidth trace. X axis is average throughput, and Y axis is throughput standard deviation. Each point is the achieved QoE for a single bandwidth trace. QoE values are demonstrated with colors, and we filled the gaps between points by interpolation. Higher network throughput results in higher QoE, and lower throughput with high variation results in lower QoE because of rebufferings. Although Pensieve and MPC have achieved high QoE for high throughput scenarios, they have poor performance in low throughput and high variance traces. BB and WQUAD have higher QoE for low throughput and high variance scenarios. LAAVS is able to combine the benefits of SVC and non-svc together. In high throughput scenarios it has high QoE (unlike BB and WQUAD), and in low throughput and high variation scenarios it has comparable performance to BB and WQUAD Overhead and Complexity. LAAVS tries to avoid using all layers (low quality base layer) when it is unnecessary. Table 2 shows the percentage of backfilled chunks with enhancement layers from different levels for all scenarios. It can be seen that most of the time enhancement layers up to level 3 are required. Thus, using LAAVS, up to 3 layers can be used which can decrease encoding, storage, and decoding overhead and complexity. 6 ACKNOWLEDGMENTS This work was supported in part by a gift from Cisco Systems, Inc. REFERENCES [1] S. Akhshabi, A. C Begen, and C. Dovrolis An experimental evaluation of rate-adaptation algorithms in adaptive streaming over HTTP. In Proc. ACM MMsys. [2] J. M Boyce, Y. Ye, J. Chen, and A. K Ramasubramonian Overview of SHVC: scalable extensions of the high efficiency video coding standard. IEEE Transactions on Circuits and Systems for Video Technology 26, 1 (2016), [3] F. Chiariotti, S. D Aronco, L. Toni, and P. Frossard Online learning adaptation strategy for DASH clients. In Proc. ACM MMSys. [4] J. Famaey, S. Latré, N. Bouten, W. Van de Meerssche, B. De Vleeschauwer, W. Van Leekwijck, and F. De Turck On the merits of SVC-based HTTP adaptive streaming. In 2013 IFIP/IEEE International Symposium on Integrated Network Management (IM 2013). IEEE, [5] T. Huang, R. Johari, N. McKeown, M. Trunnell, and M. Watson A bufferbased approach to rate adaptation: Evidence from a large video streaming service. ACM SIGCOMM 44, 4 (2015), [6] J. Hwang, J. Lee, and C. Yoo Eliminating bandwidth estimation from adaptive video streaming in wireless networks. Signal Processing: Image Communication 47 (2016), [7] J. Jiang, V. Sekar, and H. Zhang Improving fairness, efficiency, and stability in http-based adaptive video streaming with festive. In Proceedings of the 8th international conference on Emerging networking experiments and technologies. ACM, [8] J. Kua, G. Armitage, and P. Branch A Survey of Rate Adaptation Techniques for Dynamic Adaptive Streaming over HTTP. IEEE Communications Surveys & Tutorials (2017). [9] S. Lederer, C. Müller, and C. Timmerer Dynamic adaptive streaming over HTTP dataset. In Proc. ACM MMSys. ACM, [10] Y. Lin, H. Denman, and A. Kokaram Multipass encoding for reducing pulsing artifacts in cloud based video transcoding. In Proc. IEEE ICIP [11] H. Mao, R. Netravali, and M. Alizadeh Neural Adaptive Video Streaming with Pensieve. In Proceedings of the Conference of the ACM Special Interest Group on Data Communication. ACM, [12] R. Mok, E. Chan, and R. Chang Measuring the quality of experience of HTTP video streaming. In 12th IFIP/IEEE International Symposium on Integrated Network Management (IM 2011) and Workshops. IEEE, [13] R. Netravali et al Mahimahi: a lightweight toolkit for reproducible web measurement. ACM SIGCOMM 44, 4 (2015), [14] S. Petrangeli, N. Bouten, M. Claeys, and F. De Turck Towards SVC-based adaptive streaming in information centric networks. In Proc. IEEE ICMEW [15] H. Riiser, P. Vigmostad, C. Griwodz, and P. Halvorsen Commute path bandwidth traces from 3G networks: analysis and applications. In Proc. ACM MMSys [16] M. Seufert, S. Egger, M. Slanina, T. Zinner, T. Hoßfeld, and P. Tran-Gia A survey on quality of experience of http adaptive streaming. IEEE Communications Surveys & Tutorials 17, 1 (2015), [17] K. Spiteri, R. Urgaonkar, and R. Sitaraman BOLA: near-optimal bitrate adaptation for online videos. In Proc. IEEE INFOCOM. IEEE, 1 9. [18] Y. Sun, X. Yin, J. Jiang, V. Sekar, F. Lin, N. Wang, T. Liu, and B. Sinopoli Cs2p: Improving video bitrate selection and adaptation with data-driven throughput prediction. In Proc. ACM SIGCOMM [19] G. Tian and Y. Liu Towards agile and smooth video adaptation in dynamic HTTP streaming. In Proceedings of the 8th international conference on Emerging networking experiments and technologies. ACM, [20] X. Yin, A. Jindal, V. Sekar, and B. Sinopoli A control-theoretic approach for dynamic adaptive video streaming over HTTP. ACM SIGCOMM 45, 4 (2015),