Streaming with Real Bitrates and Solving Bandwidth Competition on Bottleneck in DASH

全文

(1)國立臺灣師範大學資訊工程研究所碩士論文指導教授：. 賀耀華. 博士. Streaming with Real Bitrates and Solving Bandwidth Competition on Bottleneck in DASH. 研究生：王明宇中華民國. 105. 年. 撰 2. 月.

(2)

(3) Abstract By 王明宇 [email protected] HTTP adaptive streaming is increasingly popular in multimedia delivery nowadays. The nature of HTTP provides easy deployment to content provider and chunk-based delivery enables dynamic adaption of video quality to varying network bandwidth. In this paper, we address two topics in HTTP adaptive streaming. First is the impact of bitrate disparity. In the previous work, it shows that the advertised bitrates by manifest file and the actual bitrates are significantly different. The result of inaccurate estimation causes buffer oscillations or even buffer underrun because clients frequently select higher bitrates than the network bandwidth. To employ the extensibility feature of DASH syntax, we present a systematic method for selecting the segment which real bitrate is the closest one to the given estimated throughput. The second topic is the well-known bandwidth competition on the bottleneck. We adopt logistic function to estimate bandwidth while using it to detect occurrences of bandwidth oscillations due to competition. We propose an algorithm written on client side to stabilize the requested bitrates in competition interval. The experiments show that our solutions stabilize client behavior in competition state and streaming with real bitrates improves buffer oscillations. Keywords: HTTP adaptive streaming, DASH, Video encoding, MPD, Competition, Algorithm, Fairness, Efficiency. i.

(4) Table of Contents Abstract .......................................................................................................................... i Acknowledgements ..................................................................................................... iv List of Tables ................................................................................................................ v List of Figures .............................................................................................................. vi 1. Introduction ............................................................................................................ 1 2. Background ............................................................................................................ 5 A. HTTP adaptive streaming and DASH ................................................................5 B. Network characteristics of video streaming traffic ...........................................6 C. Root cause of performance problems under bandwidth competition .............7 3. Impact of Bitrate Disparity ................................................................................... 9 4. Streaming with Real Bitrates .............................................................................. 15 A. Optimizing Segment Selections ....................................................................... 15 B. Throughput Estimation ...................................................................................... 17 C. Comparison ......................................................................................................... 19 5. Stabilizing Bandwidth under Competition ........................................................ 25 A. Motivation ........................................................................................................... 25 B. Basic Idea ............................................................................................................ 26 C. Algorithm ............................................................................................................ 27 6. Performance Evaluation ...................................................................................... 29 A. Network Setup .................................................................................................... 29 B. Bandwidth Throttling ........................................................................................ 29 C. Results & Evaluation ......................................................................................... 30 7. Related Work ....................................................................................................... 37 8. Conclusions & Future Work ............................................................................... 39. ii.

(5) To Dear Family. iii.

(6) Acknowledgements 進入研究所後，從毫無研究經驗開始學習，在決定研究主題後一步步從發現問題到必須提出與過去不同的方法，再到系統建置，分析實驗結果。歷經這些過程後，著實體會需要投入多大的心力才能完成這樣的一篇論文，中間的辛苦與挫折以及完成的快樂與成就感也只有當事人才能點滴在心頭。在此先特別感謝同校(國立臺灣師範大學)的葉梅珍博士與中央研究院資訊科學研究所的陳孟彰研究員，兩位客觀且嚴格地指出我論文的缺點，讓我能重新專注並通盤檢討該改進的地方，讓自己重新將研究成果在論文中好好展現出來。另外也特別感謝 Mr. Ran Dubin, 他的論文讓我以影片複雜度為啟發開始檢討改進，中間並耐心教導我如何使用負責影片編碼的工具。這篇論文背後正式以影片複雜度為基礎加上 HTTP 串流的精神所完成。最後要感謝對我最重要的家人，讓我能無後顧之憂，全心全意地好好完成學業。 First and foremost, I would like to thank Dr. Yeh (National Taiwan Normal University) and Dr. Chen (Institute of Information Science, Academia Sinica) for rectifying problems in my thesis. They made me refocus on the problems and complete this thesis. Second, I would like to thank Mr. Ran Dubin, his paper inspired me from video complexity and he taught me how to use video encoding tool. Finally, I would like to thank my Family, the most important people in my life, there are always no enough words to express my gratitude to them.. iv.

(7) List of Tables Table 1: Details of each representation. ........................................................................ 10 Table 2: Differences between Advertised bitrates and Real bitrates. ........................... 13 Table 3: Segment Index, Duration and Avail-BW in each sector. ................................ 19 Table 4: Number of segments requested by each player in five sectors. ...................... 22 Table 5: The percentage of requested bitrates over average throughput in five sectors. ....................................................................................................................................... 23 Table 6: Buffer status of each player. ........................................................................... 23 Table 7: Bandwidth utilization of each player in five sectors. ..................................... 23 Table 8: Unfairness and Inefficiency of five runs in Case 1. ........................................ 31 Table 9: The lowest and highest throughput in WD and Ceil Rate in Case 2. .............. 33 Table 10: Number of segments over and below fair share in Case 2. .......................... 33 Table 11: Unfairness and Inefficiency of five runs in Case 2....................................... 34 Table 12: The lowest and highest throughput in WD and Ceil Rate in Case 3. ............ 35 Table 13: Number of segments over and below fair share in Case 3. .......................... 36 Table 14: Unfairness and Inefficiency of five runs in Case 3. ...................................... 36. v.

(8) List of Figures Figure 1: Peak period traffic composition of fixed access in North America [1]. .......... 1 Figure 2: HTTP Adaptive Streaming System. ................................................................ 5 Figure 3: HTTP traffic pattern in Buffering and Steady states. ...................................... 6 Figure 4: Three cases of ON-OFF periods of two competing players. ........................... 7 Figure 5: Real bitrate of each segment in 1500 kbps representation. ........................... 13 Figure 6: Bitrate deviation in each representation. ....................................................... 14 Figure 7: Syntax of segInfo element. ............................................................................ 15 Figure 8: An example of MPD with extended metadata. .............................................. 16 Figure 9: Relationship of p and α.................................................................................. 18 Figure 10: Throughput estimation using the logistic function. ..................................... 19 Figure 11: Real bitrates and buffer state of P1. ............................................................. 20 Figure 12: Advertised bitrates and buffer state of P2. ................................................... 20 Figure 13: Bitrate of each segment that P2 actually requested...................................... 21 Figure 14: Ratio of download bitrate to instant throughput. ......................................... 21 Figure 15: Download duration of each player. ............................................................. 22 Figure 16: Requested bitrates in the competition interval (300s – 480s). .................... 25 Figure 17: An oscillation pattern in HAS. .................................................................... 27 Figure 18: Test network for experiments. ..................................................................... 29 Figure 19: Our algorithm reduces unfairness and inefficiency. .................................... 31 Figure 20: The algorithm was activated in P1 from 5 – 8 minutes. .............................. 32 Figure 21: The Ceil Rate was cut off from 1308 to 1046 kbps..................................... 33 Figure 22: Both players run the algorithm. ................................................................... 34 Figure 23: Two players cut off their ceil rate at different times. .................................. 35. vi.

(9) 1. Introduction Over the past years, streaming video over Internet is dominating broadband and mobile traffic. According to Sandvine [1], real-time entertainment (streaming video and audio) traffic accounts for 70 percent of the fixed access web traffic in 2015, doubled from 35 % from five years ago. It is the same story that video/audio represents 41 % usage in mobile access.. Figure 1: Peak period traffic composition of fixed access in North America [1].. A new paradigm named HTTP adaptive streaming (HAS) has brought a new way in video delivery. Its popularity comes from many features [5, 13], which are summarized below: 1. HTTP-based delivery provides simple transport process due to HTTP and underlying TCP/IP protocol. 2. HTTP-based delivery allows content provider to use standard HTTP servers and. 1.

(10) standard HTTP caches, so that it can be delivered from Content Delivery Network (CDN) or other standard server farms. 3. HTTP-based delivery provides the ability to move control of streaming session from server to client, hence it is a cost effective mean compared to traditional stateful protocols. 4. HTTP-based delivery provides clients to change content rate on the fly to react to varying network bandwidth. This makes clients choose initial content rate and match available bandwidth without negotiating with streaming servers. 5. HTTP-based traffic avoids NAT and firewall traversal issues which encountered by UDP traffic. Based on these advantages over other streaming techniques, we address two topics in HAS systems and provide solutions to solve each one of them in this paper. Our study focus on Dynamic Streaming over HTTP (DASH), a standard published by ISO [4], and our solutions can be easily integrated to other proprietary solutions [2, 3] as well. In the first part, we discuss the claim of significant differences between advertised bitrates by the manifest file and real encoding bitrates [21, 23]. We use FFmpeg [34] to encode video “Big Buck Bunny” to seven representations for streaming and find the same fact of bitrate disparity. A lack of such information on client side produces unexpected behavior due to incorrect segment selections. One of them is buffer oscillations because selected bitrates are often higher than advertised bitrates and the estimated throughput. To solve this problem, we introduce real bitrate information of each segment in different representations by employing the extensibility feature of DASH syntax [4]. The client can receive actual bitrates of each segment after downloading the manifest file and the additional metadata does not count much extra. 2.

(11) file size. Further, we adopt logistic function to estimate available bandwidth and compare the behavior of selecting segments by real bitrates and advertised bitrates. With real encoding bitrates, players can make correct selections, which conform to the spirit of HTTP adaptive streaming and improve buffer oscillations. Next, we propose a solution to deal with bandwidth competition on the bottleneck between two players and the solution is based on the logistic function used in the first part. Typically, in a streaming session, an adaptive streaming player first operates in the Buffering-State then in the Steady-State. In the Buffering-State, player requests next video segment as long as the previous one has been downloaded. On the other hand, player periodically requests new segment in the Steady-State, once per segment duration (T seconds). If two or more players share the same bottleneck link, the overlaps of their ON-OFF periods can make them both overestimate the available bandwidth. Consider, for instance, the case that ON period of player X overlaps with OFF period of another player Y, player X will overestimate the available bandwidth because the download does not share the bottleneck with player Y. Player X will then decide to switch to a higher video profile, and results in congestion because the bitrate is not sustainable. Player X then switches back to a lower profile and thus starts oscillations until the bottleneck disappears. Previous studies [22, 23] summarized ONOFF period is the root cause behind competition and many works proposed solutions to eliminate the OFF periods either on the server or on the gateway by shaping downloading traffic for each client. The rationale behind our algorithm is similar to previous solutions [24, 25], in contrast, our solution does not need any cooperation with network infrastructure. Based on logistic function, we use it to detect bandwidth oscillations caused by competition and calculate a ceil rate by an algorithm directly implemented inside the adaptation logic. The algorithm will step down the ceil rate if it. 3.

(12) was set too high and be deactivated when the competition is over. Streaming only with real encoding bitrates can extend the ON periods but still not be able to completely eliminate the OFF periods, but we combine the real bitrates to the algorithm to assure that requested bitrates are under the ceil rate and not to affect the fair share between two players. In summary, this paper makes the following contributions: . An adaptive player can get the actual bitrate information of each segment by downloading the manifest file as usual.. . Streaming with real bitrates can get segments that are real close to network throughput and improve buffer oscillations.. . We design an algorithm to reduce bandwidth competition between two adaptive players without any help of network infrastructure.. . Our algorithm with real encoding bitrates can assure requested bitrates not to exceed the ceil rate and further affect the fair share between two players.. The remainder of this paper is organized as follows. In Chapter 2, we provide backgrounds covering the architecture of an HAS system, network characteristics of streaming traffic and the root cause of performance problems when two players compete on bottleneck. In Chapter 3, we discuss the impact of bitrate disparity and discover the same result by encoding a video with FFmpeg for video streaming. In Chapter 4, we present a metadata-based method to select video segments that are real close to estimated throughput. Our algorithm to reduce bandwidth competition, experiment settings and results are presented in Chapter 5 and 6. Chapter 7 describes the related works. Finally, conclusions and future work are given in Chapter 8.. 4.

(13) 2. Background A. HTTP adaptive streaming and DASH. Figure 2: HTTP Adaptive Streaming System.. Figure 2 shows the basic architecture of an HTTP adaptive streaming system. As mentioned in introduction, HTTP adaptive streaming is a sequence of HTTP GET requests and responses. In HAS systems [2, 3], a video content is encoded into multiple representations and each one represents different bitrate and video quality. Each bitrate stream is further divided into several segments (or chunks) of 2-10 seconds. The adaptive player on client side implements the adaptation logic to estimate the network throughput from the downloading rates observed from past segments. The adaptive player selects appropriate segments while maintain an adequate playback buffer to minimize rebuffering events that can adversely affect user engagement [9]. In MPEG-DASH [4, 5], it defines a clear picture of the system architecture and the format of metadata called Media Presentation Description (MPD). The hierarchy of video content is defined in the structure of MPD [5, 7]. The MPD is an XML document containing information about video segments and other metadata that may be needed by clients. From the top of MPD, a video content can be logically split into multiple periods of same length or variable length. In a single period, it contains one or more adaptation sets which represents video or audio data. The adaptive player selects. 5.

(14) the appropriate representations in the adaptation set until the end of this period. A period can contain one or more Subset elements, which expresses the combination between adaptation sets (combination of video and audio) and the intention of creator of this MPD [29, 30]. The MPD file is first downloaded and parsed by clients and video streaming starts as stated before. HTTP-based streaming protocol differs from the traditional connection-oriented transport protocols in three main aspects. First, the client controls the streaming session and decides which segment to be fetched next. Servers do not need to keep state of any playback session. Second, the use of HTTP protocol makes streaming traffic not blocked by NATs and firewalls [13]. Third, existing server technology such as CDN enables load balancing and fault tolerance to HAS systems and brings low cost to content deployment. Hence, HTTP adaptive streaming has become the mainstream technique in video delivery. B. Network characteristics of video streaming traffic. Figure 3: HTTP traffic pattern in Buffering and Steady states.. 6.

(15) In a streaming session, an adaptive streaming player typically starts in the Buffering-State. The goal of player at this state is to build up enough playback buffer as quickly as possible. To achieve this goal, the player requests new segment as soon as the previous one has been downloaded. After the buffer reaches a minimum threshold (e.g. 10 seconds), the player switches to the Steady-State to keep constant playback buffer. Assume each segment corresponds to T seconds of content, the player requests one segment every T seconds (if download duration is less than T), or immediately after previous segment is received (otherwise). This periodic activity produces cycles of ON-OFF periods. During each ON period, the data of segment is transferred at the end-to-end bandwidth that can be used by TCP; the TCP connection is idle during the OFF periods. This pattern is illustrated in Figure 3. C. Root cause of performance problems under bandwidth competition. Figure 4: Three cases of ON-OFF periods of two competing players.. Previous works [22, 23] have shown that multiple players will compete bandwidth when sharing a link on the Internet. They have shown that the link becomes the bottleneck and causes many performance problems, e.g., instability, unfairness and bandwidth underutilization. The root cause of these performance problems is the temporal overlaps of the ON-OFF periods among competing players. Figure 4 shows. 7.

(16) three cases where the ON periods of player-1 may overlap with another player, player2. In the first case, two players both overestimate their fair share and cause congestion. When that happens, they will switch back to a lower representation because their TCP throughput is less than their previous estimation. This scenario can repeat, causing instability. Instability can also cause bandwidth underutilization. Suppose that two players oscillate between a lower profile P1 and a higher profile P2. The link capacity, C = P1 + P2, is fully utilized that one player requests P1 and the other requests P2. However, it is possible that both players request lower profile P1 and lead to significant underutilization. The second case shows the ON periods of Player 2 falls within the ON periods of Player 1. It can lead to a situation that two players converge to a stable but unfair equilibrium when one player overestimates the fair share. The third case shows the ON periods of two players are perfectly aligned. Both players observe a fair share of link capacity and stay stable, though previous work [22] shows there are still chances causing bandwidth underutilization in this case. In [24, 25], authors proposed solutions on server and gateway by eliminating the OFF periods to make overlaps reach the state as case 3.. 8.

(17) 3. Impact of Bitrate Disparity In an HAS system, an adaptive streaming player chooses the bitrate of next segment according to the estimated bandwidth. The advertised bitrate of each representation is embedded in the manifest file and being downloaded before the streaming session starts. From previous work [21], it shows that advertised bitrates and the actual bitrates of requested segments are drastically different in many resources, including the public DASH video dataset [32]. What is the impact of bitrate disparity in an HAS system? An adaptive player can only make bitrate selections from the pool of advertised bitrates. If the actual bitrate was higher than the advertised bitrate, the download duration would be longer than expected and the buffer started to drain. In the worst case, the player would switch back to the Buffering-State to rebuild minimum playback buffer. If the actual bitrates were lower than the advertised bitrates, the player would overestimate the available bandwidth and choose higher profile in the next round. The disparity causes incorrect segment selections and aggravates buffer oscillations. Encoding videos in constant bitrate (CBR) still has the same problem because it is hard to be enforced on a small segment granularity. Encoding an entire video to same rate can be challenging without quality degradation because some video frames can be more complex than other frames at different times. In this chapter, we encode a famous video, “Big Buck Bunny”, with libx264 of FFmpeg for our streaming experiments and show the deviation of real bitrates in each representation. Then, we provide a metadata-based method to select video segments that are real close to estimated throughput in the next chapter. FFmpeg [34] is a powerful multimedia framework for handling video/audio data. FFmpeg includes many libraries such as libavcodec, libavformat to be used by several. 9.

(18) projects and applications. FFmpeg also includes a command line program for transcoding multimedia files. In this paper, we use libx264 to encode video into H.264/MPEG-4 format. We generate seven video sequences with various predefined bitrates and resolutions, as listed in Table 1. Our video source is from Xiph database [33] and the raw file of “Big Buck Bunny” is 42 GB in full HD resolution. Table 1: Details of each representation.. Sequence 1 Sequence 2 Sequence 3 Sequence 4 Sequence 5 Sequence 6 Sequence 7. Advertised Bitrate (kbps) 400 800 1200 1500 1800 2100 2500. Resolution 480x360 1280x720 1280x720 1280x720 1920x1080 1920x1080 1920x1080. Frame Rate 24 24 24 24 24 24 24. In order to generate these sequences, we have to first encode the raw file into an mp4 file with the command below. ffmpeg –f rawvideo –vcodec rawvideo –s 1920x1080 –r 24 –pix_fmt yuv420p –i big_buck_bunny_1080p24.yuv –c:v libx264 –x264opts keyint=48:keyint_min=48:no-scenecut –preset medium –qp 0 output.mp4 The parameters in this command explain how we encode the video. The pixel format of raw file is yuv420p and the resolution of encoded video remains the same at Full HD. We encode the raw file with libx264 and set the frame rate to 24 frames per second. FFmpeg provides us to overwrite default preset settings with the “x264opts” option. We set the maximum interval between key frames with parameter “keyint” and the minimum interval with parameter “keyint_min”. This setting is very important as we will split the video into segments and at the beginning of each segment must be a key frame. We decide to split video into 2-second segments later so we set the interval. 10.

(19) to be the multiple of frame rate (2 * 24). Parameter “no-scenecut” completely disables adaptive key frame decision. Besides, this is a lossless compression so the quantization parameter is set to zero. The bitrate of output.mp4 is 98286.98 kbps. With the output file, output.mp4, we can further generate different sequences and split the video into 2second segments without glitch. Next, we use 2-pass encoding to generate each sequence. Comparing to Constant Rate Factor (CRF), which attempts to achieve a certain output quality for the whole video when output file size is of less importance, video streaming must control the target bitrate and the file size. In 1-pass encoding, the encoding is done in the first pass itself. However, in 2-pass encoding, the file is analyzed thoroughly in the first pass and a log file is created. Then, the encoder (x264) checks the log file and appropriately allocates bits, so the actual encoding process takes place in the second pass. To suit the feature of video streaming, 2-pass encoding produces more accurate output than 1-pass encoding. We list two commands to be used separately as below. Pass 1: ffmpeg -i big_buck_bunny_1080p24.mp4 -s 480x360 -c:v libx264 -x264opts keyint=48:keyint_min=48:no-scenecut -preset medium -b:v 400k -maxrate 400k -bufsize 800k -pass 1 -f mp4 /dev/null. Pass 2: ffmpeg -i big_buck_bunny_1080p24.mp4 -s 480x360 -c:v libx264 -x264opts keyint=48:keyint_min=48:no-scenecut -preset medium -b:v 400k -maxrate 400k -bufsize 800k -pass 2 -f mp4 output_400k.mp4. Here we rename output.mp4 to big_buck_bunny_1080p24.mp4 for convenience. We use libx264 and set the target bitrate with the parameter “b:v”. The trick is in two. 11.

(20) parameters, “maxrate” and “bufsize”. The VBV (Video Buffer Verifier) system in x264 is used to constrain the output bitrate so it is suitable for streaming in bandwidthconstrained environment. In x264, it has “vbv-bufsize” to control the buffer size and “vbv-maxrate” to control the rate which the buffer fills. By the rule of thumb, we set both values to the double of “bitrate” in libx264 parameters. After our test, all sequences are smooth without quality degradation and glitches with this setting. Finally, we use MP4Box from GPAC [35], which supports generation of fragmented MP4 files and basic MPDs for separate representation. To prepare for adaptive streaming, we use the following instruction to create the DASH manifest file and content segments. MP4Box -dash 2000 -frag 2000 -rap -segment-name segment_ output_400k.mp4 The “dash” parameter segments the given file into 2-second segments. The “frag” parameter creates sub-segments within segments. By setting to the same value, there will be only one subsegment per segment. “The “rap” parameter forces segments to start from specific access points, i.e. key frames. Segment duration may vary due to where the key frames are in the video. That is why we encoded the video with the appropriate settings before. The parameter “segment-name” sets the name of the segments. As a result, the name of the first segment of this representation is segment_1.m4s. We repeat previous three commands from 2-pass encoding to MP4Box to generate seven representations. As mentioned in the beginning of this chapter, bitrate disparity indeed appears in each representation. We show the real bitrate of each segment in 1500 kbps as an example in Figure 5.. 12.

(21) 3000 Segment Bitrate. Bitrate (kbps). 2500 2000 1500 1000 500 0. 0. 100. 200. 300. Segment Index Figure 5: Real bitrate of each segment in 1500 kbps representation.. From Figure 5, we can see that most real bitrates oscillate between 1200 kbps and 1800 kbps. Many segments are actually in sequence 3 to sequence 5 and some even jump between sequence 3 and sequence 6. In Table 2 and Figure 6, we list the detail and draw the box plot for each representation. Again, in traditional HTTP adaptive streaming or DASH, the client side will not receive such information. The client will not know whether it selects the bitrates as expected. To solve this, we will provide a metadata-based method to provide accurate bitrate information to clients and make them select the right segments. Table 2: Differences between Advertised bitrates and Real bitrates.. Sequence 1 Sequence 2 Sequence 3 Sequence 4 Sequence 5 Sequence 6 Sequence 7. Advertised Bitrate (kbps). Min. Max. Average. Deviation. 400 800 1200 1500 1800 2100 2500. 110 217 303 368 458 524 618. 679 1363 2011 2473 3002 3448 4046. 407 813 1219 1523 1827 2129 2533. 85.02 168.08 248.58 309.98 372.77 433.67 504.48. 13.

(22) 4500 4000 3500. Bitrate (kbps). 3000 2500. 2000 1500 1000 500 0 400 kbps. 800 kbps. 1200 kbps 1500 kbps 1800 kbps 2100 kbps 2500 kbps. Figure 6: Bitrate deviation in each representation.. 14.

(23) 4. Streaming with Real Bitrates A. Optimizing Segment Selections As mentioned, we focus on a metadata-based method for optimal segment selections in MPEG DASH. The DASH syntax provides few places for extensibility [4]. The Subset element can provide combination of adaptation sets (video/audio) within a period as in previous work [29]. Because we focus only on the video segment selections, here we extend the Subset element containing one adaptation set (video) to help clients make correct choices. The advantage of extending Subset element is to have a clean space for bitrate information, not complicating the structure of every Representation element.  <xs:element name=”segInfo”> <xs:complexType> <xs:sequence> <xs:element name=”id” type=”xs:integer” /> <xs:element name=”bitrates” type=”valuelist” /> </xs:sequence> </xs:complexType> </xs:element> <!—Definition of type valuelist --> <xs:simpleType name=”valuelist” > <xs:list itemType=”xs:interger” /> </xs:simpleType>. Figure 7: Syntax of segInfo element.. The bitrate information of one segment is described by the segInfo element in XML schema in Figure 7. This complex element contains two elements, id element and bitrates element. We specifically define the type valuelist to present a list of integers for real bitrates in all seven representations. Hence, in every segInfo element,. 15.

(24) an adaptive player can easily find which index this segment is and the list of real bitrates mapping to each representation. Figure 8 shows an example of MPD containing real bitrate information obtained from the last chapter. This MPD uses one Subset element to contain bitrate information of all segments. In this example, an adaptive player can simply choose the real bitrate closest to the given estimated throughput. Our video, “Big Buck Bunny”, is composed of 299 segments which is 9 minutes and 56 seconds long. The extra information just takes additional 30 KB in the manifest file (137 KB in total), so slowing down the download of manifest file will not become a side effect of this method. <MPD …> <Period duration="PT0H9M56.46S"/> <AdaptationSet segmentAlignment="true" …> <Representation id="1" mimeType="video/mp4" …> … </Representation> … </AdaptationSet> <Subset contains=”1”/> <segInfo> <id>1</id> <bitrates>389 778 1191 1540 1871 2220 2723</bitrates> </segInfo> … <segInfo> <id>299</id> <bitrates>110 217 303 368 458 524 618</bitrates> </segInfo> </Subset> </Period> </MPD>. Figure 8: An example of MPD with extended metadata.. 16.

(25) B. Throughput Estimation With the metadata above, the key part in HAS system is still the adaptation logic. Adaptation logic is in charge of estimating current network throughput Te (i). The instant throughput Ts (i) in general is obtained by dividing the amount of data by the delivery duration [11, 12, 29]. In previous works [15, 29], we have seen that a good adaptation logic can estimate throughput to real throughput as close as possible. Another important aspect is that it can smooth the effect of short-term fluctuations and quickly response to significant fluctuations. In this paper, to obtain the estimated throughput for next segment i, we use an estimation model based on the running average of previous downloaded segments [11, 12, 29] as the following equation:. 𝑇𝑒(i) = {. (1 − 𝛼)𝑇𝑒(𝑖 − 2) + 𝛼𝑇𝑠(𝑖 − 1), 𝑖 > 2 . 𝑇𝑠(𝑖 − 1), 𝑖 = 1, 2. (1). Note that Te (0) for segment 0 is needed when computing the value of Te (2). Te (0) is usually obtained by downloading the lowest bitrate alternative instead. As the equation shows, higher the value of alpha is, more the estimated throughput depends on the last segment throughput. To smooth the effect of short-term fluctuations, a small value of alpha should be used. If the bandwidth keeps oscillating, the value of alpha will take control of this equation with a relatively large value. For each segment, we compute the normalized throughput deviation [29] as follows:. 𝑝=. |𝑇𝑠(𝑖)−𝑇𝑒(𝑖)| 𝑇𝑒(𝑖). .. (2). The value of p indicates the degree that current throughput differs from the estimated throughput. A small value of p suggests using a relatively smooth throughput (𝛼 -> 0). Meanwhile, a significant change requires a quick response, and thus the value of 𝛼. 17.

(26) should approach to 1. The general relationship between p and 𝛼 can be modeled by the logistic function as follows:. 𝛼=. 1 1+𝑒 −𝑘(𝑝−𝑃0 ). .. (3). A logistic function is a common sigmoid curve, where k and P0 are the two very important parameters. The numerator is set to the maximum value of 𝛼, which is 1 in this case. The parameter k determines the steepness of the curve and P0 is the x-value of the midpoint in the curve. From the observations with our test network, most shortterm fluctuations correspond to p in the range of [0, 0.02]. We set k = 100 and P0 = 0.02 which provides a specific relationship between 𝑝 and 𝛼 as shown in Figure 9. In this figure, we can see that any changes of segment throughput with p > 0.05 will result in a high value of 𝛼 and p < 0.01 will result in the value of 𝛼 approaching to 0. In Figure 10, we show how this model works in a varying bandwidth environment within 2 minutes. The network setup, bandwidth controlling tool and implementation of adaptation logic will be detailed in Chapter 6. 1. 0.8. 0.6. 𝛼 0.4. 0.2. 0 0. 0.02. 0.04. 0.06. 𝑝 Figure 9: Relationship of p and α.. 18. 0.08. 0.1.

(27) 2500 Ts(i) (kbps) Te(i) (kbps). Bitrate (kbps). 2000. 1500. 1000. 500. 0 0. 20. 40. 60. 80. 100. 120. Time (sec) Figure 10: Throughput estimation using the logistic function.. C. Comparison We implemented two adaptive players (P1 and P2) to compare the differences between choosing real and advertised bitrates. To control this experiment, both players were set to use same parameters in their logistic function (k = 100, P0 = 0.02) and we divided 10-minite playback to five sectors and set specific available bandwidth as shown in Table 3. Table 3: Segment Index, Duration and Avail-BW in each sector.. Segment. Duration (min). Available bandwidth(kbps). Sector 1. 1 – 90. 3. 2000. Sector 2. 91 – 150. 2. 1500. Sector 3. 151 – 240. 3. 1200. Sector 4. 241 – 270. 1. 1500. Sector 5. 271 - 299. 1. 2000. First, we show how two players streaming video in these sectors. P1 always chose segments that the bitrates were closest and under the estimated throughput while P2. 19.

(28) kept choosing the closest advertised bitrates as shown in Figure 11 and 12. We did not use TCP pacing [14] for HAS players to fully utilize the available bandwidth so the average throughput is slightly lower at both clients. As stated before, segments requested by P2 may be much higher or much lower than the throughput so the buffer kept oscillating compared to P1 as shown in Figure 12 and 13. 2500. 12 Instant Throughput Estimated Throughput. 10. Video Bitrate. 8. Buffer Level. 1500 6 1000 4 500. Buffer Level (s). Bitrate (kbps). 2000. 2. 0. 0 0. 100. 200. 300. 400. 500. 600. Time (sec) Figure 11: Real bitrates and buffer state of P1. 2500. 12 Instant Throughput. 10. Estimated Throughput. 2000. 8. Buffer Level. 1500. 6 1000 4 500. 2. 0. 0 0. 100. 200. 300. 400. 500. Time (sec) Figure 12: Advertised bitrates and buffer state of P2.. 20. 600. Buffer Level (s). Bitrate (kbps). Select Rep.

(29) 2500 Instant Throughput Estimated Throughput. Bitrate (kbps). 2000. Select Rep Video Bitrate. 1500 1000 500 0 0. 100. 200. 300. 400. 500. 600. Time (sec) Figure 13: Bitrate of each segment that P2 actually requested.. In addition to three figures above, we also show the ratio of real bitrate to instant throughput and download duration of each segment in Figure 14 and 15. Obviously, P1 stays between 80 – 100% while P2 often exceeds 100% or underutilize its instant throughput. Hence, download durations of P1 are more stable and closer to the segment interval (2 seconds) than P2. 1.6. Ratio (Real bitrate/ Throughput). Player 1 1.4. Player 2. 1.2 1 0.8 0.6 0.4 0.2 0 0. 100. 200. 300. 400. 500. Time (sec) Figure 14: Ratio of download bitrate to instant throughput.. 21. 600.

(30) 4. Download Duration (sec). Player 1 Player 2. 2. 0 0. 100. 200. 300. 400. 500. 600. Time (sec) Figure 15: Download duration of each player.. We summarize the behavior of each player from Table 4 to Table 7. Table 4 indicates that only P1 can choose right segments spreading over seven representations. Table 5 shows the same result as in Figure 11 - 13. Table 6 shows buffer oscillations as stated before. Table 7 shows that although P1 got slightly better bandwidth utilization, the underneath behavior was completely different. Table 4: Number of segments requested by each player in five sectors.. Sector - Player. 400. 800. 1200. 1500. 1800. 2100. 2500. S1 - P1. 0. 2. 5. 29. 30. 15. 9. S1 - P2. 0. 2. 0. 2. 86. 0. 0. S2 - P1. 0. 12. 23. 16. 7. 1. 1. S2 - P2. 0. 0. 58. 1. 1. 0. 0. S3 - P1. 6. 46. 26. 7. 5. 0. 0. S3 - P2. 0. 89. 1. 0. 0. 0. 0. S4 - P1. 0. 4. 21. 4. 0. 1. 0. S4 - P2. 0. 1. 29. 0. 0. 0. 0. S5 - P1. 0. 0. 2. 13. 10. 2. 2. S5 - P2. 0. 0. 1. 2. 26. 0. 0. 22.

(31) Table 5: The percentage of requested bitrates over average throughput in five sectors.. Sector - Player S1 - P1 S1 - P2 S2 - P1 S2 - P2 S3 - P1 S3 - P2 S4 - P1 S4 - P2 S5 - P1 S5 - P2. Average Throughput 1901 1873 1432 1417 1147 1140 1430 1424 1897 1869. Bitrate > Average. Max. Max - Average. 0.00% 38.89% 1.67% 23.33% 2.22% 6.67% 0.00% 6.67% 3.45% 48.28%. 1884 2711 1716 2080 1306 1363 1417 1736 1908 2392. -17.378 837.467 283.333 662.033 158.933 222.978 -13.4 311.167 10.552 522.379. Table 6: Buffer status of each player.. Average Buffer Min Max Max - Min. P1 4.15 3.542 4.967 1.425. P2 3.89 2.352 5.461 3.109. Table 7: Bandwidth utilization of each player in five sectors.. P1 - S1 P1 - S2 P1 - S3 P1 - S4 P1 - S5 Average. Utilization 95.07% 95.51% 95.59% 95.36% 94.87% 95.28%. P2 - S1 P2 - S2 P2 - S3 P2 - S4 P2 - S5 Average. Utilization 93.68% 94.53% 95.00% 94.99% 93.48% 94.34%. Some videos are not encoded specifically for video streaming as our video. Although the client has to choose higher bitrates for certain quality of experience in some video encoding, the impact to buffer can be easily and clearly quantized with this method. This significantly reduces chances of buffer underrun and time to rebuild minimum playback buffer. In this experiment, we prove that streaming with real. 23.

(32) encoding bitrates improves buffer oscillations and still conforms to the spirit of HTTP adaptive streaming – choose segments according to the network throughput.. 24.

(33) 5. Stabilizing Bandwidth under Competition A. Motivation Now the adaptive player can choose segments that are real closest to the estimated throughput but still be unable to stabilize bitrates when two players share the same bottleneck. Figure 15 already shows the download duration of P1 from the previous experiment. This is the case when only one player shared the link while the OFF periods still existed because there were mismatches between video bitrates and network throughput. Therefore, bitrate oscillations still occur even when both players streaming with real bitrates in the competition interval as shown in Figure 16. 2500 Player 1. Player 2. Bitrate (kbps). 2000. 1500. 1000. 500. 0 270. 300. 330. 360. 390. 420. 450. 480. 510. 540. Time (sec) Figure 16: Requested bitrates in the competition interval (300s – 480s).. In the previous works [24, 25, 26], shaping the download traffic to eliminate OFF periods or scheduling the download requests indeed improves stability, fairness and efficiency. However, the shaping rate is still based on the advertised bitrates of streaming video and the players do not know whether the real bitrates exceed the fair share. Besides, shaping traffic of different real bitrates to segment interval makes the. 25.

(34) system more complex and harder to manage on server or gateway. We want to write an algorithm directly in the adaptation logic to determine when the competition starts and ends. This algorithm calculates a ceil rate as the upper bound of requested bitrates when the competition is detected and unset the ceil rate after the competition interval. Based on the last chapter, the requested bitrates will not exceed the ceil rate during the competition because the player already knew the real bitrates of each segment. With this algorithm, the adaptive player can improve fairness and efficiency without any help of network infrastructure. B. Basic Idea The core task of algorithm is to detect if the player is oscillating due to the appearance of bottleneck. In the context of HTTP adaptive streaming, an oscillation occurs when the requested representations upshift and downshift in a relatively short time scale. Our algorithm uses value of 𝛼 from logistic function to identify such pattern as shown in Figure 17. The value of 𝛼 is based on the p value calculated from the last segment (Eq. (1) - (2)). A bigger 𝛼 presents a significant change in the throughput. The 𝛼 will keep a high value over a specific threshold when the oscillation pattern appears. The algorithm keeps detecting 𝛼 values and decides the upper bound based on the requested bitrates in our defined detection window, WD.. 26.

(35) Figure 17: An oscillation pattern in HAS.. C. Algorithm The bottleneck solution is described in Algorithm 1. In Steady-State, the adaptation logic computes 𝛼 based on the previous downloaded segment. We set the size of detection window to three segments and the algorithm changes the competing state to true if the oscillation pattern occurs in line 4. Once the state becomes true, the ceil rate is set to the function of the lowest and the highest throughput in WD as line 9. There is no need to compute this upper bound again so the computed state is set to true. However, we have to lower the ceil rate if it causes network congestion and there are no immediate devices to change requests [31]. The algorithm cuts the ceil rate to 80% when the buffer drains below 2 seconds every time. Although requested bitrates are limited by the ceil rate, the algorithm still computes values of p and 𝛼 for every segment in the background. Therefore, the algorithm uses the same method to judge whether the competition is over and the adaptive player will stream video with Te (i) as usual when it leaves the competing state.. 27.

(36) __________________________________________________________________________ Algorithm 1 Stabilize Requested Bitrates under Competition For every segment i in Steady-State 01: 𝛼 =. 1 1+𝑒 −𝑘(𝑝−𝑃0). 02: Throughput = (1 − 𝛼)𝑇𝑒(𝑖 − 2) + 𝛼𝑇𝑠(𝑖 − 1) 03: 𝑇𝑒(i) = Throughput 04: If (competingState == false && 𝛼 [n – 1] > 0.8 && 𝛼 [n – 2] > 0.8 && 𝛼 [n – 3] > 0.8) 05:. competingState = true. 06: If (competingState == true) 07:. If (computed == false). 08:. N1 = Lowest Ts in WD, N2 = Highest Ts in WD. 09:. Throughput = Ceil Rate = (N1 + N2) / 2. 10:. Computed = true. 11:. Else. 12:. Throughput = Ceil Rate. 13:. If (buffer < 2.0s). 14:. Ceil Rate = 0.8 * Ceil Rate. 15:. Throughput = Ceil Rate. 16:. If (𝛼 [n – 1] < 0.8 && 𝛼 [n – 2] < 0.8 && 𝛼 [n – 3] < 0.8). 17:. competingState = computed = false. 18:. Throughput = Te (i). 19: Select segment based on Throughput 20: Calculate p for next round __________________________________________________________________________. 28.

(37) 6. Performance Evaluation A. Network Setup. Figure 18: Test network for experiments.. As shown in Figure 18, we set up the test network using GNS3 [36], which provides real-time network simulation without the need for network hardware. The C3725 router is connected to two virtual machines, one for server on Linux 14.04 LTS and one for adaptive player on Windows 7. The whole system was setting on a laptop running Mac OS X 10.11 with standard Intel i5 and 8GB RAM. We installed Apache server on the Linux machine and loaded all necessary content generated by FFmpeg and MP4Box as described in Chapter 3. On the client side, we developed a cross-platform implementation in C++ with PugiXML [37], libCurl [38] and Boost library [39]. With these libraries, it made us much easier to parse the MPD file, process HTTP requests, and schedule download events. B. Bandwidth Throttling In all experiments, we used bandwidth shaping to control the network rate between server and router for the end-to-end throughput. The mechanism was based on the Linux traffic control system (tc) and the hierarchical token bucket (htb) which is a classful queuing discipline (qdisc) [40]. We used the following commands to add a qdisc to the root of interface eth0 and configure traffic leaving the interface.. 29.

(38) tc qdisc add dev eth0 root handle 1:0 htb default 90 tc class add dev eth0 parent 1:1 classid 1:90 htb rate rate1 ceil max1 tc class replace dev eth0 parent 1:1 classid 1:90 htb rate rate2 ceil max2 The first two commands create a qdisc to interface eth0 and install a class to specify the outgoing rate to rate1. We set the value of max1 to rate1 because we want the outgoing rate to be constant. The third command changes the outgoing rate to rate2 (which equals to max2) and any desired rates as in Chapter 4. C. Results & Evaluation In this section, we use the following scenario to evaluate our algorithm: One client (P1) starts to play the 10-minute video, “Big Buck Bunny”. After 5 minutes, the second client (P2) starts with the same video and both continue playing for the next 3 minutes (5 – 8 minutes). The second client leaves and the first client continues playing to the end (8 - 10 minutes). We first test both players streaming video only with real bitrates as the base case (Case 1). Next, we test two cases that only one player streaming with algorithm (Case 2) and both players streaming with algorithm (Case 3). We follow two performance metrics defined in [22, 26] to evaluate each experiment: 1. Unfairness: the average of the absolute real bitrate differences between the corresponding segments requested by each player. 2. Inefficiency: The inefficiency at time t is. | ∑𝑥 𝐵𝑥,𝑡 −𝑊| 𝑊. . The bandwidth of the. bottleneck link is W and each player x requests bitrate 𝐵𝑥,𝑡 at time t. A value close to zero implies two players in aggregate use bandwidth as much as possible. The instability metric is not suited here because we use real bitrates instead of advertised bitrates in this paper. For unfairness metric, note that we use real bitrates instead of advertised bitrates as previous works. We set the bandwidth W to 2 Mbps. 30.

(39) and ran each case 5 times to compare the behavior and metrics between two players. Figure 19 shows that Case 3 has the lowest unfairness and inefficiency, which means both players streaming with algorithm brings the best result. As the base case, Case 1 is the worst in three cases. Even two players streaming with real bitrates, the undefined overlays of OFF periods still exist. As shown in Figure 16 and Table 8, the metadata method cannot help to improve stabilizing the players when competing on bottleneck. 0.6 0.5 0.4 Case1 0.3. Case2 Case3. 0.2 0.1 0 Unfairness. Inefficiency. Figure 19: Our algorithm reduces unfairness and inefficiency.. Table 8: Unfairness and Inefficiency of five runs in Case 1.. 1 2 3 4 5. Unfairness (Mbps) 0.39 0.49 0.57 0.62 0.61. Inefficiency 0.203 0.171 0.187 0.169 0.162. In Case 2, the algorithm running in P1 has effectively improved performance problems appeared in Case 1. The algorithm in P1 was activated when it detected the oscillation pattern and calculated a ceil rate for the sequential requests as shown in Figure 20. Even in some experiments the upper bounds were slightly over the fair. 31.

(40) share, the request bitrates still depended on the result of video encoding. Thus, the network did not congest in most situations. We specifically show the behavior of P1 when the ceil rate was set too high in Figure 21. The ceil rate were cut off 20 % as the algorithm detected the buffer had drained below 2 seconds. Table 9 lists the values we used and calculated from the algorithm. Table 10 lists number of segments chosen over and below the fair share. Table 11 lists the result of metrics in each run.. 2500 Player 1. Player 2. P1 Ceil Rate. Bitrate (kbps). 2000. 1500. 1000. 500. 0 270. 300. 330. 360. 390. 420. 450. 480. Time (sec) Figure 20: The algorithm was activated in P1 from 5 – 8 minutes.. 32. 510. 540.

(41) 2500. 20 Player 1. Player 2. P1 Ceil Rate. P1 Buffer. 18. 2000. 16. 1500. 12 10. 1000. 8 6. 500. 4 2. 0. 0 270. 300. 330. 360. 390. 420. 450. 480. 510. 540. Time (sec) Figure 21: The Ceil Rate was cut off from 1308 to 1046 kbps. Table 9: The lowest and highest throughput in WD and Ceil Rate in Case 2.. 1 2 3 4 5. Min 865 936 849 959 865. Max 1036 1302 1047 1205 1751. Ceil Rate 950 1119 948 1082 1308 -> 1046. Table 10: Number of segments over and below fair share in Case 2.. Run - Player R1 – P1 R1 – P2 R2 – P1 R2 – P2 R3 – P1 R3 – P2 R4 – P1 R4 – P2 R5 – P1 R5 – P2. > Fair Share 1.1% (1 / 91) 39.6% (36 / 91) 36.3% (33 / 91) 23.1%(21 / 91) 1.1% (1 / 91) 53.8% (49 / 91) 30.8% (28 / 91) 37.4% (34 / 91) 33.0% (30 / 91) 15.4% (14 / 91). 33. < Fair Share 98.9% (90 / 91) 60.4 %(55 / 91) 63.7% (58 / 91) 76.9% (70 / 91) 98.9% (90 / 91) 46.2 %(42 / 91) 69.2% (63 / 91) 62.6% (57 / 91) 67.0% (61 / 91) 84.6% (77 / 91). Buffer (s). Bitrate (kbps). 14.

(42) Table 11: Unfairness and Inefficiency of five runs in Case 2.. 1 2 3 4 5. Unfairness (Mbps) 0.347 0.271 0.435 0.282 0.317. Inefficiency 0.157 0.170 0.150 0.140 0.190. Case 3 is the best case when both players used the algorithm as shown in Figure 22. Unlike case 2 which P2 kept oscillating in 3-minute interval, both players requested segments closest to the ceil rate to achieve the lowest inefficiency and unfairness. Note that there was no coordination between two players so each player lowered their ceil rate at different time as shown in Figure 23. Table 12-14 are the same as before listing the results in this case.. 2500. 20 Player 1. Player 2. P1 Ceil Rate. P2 Ceil Rate. P1 Buffer. P2 Buffer. 18. 2000. 16. 1500. 12 10. 1000. 8 6. 500. 4 2. 0. 0 270. 300. 330. 360. 390. 420. 450. 480. Time (sec) Figure 22: Both players run the algorithm.. 34. 510. 540. Buffer (s). Bitrate (kbps). 14.

(43) 2500. 20. 2000. Player 1. Player 2. P1 Ceil Rate. P2 Ceil Rate. P1 Buffer. P2 Buffer. 18 16. 1500. 12. 10 1000. 8 6. 500. 4 2. 0. 0 270. 300. 330. 360. 390. 420. 450. 480. 510. 540. Time (sec) Figure 23: Two players cut off their ceil rate at different times.. Table 12: The lowest and highest throughput in WD and Ceil Rate in Case 3.. Run - Player. Min. Max. Ceil Rate. R1 – P1 R1 – P2 R2 – P1. R4 – P2. 873 1014 951 917 964 873 956 857 944 955. 1752 1716 1212 1283 1035 1069 1043 1205 1710 1248. 1312 -> 1049 1365 -> 1092 1081 -> 1081 1100 -> 1100 999 -> 999 971 -> 971 999 -> 999 1031 -> 1031 1327 -> 1061 1101 -> 1101. R5 – P1. 951. 1212. 1081 -> 1081. R5 – P2. 924 890. 1248 1563. 1086 -> 1086 1226 -> 1226. R2 – P2 R3 – P1 R3 – P2 R4 – P1. 35. Buffer (s). Bitrate (kbps). 14.

(44) Table 13: Number of segments over and below fair share in Case 3.. Run - Player R1 – P1 R1 – P2 R2 – P1 R2 – P2 R3 – P1 R3 – P2 R4 – P1 R4 – P2 R5 – P1 R5 – P2. > Fair Share 22.0.% (20 / 91) 18.7% (17 / 91) 30.8% (28 / 91) 3.3% (3 / 91) 2.2% (2 / 91) 0.0% (0 / 91) 27.5% (25 / 91) 18.7% (17 / 91) 30.8% (28 / 91) 41.8% (38 / 91). < Fair Share 78.0% (71 / 91) 81.3% (74 / 91) 69.2% (63 / 91) 96.7% (88 / 91) 97.8% (89 / 91) 100.0% (91 / 91) 72.5% (66 / 91) 70.3% (74 / 91) 69.2% (63 / 91) 58.2% (53 / 91). Table 14: Unfairness and Inefficiency of five runs in Case 3.. 1 2 3 4 5. Unfairness (Mbps). Inefficiency. 0.173 0.169 0.157 0.174 0.195. 0.133 0.136 0.192 0.115 0.087. After testing all three cases, we find two facts appeared in Case 2 and Case 3. In the competition interval, sometimes Ts (i) and Te (i) were very close. This would make our algorithm judge that the competition had disappeared and unset the ceil rate. This misjudge needed about 6 seconds to compensate as WD = 3. Another fact worth discussing is the reaction time when the competition was over. The value of Ts (i) will first stabilize and the estimated throughput Te (i) will approach Ts (i) by the running average in the adaptation logic. In our setting of k = 100 and P0 = 0.02, it often took about 15 – 20 seconds to judge the competition was over. This may have no impact on short videos but may affect clients who still watching long videos [10].. 36.

(45) 7. Related Work The related work covers four main categories: systems of HTTP adaptive streaming, measurements of their performances, rate selection algorithms and solutions to bottleneck competition. Video Streaming Services: HTTP adaptive streaming has become a mainstream in video delivery. In [11], authors investigate the behavior of rate adaptation in three commercial clients including Netflix, Microsoft Smooth Streaming [2] and Adobe OSMF [3]. A new standard in HAS is MPEG-DASH (Dynamic Adaptive Streaming over HTTP) [4, 5], which standards the format of MPD (Media Presentation Description) and video content. With DASH, clients have free space to implement their specific algorithm. In [6], authors evaluate the segment length and persistent connections of web servers with DASH dataset [32]. In [7], authors develop a plugin which can be integrated to VLC for DASH. Video Streaming Measurements: Measurements of HAS and DASH cover a wide range from HTTP traffic, video quality and sharing bottleneck with multiple players. In [8], authors summarize the ON-OFF characteristics of HAS traffic and compare different download strategies by YouTube and Netflix. In [14], authors propose TCP pacing as a solution to fully utilize network bandwidth. Rather than focusing on the network characteristics of video streaming traffic, [9, 10] discuss viewer experience and content characteristics. In [21], authors pinpoint difficulties in HAS from impact of chunk duration, bitrate disparity and transport protocols. Further, authors propose requirement for future media streaming. In [22, 23], authors analyze the performance problems such as instability, unfairness and inefficiency when two players share the same bottleneck. These works have identified ON-OFF cycles as the root cause.. 37.

(46) Rate Selection Algorithms: This category is about optimizing video bitrate selections. In [11, 12], authors propose methods to smooth throughput measurement such as running average. In [15, 18], authors use buffer as feedback and PID controller to smooth rate selection process. In [23], authors show that segment size (real bitrate) being one of factors affects the segment selections. In [16], authors use parallel requesting segments to improve playback quality. In [19], authors optimize video quality by data probe with a measurement proxy architecture. In [20], authors consider video bitrate variability to optimize overall experience. Only a few works consider cases with the bottleneck or the effect of real bitrates. In [17], authors additionally evaluate their algorithm in the scenario where two players share a common link. However, the selected bitrates are still based on the advertised bitrates and buffer levels are not as stable as our results. In [28], authors propose a video control plane which can use a global view of network and clients to dynamically optimize video delivery. A similar method in [31] is to rewrite requests on the proxy server and forward to the DASH server. Solutions to bottleneck competition: In [24], the gateway calculates downloading rate for each client. In [25], the server is in charge of detecting oscillations and limits number of video profiles to be fetched. These methods try to eliminate OFF periods but we prove that it is impractical in Chapter 3. In [26], authors develop an algorithm to request chunks with randomized scheduling. In [27], authors propose a framework to manage resources across adaptive video flows on a base station in cellular networks.. 38.

(47) 8. Conclusions & Future Work In this paper, we first focus on how to optimize segment selections in HTTP adaptive streaming. In HAS and DASH, bitrate disparity between advertised bitrates and real bitrates violates the spirit of HAS that segments are selected based on estimated throughput and corresponding advertised bitrates. Streaming content of inconsistent quality causes buffer oscillations and also brings down reliability of buffer-based algorithms. Therefore, we provide accurate bitrate information of each segment by Subset elements in MPD to make user select correct segments across different encoding representations. As a consequence, the client rarely selects segments that make the network unsustainable when throughput estimation model works well. Even the client has to choose higher bitrates for certain quality of experience in some video encoding, the impact to buffer can be easily and clearly quantized with this method. On the other hand, the bandwidth competition on network bottleneck in HAS has been deeply investigated and many solutions have been proposed as well. In this paper, we propose an algorithm to detect oscillations in a detection window. The algorithm sets a ceil rate for the sequential requests and cut the ceil rate off when buffer has drained below a certain threshold. With real bitrate information in the first part, we can assure that clients will not request segments over the ceil rate. Our evaluation shows the minimum unfairness and inefficiency appear when both players run the algorithm. In future work, we have to collect different types of bandwidth fluctuations and oscillation patterns based on connected networks and client locations. These will mature our algorithm to automatically adapt parameters in throughput estimation model and thresholds of test condition in the detection window.. 39.

(48) References [1] Sandvine Report. https://www.sandvine.com/trends/global-internet-phenomena/ [2] Microsoft Smooth Streaming. https://www.microsoft.com/silverlight/smoothstreaming/ [3] Adobe OSMF. http://www.osmf.org/ [4] ISO/IEC IS 23009-1:2012, Information technology - Dynamic adaptive streaming over HTTP (DASH) - Part 1: Media presentation description and segment formats. [5] Stoekhammer, T. "Dynamic adaptive streaming over HTTP-design principles and standards." Proceedings of the Second Annual ACM Conference on Multimedia Systems. Vol. 2014. New York, USA: ACM, 2011. [6] Lederer, Stefan, Christopher Müller, and Christian Timmerer. "Dynamic adaptive streaming over HTTP dataset." Proceedings of the 3rd Multimedia Systems Conference. ACM, 2012. [7] Müller, Christopher, and Christian Timmerer. "A VLC media player plugin enabling dynamic adaptive streaming over HTTP." Proceedings of the 19th ACM international conference on Multimedia. ACM, 2011. [8] Rao, Ashwin, et al. "Network characteristics of video streaming traffic." Proceedings of the Seventh COnference on emerging Networking EXperiments and Technologies. ACM, 2011. [9] Krishnan, S. Shunmuga, and Ramesh K. Sitaraman. "Video stream quality impacts viewer behavior: inferring causality using quasi-experimental designs." Networking, IEEE/ACM Transactions on 21.6 (2013): 2001-2014. [10] Gill, Phillipa, et al. "YouTube traffic characterization: a view from the edge." Proceedings of the 7th ACM SIGCOMM conference on Internet measurement. ACM, 2007. [11] Akhshabi, Saamer, Ali C. Begen, and Constantine Dovrolis. "An experimental evaluation of rate-adaptation algorithms in adaptive streaming over HTTP." Proceedings of the second annual ACM conference on Multimedia systems. ACM, 2011. [12] Liu, Chenghao, Imed Bouazizi, and Moncef Gabbouj. "Rate adaptation for adaptive HTTP streaming." Proceedings of the second annual ACM conference on Multimedia systems. ACM, 2011. [13] Popa, Lucian, Ali Ghodsi, and Ion Stoica. "HTTP as the narrow waist of the future Internet." Proceedings of the 9th ACM SIGCOMM Workshop on Hot Topics in Networks. ACM, 2010. [14] Esteban, Jairo, et al. "Interactions between HTTP adaptive streaming and TCP." Proceedings of the 22nd international workshop on Network and Operating System Support for Digital Audio and Video. ACM, 2012.. 40.

(49) [15] Tian, Guibin, and Yong Liu. "Towards agile and smooth video adaptation in dynamic HTTP streaming." Proceedings of the 8th international conference on Emerging networking experiments and technologies. ACM, 2012. [16] Liu, Chenghao, Imed Bouazizi, and Moncef Gabbouj. "Parallel adaptive HTTP media streaming." Computer Communications and Networks (ICCCN), 2011 Proceedings of 20th International Conference on. IEEE, 2011. [17] Miller, Konstantin, et al. "Adaptation algorithm for adaptive streaming over HTTP." Packet Video Workshop (PV), 2012 19th International. IEEE, 2012. [18] Huang, Te-Yuan, Ramesh Johari, and Nick McKeown. "Downton abbey without the hiccups: Buffer-based rate adaptation for http video streaming." Proceedings of the 2013 ACM SIGCOMM workshop on Future human-centric multimedia networking. ACM, 2013. [19] Mok, Ricky KP, et al. "QDASH: a QoE-aware DASH system." Proceedings of the 3rd Multimedia Systems Conference. ACM, 2012. [20] Li, Zhi, et al. "Streaming video over HTTP with consistent quality." Proceedings of the 5th ACM Multimedia Systems Conference. ACM, 2014. [21] Bae, Sangwook, Dahyun Jang, and KyoungSoo Park. "Why Is HTTP Adaptive Streaming So Hard?." Proceedings of the 6th Asia-Pacific Workshop on Systems. ACM, 2015. [22] Akhshabi, Saamer, et al. "What happens when HTTP adaptive streaming players compete for bandwidth?." Proceedings of the 22nd international workshop on Network and Operating System Support for Digital Audio and Video. ACM, 2012. [23] Huang, Te-Yuan, et al. "Confused, timid, and unstable: picking a video streaming rate is hard." Proceedings of the 2012 ACM conference on Internet measurement conference. ACM, 2012. [24] Houdaille, Rémi, and Stéphane Gouache. "Shaping http adaptive streams for a better user experience." Proceedings of the 3rd Multimedia Systems Conference. ACM, 2012. [25] Akhshabi, Saamer, et al. "Server-based traffic shaping for stabilizing oscillating adaptive streaming players." Proceeding of the 23rd ACM Workshop on Network and Operating Systems Support for Digital Audio and Video. ACM, 2013. [26] Jiang, Junchen, Vyas Sekar, and Hui Zhang. "Improving fairness, efficiency, and stability in http-based adaptive video streaming with festive." Proceedings of the 8th international conference on Emerging networking experiments and technologies. ACM, 2012. [27] Chen, Jiasi, et al. "A scheduling framework for adaptive video delivery over cellular networks." Proceedings of the 19th annual international conference on Mobile computing & networking. ACM, 2013. [28] Liu, Xi, et al. "A case for a coordinated internet video control plane." Proceedings of the ACM SIGCOMM 2012 conference on Applications, technologies, architectures, and protocols for computer communication. ACM, 2012.. 41.

(50) [29] Thang, Truong Cong, et al. "Adaptive streaming of audiovisual content using MPEG DASH." Consumer Electronics, IEEE Transactions on 58.1 (2012): 78-85. [30] Thang, Truong Cong, Jung Won Kang, and Yong Man Ro. "Graph-based perceptual quality model for audiovisual contents." Multimedia and Expo, 2007 IEEE International Conference on. IEEE, 2007. [31] El Essaili, Ali, et al. "Quality-of-experience driven adaptive HTTP media delivery.” Communications (ICC), 2013 IEEE International Conference on. IEEE, 2013. [32] DASH video dataset. http://www-itec.uni-klu.ac.at/dash/?page_id=207 [33] Xiph. Xiph organization video data-base. Website, 2014. https://media.xiph.org/video/derf/ [34] FFmpeg. https://www.ffmpeg.org [35] Le Feuvre, Jean, et al. "Experimenting with multimedia advances using GPAC." Proceedings of the 19th ACM international conference on Multimedia. ACM, 2011. [36] GNS3. https://www.gns3.com [37] PugiXML. http://pugixml.org [38] libCurl. http://curl.haxx.se/libcurl/ [39] Boost library. http://www.boost.org [40] Hubert B. 2002. Linux Advanced Routing &Traffic Control HOWTO. http://lartc.org/howto/index.html. 42.

(51)