1. Dynamic Adaptive Streaming over HTTP
Introduction to DASH
Dynamic Adaptive Streaming over HTTP

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)
 
02 May 2011
Acknowledgment: Thomas Stockhammer (QUALCOMM), Mark Watson (Netflix) – reused their presentations from MMSys’11 accessible via

3. User Frustration in Internet Video
Video not accessible
Behind a firewall
Plugin not available
Bandwidth not sufficient
Wrong/non-trusted device
Wrong format
Fragmentation
Devices
Content Formats
DRMs
Low Quality of Experience
Long start-up delay
Frequent Re-buffering
Low playback quality
No lip-sync
No DVD quality (language, subtitle)
Expensive
Sucks my bandwidth
Need a dedicated devices
Other costs…
One way to build confidence ➪ Open Standards
Ack & ©: Thomas Stockhammer
2010/05/02
Christian Timmerer, Alpen-Adria-Universität Klagenfurt, Austria

4. Christian Timmerer, Alpen-Adria-Universität Klagenfurt, Austria
What is DASH?
2010/05/02
Christian Timmerer, Alpen-Adria-Universität Klagenfurt, Austria

5. HTTP Streaming of Media
Server MF DF
ISOBMFF
M2TS
Client
easy conversion 1 MF DF 2
easy conversion
ISOBMFF
M2TS
ISOBMFF … ISO Base Media File Format (e.g., mp4 – others: avi)
M2TS … MPEG-2 Transport Stream (e.g., DVB, DMB)
MF … Manifest Format (e.g., MPD, FMF)
DF … Delivery Format (e.g., F4F, 3gs)
2010/05/02
Christian Timmerer, Alpen-Adria-Universität Klagenfurt, Austria

6. Adaptive Streaming in Practice
Ack & ©: Mark Watson
2010/05/02
Christian Timmerer, Alpen-Adria-Universität Klagenfurt, Austria

7. Dynamic Adaptive Streaming over HTTP (DASH)
Proprietary Solutions
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
. . .
3GPP Rel.9 Adaptive HTTP Streaming
3GPP Rel.10 DASH
MPEG DASH
OIPF HTTP Adaptive Streaming
time
2010/05/02
Christian Timmerer, Alpen-Adria-Universität Klagenfurt, Austria

8. Christian Timmerer, Alpen-Adria-Universität Klagenfurt, Austria
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

9. DASH Design Principles
DASH is not
system, protocol, presentation, codec, interactivity, client specification
DASH is an enabler
It provides formats to enable efficient and high-quality delivery of streaming services over the Internet
It is considered as one component in an end-to-end service
System definition left to other organizations (SDOs, Fora, Companies, etc.)
Design choices
Enable reuse of existing technologies (containers, codecs, DRM etc.)
Enable deployment on top of HTTP-CDNs (Web Infrastructures, caching)
Enable very high user-experience (low start-up, no rebuffering, trick modes)
Enable selection based on network and device capability, user preferences
Enable seamless switching
Enable live and DVD-kind of experiences
Move intelligence from network to client, enable client differentiation
Enable deployment flexibility (e. g., live, on-demand, time-shift viewing)
Provide simple interoperability points (profiles)
Ack & ©: Thomas Stockhammer
2010/05/02
Christian Timmerer, Alpen-Adria-Universität Klagenfurt, Austria

10. What is specified – and what is not?
Ack & ©: Thomas Stockhammer
2010/05/02
Christian Timmerer, Alpen-Adria-Universität Klagenfurt, Austria

11. Christian Timmerer, Alpen-Adria-Universität Klagenfurt, Austria
DASH Data Model
Segment Info
Initialization Segment
Media Presentation
Media Segment 1
start=0s
Period,
start=100
baseURL=
Representation 1
500kbit/s …
Representation 2
100kbit/s
Period, start=0s …
Representation 1
bandwidth=500kbit/s
width 640, height 480
Segment Info
duration=10s
Template: ./ahs-5-$Index$.3gs …
Media Segment 2
start=10s
Media Segment 3
start=20s
Media Segment 20
start=190s
Period, start=100s …
Period, start=295s … …
Ack & ©: Thomas Stockhammer
2010/05/02
Christian Timmerer, Alpen-Adria-Universität Klagenfurt, Austria

12. Media Presentation Description
Redundant information of Media Streams for the purpose to initially select or reject Groups or Representations
Examples: Codec, DRM, language, resolution, bandwidth
Access and Timing Information
HTTP-URL(s) and byte range for each accessible Segment
Earliest next update of the MPD on the server
Segment availability start and end time in wall-clock time
Approximated media start time and duration of a Media Segment in the media presentation timeline
For live service, instructions on starting playout such that media segments will be available in time for smooth playout in the future
Switching and splicing relationships across Representations
Relatively little other information
Ack & ©: Thomas Stockhammer
2010/05/02
Christian Timmerer, Alpen-Adria-Universität Klagenfurt, Austria

13. Christian Timmerer, Alpen-Adria-Universität Klagenfurt, Austria
DASH Groups & Subsets
Group id="grp-1"
Group by codec, language, resolution, bandwidth, views, etc. – very flexible (in combination with xlink)!
Ranges @height
Representation id="rep-1"
Representation id="rep-2"
. . .
Representation id="rep-n"
Subset id="ss-1"
Contains group="grp-1"
Contains group="grp-4"
Contains group="grp-7"
Group id="grp-2"
Representation id="rep-1"
Representation id="rep-2"
. . .
Representation id="rep-n"
Subsets
Mechanism to restrict the combination of active Groups
Expresses the intention of the creator of the Media Presentation
. . .
Group id="grp-m"
Representation id="rep-1"
2010/05/02
Christian Timmerer, Alpen-Adria-Universität Klagenfurt, Austria
Representation id="rep-2"
. . .
Representation id="rep-n"

14. Christian Timmerer, Alpen-Adria-Universität Klagenfurt, Austria
Segment Indexing
Provides binary information in ISO box structure on
Accessible units of data in a media segment
Each unit is described by
Byte range in the segments (easy access through HTTP partial GET)
Accurate presentation duration (seamless switching)
Presence of representation access positions, e.g. IDR frames
Provides a compact bitrate-over-time profile to client
Can be used for intelligent request scheduling
Generic Data Structure usable for any media segment format, e.g. ISO BMFF, MPEG-2 TS, etc.
Hierarchical structuring for efficient access
May be combined with media segment or may be separate
Ack & ©: Thomas Stockhammer
2010/05/02
Christian Timmerer, Alpen-Adria-Universität Klagenfurt, Austria

15. Christian Timmerer, Alpen-Adria-Universität Klagenfurt, Austria
Segment Indexing
seg1.mp4
Segment Index in MPD only
<MPD>
...
<URL sourceURL="seg1.mp4"/>
<URL sourceURL="seg2.mp4"/>
</MPD>
seg2.mp4
...
<MPD>
...
<URL sourceURL="seg.mp4" range="0-499"/>
<URL sourceURL="seg.mp4" range=" "/>
</MPD>
seg.mp4
Segment Index in MPD + Segment
<MPD>
...
<Index sourceURL="idx.mp4"/>
<URL sourceURL="seg.mp4"/>
</MPD>
idx.mp4
seg.mp4
Segment Index in Segment only
<MPD>
...
<BaseURL>seg.mp4</BaseURL>
</MPD>
idx
seg.mp4
2010/05/02
Christian Timmerer, Alpen-Adria-Universität Klagenfurt, Austria

16. Adaptive Streaming Summary
For on demand
Chunks are unnecessary and costly
Byte range requests have caching and flexibility advantages
Separate audio/video essential for language support
For live
Chunks are unavoidable
Still value in decoupling request size from chunk size
Multiple language audio tracks are rare
May need manifest updates
For both
Switch point alignment required for most CE decoding pipelines
Ack & ©: Mark Watson and Thomas Stockhammer
2010/05/02
Christian Timmerer, Alpen-Adria-Universität Klagenfurt, Austria

17. Christian Timmerer, Alpen-Adria-Universität Klagenfurt, Austria
Adaptation Problem
Choose sequence and timing of requests to minimize probability of re-buffers and maximize quality
Ack & ©: Mark Watson
2010/05/02
Christian Timmerer, Alpen-Adria-Universität Klagenfurt, Austria

18. Christian Timmerer, Alpen-Adria-Universität Klagenfurt, Austria
Conclusions
Asynchronous delivery of the same content to many users is a first-class network service
HTTP CDNs may not be the “perfect” architecture, but it’s working pretty well at scale
Many variations on HTTP Adaptive Streaming theme in deployed systems and emerging standards
DASH provides sufficient flexibility here
DASH is rich and simple at the same time
Understand more detailed market needs
Create profiles as considered necessary
Collaborate with system creators on how to integrate DASH
Ack & ©: Mark Watson and Thomas Stockhammer
2010/05/02
Christian Timmerer, Alpen-Adria-Universität Klagenfurt, Austria

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. Christian Timmerer, Alpen-Adria-Universität Klagenfurt, Austria
Implementations
Reference Software
Open Source, ISO Copyright
Currently not publicly available
GPAC Implementation
GNU Lesser General Public License
VLC Plugin
2010/05/02
Christian Timmerer, Alpen-Adria-Universität Klagenfurt, Austria

21. Thank you for your attention
... questions, comments, etc. are welcome …
Ass.-Prof. Dipl.-Ing. Dr. Christian Timmerer
Klagenfurt University, Department of Information Technology (ITEC)
Universitätsstrasse 65-67, A-9020 Klagenfurt, AUSTRIA
Tel: +43/463/ Fax: +43/463/
© Copyright: Christian Timmerer
2010/05/02
Christian Timmerer, Alpen-Adria-Universität Klagenfurt, Austria

22. ABR – Adaptive Bitrate Adaptation
Adaptation Schemes
ABR – Adaptive Bitrate Adaptation

23. Dynamic Adaptive Video Streaming over HTTP (DASH)
Abdelhak Bentaleb
Supervisor
Prof. Roger Zimmermann
School of Computing
National University of Singapore

24. 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. Push and Pull-Based video delivery source
Push-Based Delivery
Pull-Based Delivery
Source (Server)
Broadcasters/servers 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
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. What is Streaming? Definition Two Main Characteristics
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. 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. HTTP Dynamic Adaptive video Streaming (DASH)
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
Request the MPD
Download segments using HTTP GET
select bitrate based on TCP bandwidth estimation
Adapt to network resources dynamically

29. 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).
HTTP
TCP

30. Overview

31. Client-side Bitrate (BR) Adaptation
The bitrate adaptation logic is fully controlled by the client (purely client-driven).
Bitrate adaptation heuristics based on:
Available bandwidth
Playback buffer size
Chunk scheduling
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. 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
This paper compares four commuter scenarios:

33. Adaptation Comparison (2)
Netview
Netview

34. 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. 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. 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. 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. 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
600Kbps
300Kbps
900Kbps
1000Kbps
Traffic Shaper

39. 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. 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. 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. 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.

43. Comparison
heterogeneous systems = different device capabilities with different communication technologies