Saamer Akhshabi, Constantine Dovrolis Georgia Institute of Technology An Experimental Evaluation of...

44
Saamer Akhshabi, Constantine Dovrolis Georgia Institute of Technology An Experimental Evaluation of Rate Adaptation Algorithms in Adaptive Video Streaming over HTTP Ali C. Begen Cisco Systems February 3, 2011

Transcript of Saamer Akhshabi, Constantine Dovrolis Georgia Institute of Technology An Experimental Evaluation of...

Saamer Akhshabi, Constantine DovrolisGeorgia Institute of Technology

An Experimental Evaluation of Rate Adaptation Algorithms in

Adaptive Video Streaming over HTTP

Ali C. BegenCisco Systems

February 3, 2011

OutlineOverview of adaptive video streamingExperimental methodologyRate adaptation under available bw

variationsSmooth Streaming playerNetflix playerOSMF player

Live streamingCompetition between multiple playersConclusions

OutlineOverview of adaptive video streamingExperimental methodologyRate adaptation under available bw

variationsSmooth Streaming playerNetflix playerOSMF player

Live streamingCompetition between multiple playersConclusions

Other Video Streaming Approaches

HTTP Progressive Download

RTSP and RTP

Other Video Streaming Approaches

RTMP

Other Video Streaming Approaches

Several players support itSeveral commercial content providers use it

Microsoft Smooth Streaming PlayerNetflix PlayerAdobe OSMF/Zeri PlayerApple Player

Adaptive video streaming over HTTP

HTTP Adaptive Video Streaming

HTTP Adaptive Video Streaming:

Manifest File and Fragments

HTTP Adaptive Video Streaming:

HTTP Request and Response

OutlineOverview of adaptive video streamingExperimental methodologyRate adaptation under available bw

variationsSmooth Streaming playerNetflix playerOSMF player

Live streamingCompetition between multiple playersConclusions

ObjectivesExamine how commercial adaptive players

react to available bw variationsPersistent variationsShort-term variations (spikes)

We control the available bw using DummynetIn parallel, we collect packet traces at the

playerIdentify requested bitrates & measure throughput

Also, we estimate playback buffer size (in seconds)Use fragment timestamps (explained later)

Experimental Methodology

OutlineOverview of adaptive video streamingExperimental methodologyRate adaptation under available bw

variationsSmooth Streaming playerNetflix playerOSMF player

Live streamingCompetition between multiple playersConclusions

Smooth Streaming Player

Smooth Streaming PlayerSample HTTP Request:

GET /mediadl/iisnet/smoothmedia/Experience/BigBuckBunny720p.ism/QualityLevels(2040000)/Fragments(video=400000000) HTTP/1.1

Smooth Streaming PlayerBuffering and Steady State

• One fragment per HTTP request

• No HTTP pipelining •Two states:1.Buffering state

• Request fragments as fast as possible

2.Steady-state• Request new fragment

every T seconds

Smooth Streaming PlayerBehavior under Unrestricted Available

Bandwidth

Average throughput: running average of instantaneous 2-sec TCP throughput measurements.

Fragment throughput: per-fragment throughput measurement

Smooth Streaming PlayerBehavior under Unrestricted Available

Bandwidth

Two successive, say video, requests sent at times t1 and t2 (t1<t2) with timestamps t‘

1 and t‘2 (t‘

1 < t‘2) respectively

The playback buffer duration (in seconds) for video at time t2 is estimated as:

B(t2) = B(t1) - (t2-t1) + (t‘2 - t‘

1)

Smooth Streaming PlayerNotice: Important variation in fragment sizes

The video fragment size varies considerably (VBR encoding) The rate can vary widely around the nominal bitrate (2.75 Mbps)

This can be a significant problem for adaptive video streaming!

Smooth Streaming PlayerBehavior under persistent changes in

available bandwidth

Rate adaptation occurs after long delays The player estimates available bw using a running

average of the per-fragment TCP throughput measurements

Smooth Streaming PlayerPlayback buffer size under persistent changes

in the available bandwidth

Playback buffer size decreases when available bandwidth is less than the requested bitrate

Playback buffer size increases when player goes into “buffering state” requesting fragments as fast as possible

Together with switching to bitrate < available bw

The client reacts to some of the spikes by switching to lower bitrate too late

Stays at that bitrate for long after the spike has passed

Smooth Streaming PlayerBehavior under short term available bandwidth

variations (negative spikes)

OutlineOverview of adaptive video streamingExperimental methodologyRate adaptation under available bw

variationsSmooth Streaming playerNetflix playerOSMF player

Live streamingCompetition between multiple playersConclusions

Netflix Player

Netflix PlayerSample HTTP Request:

GET /sa2/946/1876632946.wmv/range/2212059-2252058?token=1283923056\_d6f6112068075f1fb60cc48eab59ea55\&random=1799513140 HTTP/1.1

NetflixPlayerBehavior under Unrestriced Available

Bandwidth

Player accumulates 5-min playback buffer!

Netflix PlayerBehavior under persistent changes in

the available bandwidth

Initially, the player requests fragments at all possible bitrates

Occasionally, the player requests higher bitrate than available bw!

Utilize large playback buffer size to optimize video quality

Smooth Streaming PlayerBehavior under short term available bandwidth

variation with positive spikes

Netflix appears to be more aggressive than Smooth Streaming in requesting higher bitrates

OutlineOverview of adaptive video streamingExperimental methodologyRate adaptation under available bw

variationsSmooth Streaming playerNetflix playerOSMF player

Live streamingCompetition between multiple playersConclusions

Adobe OSMF/Zeri Player

Adobe OSMF PlayerSample HTTP Request:

GET /content/inoutedit-mbr/inoutedit\_h264\_3000Seg1-Frag5 HTTP/1.1

OSMF PlayerBehavior under persistent changes in

the available bandwidth

The client fails to select highest possible bitrate for the given available bw

OSMF PlayerBehavior under persistent changes in

the available bandwidth

Also, player often oscillates between bitrates Mostly lowest and highest bitrates

OutlineOverview of adaptive video streamingExperimental methodologyRate adaptation under available bw

variationsSmooth Streaming playerNetflix playerOSMF player

Live streamingCompetition between multiple playersConclusions

Smooth Live Streaming

No major differences with on-demand streaming Player starts streaming with 8-seconds delay

CableTV networks often use 7-second “profanity delay”

Smooth Live StreamingBuffer Fill Level

Playback delay increases over time whenever playback buffer gets empty

Player does not skip fragments

OutlineOverview of adaptive video streamingExperimental methodologyRate adaptation under available bw

variationsSmooth Streaming playerNetflix playerOSMF player

Live streamingCompetition between multiple playersConclusions

Two Smooth Streaming players compete

Players keep oscillating between rates even when available bw is constant

Synchronization can cause simultaneous bitrate drops

Two Smooth Streaming players compete

Fairness issue: one stream may get much lower bitrate than the other

OutlineOverview of adaptive video streamingExperimental methodologyRate adaptation under available bw

variationsSmooth Streaming playerNetflix playerOSMF player

Live streamingCompetition between multiple playersConclusions and future work

Summary of the key differences between players

Smooth Streaming playerPlayback buffer size of 10s of secondsConservative in selecting bitrate (< available

bw)Netflix player

Playback buffer size of few minutesMore aggressive than Smooth player (often >

available bw)Zeri player

Erratic bitrate selectionUnder Development (?)

Weaknesses in adaptation logic

Smooth Streaming playerLarge delay in responding to persistent available

bw variationsErratic rate adaptations under short-term

variationsOscillations and unfairness when multiple players

competeNetflix player

Large delay in responding to persistent available bw variations

Erratic rate adaptations under short-term variations

Requires large playback bufferZeri player

Adaptation logic seems broken

Future WorkContinue the analysis of commercial

players to understand how they workAnd identify weaknesses

Expand study of multi-player competition Design and implement an adaptive

steaming adaptation logic that can address all previous issues