An Adaptive Video Streaming Control System: Modeling, Validation, and Performance Evaluation PRESENTED BY : XI TAO AND PRATEEK GOYAL DEC

Introduction Video traffic accounts for more than 90% of the global internet traffic, acc. to a Cisco report. Such a growth is fed by websites such as Netflix and YouTube. The increase in the number of smartphones and tablets further feeds the growth. The challenging task is to provide the user with a seamless multimedia experience at maximum QoS. To this purpose, multimedia content needs to be adaptive to match a wide set of variables such as screen resolution, CPU load, available bandwidth etc. With progressive streaming, the video is encoded at a constant bit rate and delivered by HTTP. The received video is temporarily stored in the buffer before playing, to mitigate the mismatch between video bit rate and available bandwidth. In adaptive streaming, the video bit rate is throttled on the fly in order to match the available bandwidth and get the best video quality while minimizing latency.

Related Work Several transport protocols for video streaming have been proposed, such as TCP friendly rate protocol, Real Time transport protocol, Microsoft Media Service and Real Time Messaging protocol. TCP (supported by HTTP) is getting wider acceptance than before because: HTTP based streaming is cheaper to deploy TCP has build in NAT capabilities TCP is easily deployed within CDN TCP guarantees network stability Video Adaptation techniques can be grouped into three categories: Transcoding based Scalable encoding based Stream switching (or Multiple bit rate) based

Transcoding based approach adapts the video content to match a specific bit rate by means of on-the-fly transcoding of the raw content. These algorithms can achieve very fine granularity by throttling frame rate, compression and video resolution. However, this comes at the cost of increased processing load and poor scalability. This is because transcoding is done on a per-client basis. Some adaptation algorithms employ scalable codecs such as H264/MPEG4. Both spatial and temporal scalability can be exploited to adapt picture resolution and frame rate without re-encoding the raw content. It reduces processing costs because the raw video is encoded once and adapted on-the-fly by using the scalability features of the codecs. However, it is difficult to use with CDNs since the adaptation logic requires specific servers and standard proxy caching is not possible. Further, there is a limited set of codecs. Stream switching or MBR streaming, encodes the raw video content at increasing bit rates resulting in “N” versions of the video that form a discrete set of video levels. The algorithm automatically selects a level which matches the user’s bandwidth. They minimize the processing cost by encoding the raw video once. Also, it does not rely on a particular codec. However, it comes with increased storage requirements and coarser granularity. Services using stream switching include Microsoft IIS smooth streaming, Apple HTTP adaptive live streaming, Move networks, Netflix, etc.

Automatic Stream Switching Controller Overall control and communication architecture of the video level switching system.

Overall Control Architecture The primary goal of the system is to dynamically select the video level, in order to match the available bandwidth b(t). System controllers are driven by the available bandwidth estimate b’(t) and the buffer duration q(t). Client and server communicate through HTTP protocol. Each session has two sockets: The control socket CS (to send commands to server via HTTP) and data socket DS (to the video stream to the client). Client is made up of player buffer (to store the video frames and feed the player), buffer controller (to compute control variable T(t) that is sent to buffer controller actuator at the server), stream switching controller (computes control variable c(t) that is sent to stream switching actuator in the server) and measurement module (supplies an array F(t) to the controllers). Server has a stream switching actuator (selects the appropriate video level based on c(t)) and buffer controller actuator (throttles the video streamer rate based on T(t)).

Playout buffer level controller and Bandwidth Estimator Aim of the playout buffer level controller is to drive the player buffer length q(t) to a target length q T (t) in order to guarantee continuous reproduction of the video. Block diagram is shown:

Output of the controller block f(.) is throttle percentage T(t). It aims to change the difference between target buffer length and buffer length to 0. The controller has 3 phases: rebuffering, bandwidth probing and normal. Rebuffering is triggered when the player buffer gets empty and lasts until a sufficient amount of video is stored in the playout buffer. During this, the throttle percentage is set at 200. During bandwidth probing, T(t) is set to 500 and the client triggers a bandwidth probing phase. During this short interval, the received video rate reaches a peak that is close to available bandwidth. At the end of this phase, the server sends a round trip time estimate R(t). A safety factor is computed based on this R(t) using the following equations: During the Normal phase, T(t) is set as follows:

Client sends the T(t) to the server. The server produces a video rate r’(t) that fills the sender buffer according the following equation: When the throttle percentage is above 100%, the server streams the video at a rate that is greater than the current video level bit rate, and the player buffer is filled. When the buffer length matches the target buffer length, T(t) is equal to 100%.

Automatic stream switching controller It aims at selecting the video level to be sent by the server to the client, so that best quality is preserved and rebuffering is avoided. The controller is event based, i.e. its decision are triggered when particular events occur. For each level, a high and low threshold is maintained. In order to switch up the level, the estimated bandwidth must cross the high threshold. This causes network underutilization and reduces QoS. In order to select a level, the estimated bandwidth must be at least (1.2 x current level). Figure shows a finite state machine modeling the algorithm: Current level is maintained until the transitions occur.

HTTP protocol and video level parameters

Table of commands

Controlled Testbed

Efficiency Indices

Model Validation

Conclusions 1. modeled and validated the automatic stream-switching controller A) one controls the length of the client buffer B) the second one selects the video level 2. an extensive performance evaluation in a controlled environment A) a video flow takes 21 s on average to switch up between two adjacent video levels in response to a bandwidth increase B) due to the conservativeness of the stream-switching algorithm, a low bandwidth utilization may be obtained C) when the available bandwidth suddenly decreases, interruptions of the video playback may occur due to a large actuation delay

Thank You Questions?