2. Dynamic Adaptive
Streaming over HTTP (DASH)
Christian Timmerer and Christopher Müller
Alpen-Adria Universität Klagenfurt (AAU) Faculty of Technical Sciences (TEWI)
Institute of Information Technology (ITEC) Multimedia Communication (MMC)
http://research.timmerer.com http://blog.timmerer.com mailto:christian.timmerer@itec.uni-klu.ac.at
02 May 2011
Acknowledgment: Thomas Stockhammer (QUALCOMM), Mark Watson (Netflix) – reused their presentations
from MMSys’11 accessible via http://www.mmsys.org/
7. Dynamic Adaptive Streaming over HTTP (DASH)
2010/05/02
Christian Timmerer, Alpen-Adria-Universität
Klagenfurt, Austria
7
http://multimediacommunication.blogspot.com/2010/05/http-streaming-of-mpeg-media.html
Proprietary Solutions
3GPP Rel.9 Adaptive
HTTP Streaming
Int’l Standard Solutions V1 Int’l Standard Solutions V2
Apple HTTP Live
Streaming
Adobe HTTP
Dynamic Streaming
Microsoft Smooth
Streaming
Netflix Akamai
Movenetworks’
Movestreaming
Amazon . . .
OIPF HTTP Adaptive
Streaming
MPEG DASH
3GPP Rel.10 DASH
time
8. Outline
• Introduction
– DASH Design Principles
– Scope: What is specified – and what is not!
• DASH Data Model
– Media Presentation Description
– Segment Indexing
• Dynamic & Adaptive
– Video on Demand vs. Live
– The Adaptation Problem
• Conclusions & Future Work
2010/05/02
Christian Timmerer, Alpen-Adria-Universität
Klagenfurt, Austria
8
13. DASH Groups & Subsets
Group by codec, language, resolution, bandwidth,
views, etc. – very flexible (in combination with xlink)!
Ranges for the @bandwidth, @width, @height and
@frameRate
2010/05/02
Christian Timmerer, Alpen-Adria-Universität
Klagenfurt, Austria
13
Group id="grp-1"
Representation id="rep-1"
. . .
Representation id="rep-2"
Representation id="rep-n"
Group id="grp-2"
Representation id="rep-1"
. . .
Representation id="rep-2"
Representation id="rep-n"
. . .
Group id="grp-m"
Representation id="rep-1"
Representation id="rep-2"
Subset id="ss-1"
Contains group="grp-1"
Contains group="grp-4"
Contains group="grp-7"
Subsets
Mechanism to restrict the combination of
active Groups
Expresses the intention of the creator of the
Media Presentation
19. Potential Future Work Items
• MMSys’11 Keynote
– HTTP Adaptive Streaming in Practice by Mark Watson (Netflix)
– Future work
• Good models for future bandwidth
• Tractable representations of future choices - how to efficiently search
the 'choice space’
• What are the quality goals?
• Call for adaptation logics
– Efficient implementations of the actual adaptation logic which is
responsible for the dynamic and adaptive part of DASH
• Get it deployed and adopted (e.g. W3C, DVB – what is
necessary?)
• Join this activity, everyone is invited – get involved in and
exited about DASH!
2010/05/02
Christian Timmerer, Alpen-Adria-Universität
Klagenfurt, Austria
20
http://multimediacommunication.blogspot.com/2011/02/beta-version-of-vlc-dash-plugin.html
20. Implementations
• Reference Software
– Open Source, ISO Copyright
– Currently not publicly available
• GPAC Implementation
– GNU Lesser General Public License
– http://gpac.wp.institut-telecom.fr/
• VLC Plugin
– GNU Lesser General Public License
– http://www-itec.uni-klu.ac.at/dash/
2010/05/02
Christian Timmerer, Alpen-Adria-Universität
Klagenfurt, Austria
21
23. Dynamic Adaptive Video Streaming over
HTTP (DASH)
Abdelhak Bentaleb
bentaleb@comp.nus.edu.sg
Supervisor
Prof. Roger Zimmermann
National University of Singapore
School of Computing
24. 25
Introduction
Real-time Entertainment
Streaming video and audio,
More than 65% of Internet traffic at
peak periods
Popular Services
YouTube (16.9%), Netflix (34.9%),
Amazon Video (2.95%), Hulu (2.5%)
All delivered over the top (OTT)
Network operators are looking for novel
ways to optimally utilize the resources
What happens when multiple client
compete with each other?
Source: Global Internet Phenomena Report (DEC 2015) Sandvine
Source: Trends and Analysis Report (May 2015) CISCO
25. 26
Push and Pull-Based video delivery source
Push-Based
Delivery
Pull-Based
Delivery
Source (Server)
Broadcasters/serv
ers like: Windows
Media, Apple
QuickTime,
RealNetworks
Helix, Cisco
VDS/DCM
Web/FTP servers
such as:
LAMP, Microsoft
IIS,
Adobe Flash,
RealNetworks
Helix, Cisco VDS
Protocols RTSP, RTP, UDP
HTTP, RTMPx,
FTP
Video Monitoring
and User
Tracking
RTCP for RTP
transport
(Currently)
Proprietry
Multicast Support Yes No
Caching Support No Yes for HTTP
Traditional Video Streaming: Push-
based
Initiate, manage and control a video
streaming session between the client
and server
Adaptive HTTP Video Streaming
(HAS): Pull-based
Uses HTTP and TCP to fetch data
26. 27
What is Streaming?
Definition
Streaming is transmission of a continuous
content from a server to a client.
Simultaneous consumption by the client.
Two Main Characteristics
Client consumption rate may be limited by
real-time constraints as opposed to just
bandwidth availability.
Server transmission rate (loosely or tightly)
matches to client consumption rate.
27. 28
HAS Video Delivery Benefits
Dynamic Adaptation to the network condition.
Reuse of existing Internet infrastructure.
Adaptation logic located at the client side.
HTTP protocol: simplifies getting through NATs and firewalls.
28. 30
HTTP Dynamic Adaptive video Streaming
(DASH)
Request the MPD
Download segments using HTTP GET
select bitrate based on TCP bandwidth
estimation
Adapt to network resources dynamically
Fragment the video into small fixed duration (2 to
10s) segments
Encode and store segments at different bitrate
and resolution levels
List the encoded segments in a Media
Presentation Description (MPD)
Send segments using HTTP POST
29. 31
HTTP Dynamic Adaptive video Streaming
(DASH)
Adaptation to dynamic network conditions
Adapts to dynamic conditions anywhere on the path
through the Internet and/or home network.
Decrease continual connections between S and C’s while increase scalability
of clients.
Improved end-user Quality of Experience (QoE)
Enables faster start-up and seeking.
Reduces freezes.
Use of HTTP/TCP
Provides easy traversal for all kinds of middleboxes.
Enables cloud access, leverages existing HTTP
caching infrastructure (Cheaper CDN costs).
31. 33
Client-side Bitrate (BR) Adaptation
The bitrate adaptation logic is fully controlled by the client
(purely client-driven).
Bitrate adaptation heuristics based on:
1. Available bandwidth
2. Playback buffer size
3. Chunk scheduling
4. Hybrid-based
Interesting algorithms
Li et al (2014), Liu et al (2011)
Huang et al (2014), Mueller et al (2015)
Jiang et al (2012), Chen et al (2013)
Yin et al (2015), Li et al. (2014), De Cicco et al. (2013), Miller et al. (2012),
Zhou et al. (2012)
32. 34
Adaptation Comparison (1)
• “A Comparison of Quality Scheduling in Commercial Adaptive HTTP Streaming
Solutions on a 3G Network”
Haakon Riiser, Håkon S. Bergsaker, Paul Vigmostad, Pål Halvorsen, Carsten Griwodz,
ACM MoVid '12, proceedings of the 4th Workshop on Mobile Video, pp. 25-30.
• This paper compares four commuter scenarios:
34. 36
1. Available Bandwidth BR Adaptation
Uses the available bandwidth estimation as an heuristic in the
bitrate adaptation logic algorithm.
Interesting algorithms:
Li et al. (2014), Liu et al. (2011)
Challenges and drawbacks:
Blind available bandwidth sharing between competing clients
Each client strives to fetch the high chunk bitrate => unfairness, congestion
Distribute the available bandwidth equally between clients
Heterogeneous devices with various capabilities case?
The bandwidth estimation is not accurate DASH scalability issues
Lack of a central manager
May suffer from buffer starvation and undesirable QoE
Worst decisions when number of clients increase
35. 37
2. Buffer Level Size BR Adaptation
Uses the current buffer level size as an criterion in the bitrate
adaptation logic algorithm.
Interesting algorithms:
Huang et al. (2014), Mueller et al. (2015)
Challenges and drawbacks:
Suffer from frequent bitrate switch with a low perpetual quality
Low end-user QoE
Can not deal with rapid and/or sudden bandwidth variations
Very slow detection very slow detection, eliminate the available bandwidth
estimation
Can not support many clients
36. 38
3. Chunk Scheduling BR Adaptation
Divides the bitrate adaptation algorithm into many components
and uses scheduling approach to select a suitable bitrate level.
Interesting algorithms:
Jiang et al. (2012), Chen et al. (2013)
Challenges and drawbacks:
Is exposed to instability issue when the number of players increases
Inaccurate bandwidth estimation
Ignored responsiveness to bandwidth fluctuations
Buffer undershoot issue and stalls
Achieves unpleasant end-user QoE
Hard to implement in a real word without any central control manager that
schedules bitrate decisions for each client
37. 39
4. Hybrid BR Adaptation
The client makes its bitrate selection based on combination
between available bandwidth and buffer level heuristics.
Interesting algorithms:
Yin et al. (2015), Li et al. (2014), De Cicco et al. (2013), Miller et al.
(2012), Zhou et al. (2012)
Challenges and drawbacks:
Supports few number of clients
Avoid just one or two of scalability issues
e.g., consistent quality without taking into account fair share of bandwidth
Lack of optimal bitrate decisions
Does not consider any metric of user satisfaction
Suffers from video instability and stalls
Achieves a poor end-user QoE
38. 40
Server-side Bitrate Adaptation
The bitrate adaptation logic is fully controlled by the server (purely
server-driven)
Uses traffic shaping mechanism to assign the bitrate for each client,
e.g., based on some pricing rules
Not requiring any cooperation from the client
Like traditional video streaming systems
Some interesting algorithms
Akhshabi et al. (2013)
Houdaille and Gouache (2012)
De Cicco et al. (2011)
DASH Server DASH client
Traffic Shaper
39. 41
SVC-based Bitrate Adaptation
Each segment can be split into a subset of bit-streams.
The client selects the base layer of the lower quality and
increases the quality by downloading more enhancement layers.
Downloading more layers is based on network conditions.
Interesting algorithms
Kreuzberger et al. (2015), Sieber et al. (2013), Andelin et al. (2012)
40. 42
SDN-based Bitrate Adaptation
Software defined networking is used.
Network resources control and monitoring capabilities
simplify/rapidity of network resource programming and deployment
Avoid the purely client-driven bitrate adaptation issues
The bitrate adaptation logic is controlled, monitored and assisted
by a central coordinator called SDN controller.
QoE improvement => interaction
between a SDN controller and
DASH client
All Interesting algorithms:
Georgopoulos et al. (2013), Farshad et al. (2015),
Arefin et al. (2013), Nam et al. (2014), Wang et al. (2014),
Ferguson et al. (2013), Bari et al. (2013), Gorlatch et al. (2015),
Gudipati et al. (2013), Yap et al. (2013)
41. 43
In-network based Bitrate Adaptation
Bitrate adaptation logic is based on in-network decisions.
In-network process needs a special component.
Agent and/or proxy deployed in the network
Offer the required information that allow
bitrate adaptation algorithm to use
efficiently the network resources.
Interesting algorithms
Mok et al. (2012), Eckert and Knoll (2013),
Bouten et al. (2015), Petrangeli et al. (2015),
Thomas et al. (2015), Joseph and de Veciana (2014),
El Essaili et al. (2013)
42. 44
Commercial Solution Bitrate Adaptation
Microsoft smooth player (MSS)
Current available bandwidth, playback windows resolution and CPU load as heuristics
for bitrate adaptation logic.
Apple HTTP Live streaming player (HLS)
Current available bandwidth, device capabilities as heuristics during the bitrate
adaptation logic process.
Adobe OSMF
Adapts to the network variations based on the available bandwidth and device
processing capabilities.
Akamai HD
Adapts to the network variations based on the available bandwidth and CPU
load.
