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
2
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
3
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 ON-OFF 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
4
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.
5