Today, the technology for video streaming over the Internet is converging towards a paradigm named HTTP-based adaptive streaming (HAS), which brings two new features. First, by using HTTP TCP, it leverages network-friendly TCP to achieve both firewall NAT traversal and bandwidth sharing. Second, by pre-encoding and storing the video in a number of discrete rate levels, it introduces video bitrate adaptivity in a scalable way so that the video encoding is excluded from the closed-loop adaptation. A conventional wisdom in HAS design is that since the TCP throughput observed by a client would indicate the available network bandwidth, it could be used as a reliable reference for video bitrate selection. We argue that this is no longer true when HAS becomes a substantial fraction of the total network traffic. We show that when multiple HAS clients compete at a network bottleneck, the discrete nature of the video bitrates results in difficulty for a client to correctly perceive its fair-share bandwidth. Through analysis and test bed experiments, we demonstrate that this fundamental limitation leads to video bitrate oscillation and other undesirable behaviors that negatively impact the video viewing experience. We therefore argue that it is necessary to design at the application layer using a "probe and adapt" principle for video bitrate adaptation (where "probe" refers to trial increment of the data rate, instead of sending auxiliary piggybacking traffic), which is akin, but also orthogonal to the transport-layer TCP congestion control. We present PANDA - a client-side rate adaptation algorithm for HAS - as a practical embodiment of this principle. Our test bed results show that compared to conventional algorithms, PANDA is able to reduce the instability of video bitrate selection by over 75 without increasing the risk of buffer underrun.
@cite_16: With an increasing demand for high-quality video content over the Internet, it is becoming more likely that two or more adaptive streaming players share the same network bottleneck and compete for available bandwidth. This competition can lead to three performance problems: player instability, unfairness between players, and bandwidth underutilization. However, the dynamics of such competition and the root cause for the previous three problems are not yet well understood. In this paper, we focus on the problem of competing video players and describe how the typical behavior of an adaptive streaming player in its Steady-State, which includes periods of activity followed by periods of inactivity (ON-OFF periods), is the main root cause behind the problems listed above. We use two adaptive players to experimentally showcase these issues. Then, focusing on the issue of player instability, we test how several factors (the ON-OFF durations, the available bandwidth and its relation to available bitrates, and the number of competing players) affect stability.
@cite_4: Today's commercial video streaming services use dynamic rate selection to provide a high-quality user experience. Most services host content on standard HTTP servers in CDNs, so rate selection must occur at the client. We measure three popular video streaming services -- Hulu, Netflix, and Vudu -- and find that accurate client-side bandwidth estimation above the HTTP layer is hard. As a result, rate selection based on inaccurate estimates can trigger a feedback loop, leading to undesirably variable and low-quality video. We call this phenomenon the "downward spiral effect", and we measure it on all three services, present insights into its root causes, and validate initial solutions to prevent it.
@cite_11: Adaptive (video) streaming over HTTP is gradually being adopted by content and network service providers, as it offers significant advantages in terms of both user-perceived quality and resource utilization. In this paper, we first focus on the rate-adaptation mechanisms of adaptive streaming and experimentally evaluate two major commercial players (Smooth Streaming and Netflix) and one open-source player (Adobe's OSMF). We first examine how the previous three players react to persistent and short-term changes in the underlying network available bandwidth. Do they quickly converge to the maximum sustainable bitrate? We identify major differences between the three players and significant inefficiencies in each of them. We then propose a new adaptation algorithm, referred to as AdapTech Streaming, which aims to address the problems with the previous three players. In the second part of the paper, we consider the following two questions. First, what happens when two adaptive video players compete for available bandwidth in the bottleneck link? Can they share that resource in a stable and fair manner? And second, how does adaptive streaming perform with live content? Is the player able to sustain a short playback delay, keeping the viewing experience ''live''?
: Various research efforts have focused on understanding the behavior of several commercially deployed HAS systems. One such example is @cite_11 , where the authors characterize and evaluate HTTP streaming players such as Microsoft Smooth Streaming, Netflix, and Adobe OSMF via experiments in controlled settings. The first measurement study to consider HAS streaming in the multi-client scenarios is @cite_16 . The authors identify the root cause of the player's rate oscillation problem as the existence of on-off patterns in HAS traffic. In @cite_4 , the authors measure behavior of commercial video streaming services, i.e., Hulu, Netflix, and Vudu, when competing with other long-lived TCP flows. The results revealed that inaccurate estimations can trigger a feedback loop leading to undesirably low-quality video.