Dynamic Adaptive Streaming over HTTP DASH Christian Timmerer and Christopher Müller AlpenAdria Universität Klagenfurt AAU Faculty of Technical Sciences TEWI Institute of Information Technology ITEC ID: 644996
Download Presentation The PPT/PDF document "Introduction to DASH Dynamic Adaptive St..." is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
Introduction to DASH
Dynamic Adaptive Streaming over HTTPSlide2
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
/Slide3
User Frustration in Internet Video
Video not
accessible
Behind a firewallPlugin not availableBandwidth not sufficientWrong/non-trusted deviceWrong formatFragmentationDevicesContent FormatsDRMsLow Quality of
ExperienceLong start-up delay
Frequent
Re-buffering
Low
playback qualityNo lip-syncNo DVD quality (language, subtitle)ExpensiveSucks my bandwidthNeed a dedicated devicesOther costs…
2010/05/02
Christian Timmerer, Alpen-Adria-Universität Klagenfurt, Austria
3
Ack & ©: Thomas Stockhammer
One way to build confidence ➪ Open StandardsSlide4
What is DASH?
2010/05/02
Christian Timmerer, Alpen-Adria-Universität Klagenfurt, Austria
4http://en.wikipedia.org
/wiki/Dash_(disambiguation)Slide5
HTTP Streaming of Media
2010/05/02
Christian Timmerer, Alpen-Adria-Universität Klagenfurt, Austria
5
Server
MF
DF
ISOBMFF
M2TS
easy
conversion
MF
DF
ISOBMFF
M2TS
Client
easy
conversion
1
2
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)Slide6
Adaptive Streaming in Practice
2010/05/02
Christian Timmerer, Alpen-Adria-Universität Klagenfurt, Austria
6Ack & ©: Mark WatsonSlide7
Dynamic Adaptive Streaming over HTTP (DASH)
2010/05/02
Christian Timmerer, Alpen-Adria-Universität Klagenfurt, Austria
7http://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
timeSlide8
Outline
Introduction
DASH
Design PrinciplesScope: What is specified – and what is not!DASH Data ModelMedia Presentation DescriptionSegment IndexingDynamic & AdaptiveVideo on Demand vs. LiveThe Adaptation ProblemConclusions & Future Work2010/05/02Christian Timmerer, Alpen-Adria-Universität Klagenfurt, Austria
8Slide9
DASH Design Principles
DASH is
not
system, protocol, presentation, codec, interactivity, client specificationDASH is an enablerIt provides formats to enable efficient and high-quality delivery of streaming services over the InternetIt is considered as one component in an end-to-end serviceSystem definition left to other organizations (SDOs, Fora, Companies, etc.)Design choicesEnable 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 preferencesEnable seamless switchingEnable live and DVD
-kind of experiencesMove
intelligence from network to client, enable client differentiation
Enable deployment flexibility (e. g
., live, on-demand, time-shift viewing)Provide simple interoperability points (profiles)
2010/05/02
Christian Timmerer, Alpen-Adria-Universität Klagenfurt, Austria
9
Ack
& ©: Thomas
StockhammerSlide10
What is
specified
– and what is not?
2010/05/02Christian Timmerer, Alpen-Adria-Universität Klagenfurt, Austria10Ack & ©: Thomas StockhammerSlide11
DASH Data Model
2010/05/02
Christian Timmerer, Alpen-Adria-Universität Klagenfurt, Austria
11
Segment Info
Initialization Segment
http://www.e.com/ahs-5.3gp
Media Presentation
Period, start=0s
…
Period, start=100s
…
Period, start=295s
…
…
Period,
start=100
baseURL=http://www.e.com/
Representation 1
500kbit/s
…
Representation 2
100kbit/s
…
Representation 1
bandwidth=500kbit/s
width
640,
height
480
Segment Info
duration=10s
Template:
./ahs-5-$Index$.3gs
…
Media Segment 1
start=0s
http://www.e.com/ahs-5-1.3gs
Media Segment 2
start=10s
http://www.e.com/ahs-5-2.3gs
Media Segment 3
start=20s
http://www.e.com/ahs-5-3.3gh
Media Segment 20
start=190s
http://www.e.com/ahs-5-20.3gs
Ack
& ©:
Thomas
StockhammerSlide12
Media Presentation Description
Redundant
information of
Media Streams for the purpose to initially select or reject Groups or RepresentationsExamples: Codec, DRM, language, resolution, bandwidthAccess and Timing InformationHTTP-URL(s) and byte range for each accessible SegmentEarliest next update of the MPD on the serverSegment availability start and end time in wall-clock timeApproximated media start time and duration of a Media Segment in the media presentation timelineFor 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 RepresentationsRelatively little other information2010/05/02Christian Timmerer, Alpen-Adria-Universität Klagenfurt, Austria
12
Ack & ©: Thomas
StockhammerSlide13
DASH Groups & Subsets
Group by codec, language, resolution, bandwidth, views, etc. – very flexible (in combination with
xlink
)!Ranges for the @bandwidth, @width, @height and @frameRate2010/05/02Christian Timmerer, Alpen-Adria-Universität Klagenfurt, Austria13Group 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"
Representation id="rep-n"
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 Slide14
Segment Indexing
Provides
binary information
in ISO box structure onAccessible units of data in a media segmentEach unit is described byByte range in the segments (easy access through HTTP partial GET)Accurate presentation duration (seamless switching)Presence of representation access positions, e.g. IDR framesProvides a compact bitrate-over-time profile to clientCan be used for intelligent request schedulingGeneric Data Structure usable for any media segment format, e.g. ISO BMFF, MPEG-2 TS, etc.Hierarchical
structuring for efficient accessMay be combined with media segment
or may be
separate
2010/05/02
Christian Timmerer, Alpen-Adria-Universität Klagenfurt, Austria14Ack
& ©: Thomas StockhammerSlide15
Segment Indexing
2010/05/02
Christian Timmerer, Alpen-Adria-Universität Klagenfurt, Austria
15Segment Index in MPD onlySegment Index in MPD + Segment Segment Index in Segment only
<MPD> ... <URL
sourceURL
="seg1.mp4"/>
<URL
sourceURL="seg2.mp4"/></MPD>seg1.mp4
seg2.mp4
...
<MPD>
...
<URL
sourceURL
="seg.mp4" range="0-499"/>
<URL
sourceURL
="seg.mp4" range="500-999"/>
</MPD>
seg.mp4
<MPD>
...
<Index
sourceURL
="idx.mp4"/>
<URL
sourceURL
="seg.mp4"/>
</MPD>
seg.mp4
idx.mp4
<MPD>
...
<
BaseURL
>seg.mp4</
BaseURL
>
</MPD>
seg.mp4
idxSlide16
Switch Point Alignment
2010/05/02
Christian Timmerer, Alpen-Adria-Universität Klagenfurt, Austria
16Ack & ©: Mark WatsonSlide17
Adaptive Streaming Summary
For on demand
Chunks
are unnecessary and costlyByte range requests have caching and flexibility advantagesSeparate audio/video essential for language support2010/05/02Christian Timmerer, Alpen-Adria-Universität Klagenfurt, Austria17Ack & ©: Mark Watson and Thomas
Stockhammer
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 pipelinesSlide18
Adaptation Problem
Choose
sequence
and timing of requests to minimize probability of re-buffers and maximize quality2010/05/02Christian Timmerer, Alpen-Adria-Universität Klagenfurt, Austria18
Ack & ©: Mark WatsonSlide19
Conclusions
Asynchronous
delivery of the
same content to many users is a first-class network serviceHTTP CDNs may not be the “perfect” architecture, but it’s working pretty well at scaleMany variations on HTTP Adaptive Streaming theme in deployed systems and emerging standardsDASH provides sufficient flexibility hereDASH is rich and simple at the same timeUnderstand more detailed market needsCreate
profiles as considered necessaryCollaborate with system creators on how to integrate
DASH
2010/05/02
Christian Timmerer, Alpen-Adria-Universität Klagenfurt, Austria
19Ack & ©:
Mark Watson and Thomas StockhammerSlide20
Potential Future Work Items
MMSys’11 Keynote
HTTP
Adaptive Streaming in Practice by Mark Watson (Netflix)Future workGood models for future bandwidthTractable representations of future choices - how to efficiently search the 'choice space’What are the quality goals?Call for adaptation logicsEfficient implementations of the actual adaptation logic which is responsible for the dynamic and adaptive part of DASHGet 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.htmlSlide21
Implementations
Reference Software
Open Source, ISO Copyright
Currently not publicly availableGPAC ImplementationGNU Lesser General Public Licensehttp://gpac.wp.institut-telecom.fr/VLC PluginGNU Lesser General Public Licensehttp://www-itec.uni-klu.ac.at/dash/2010/05/02Christian Timmerer, Alpen-Adria-Universität Klagenfurt, Austria21Slide22
Thank you for your attention
... questions, comments, etc. are welcome …
Ass.-Prof. Dipl.-Ing. Dr. Christian TimmererKlagenfurt University, Department of Information Technology (ITEC)
Universitätsstrasse 65-67, A-9020 Klagenfurt, AUSTRIA
christian.timmerer@itec.uni-klu.ac.at
http://research.timmerer.com/
Tel: +43/463/2700 3621 Fax: +43/463/2700 3699
© Copyright: Christian Timmerer22
2010/05/02
Christian Timmerer, Alpen-Adria-Universität Klagenfurt, AustriaSlide23
Adaptation Schemes
ABR – Adaptive Bitrate AdaptationSlide24
Dynamic Adaptive Video Streaming over HTTP (DASH)
Abdelhak
Bentaleb
bentaleb@comp.nus.edu.sg
Supervisor
Prof. Roger Zimmermann
National University of Singapore
School of ComputingSlide25
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) CISCOSlide26
Push and Pull-Based video delivery source
Push-Based Delivery
Pull-Based
DeliverySource (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 VDSProtocolsRTSP, RTP, UDPHTTP, 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
Slide27
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.Slide28
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.Slide29
Outline
Introduction
Background
Problem Identification, Motivation and Goals
Literature Survey
Proposed Work
Performance Evaluation
Conclusion and Future DirectionsSlide30
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 POSTSlide31
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
TCPSlide32
OverviewSlide33
Client-side
Bitrate (BR)
Adaptation
The bitrate adaptation logic is fully controlled by the client (purely client-driven).Bitrate adaptation heuristics based on:
A
vailable bandwidth
P
layback
buffer size
C
hunk scheduling
H
ybrid-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)
Slide34
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 s
cenarios:Slide35
Adaptation Comparison (2)
Netview
NetviewSlide36
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 s
uffer
from buffer starvation and undesirable
QoE
Worst decisions when number of clients increaseSlide37
2.
Buffer
L
evel 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
d
rawbacks:
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
clientsSlide38
3.
Chunk
Scheduling
BR AdaptationDivides 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
d
rawbacks:
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 clientSlide39
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
.,
c
onsistent
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
Slide40
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
ShaperSlide41
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)Slide42
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
assistedby 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)Slide43
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 allowbitrate
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)
Slide44
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.Slide45
ComparisonSlide46Slide47
BackupSlide48
Client-side Bitrate Adaptation
The bitrate adaptation logic is fully controlled by the client (purely client-driven)
Bitrate adaptation heuristics
Available bandwidth, playback buffer size, chunk scheduling and hybrid-based.Slide49
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
DASH Server
DASH client
600Kbps
300Kbps
900Kbps
1000Kbps
Traffic
ShaperSlide50
Server-side Bitrate Adaptation
Some interesting algorithms
Akhshabi
et al (2013), Houdaille
and Gouache (2012), De Cicco et al (2011)
Challenges
and
Drawbacks
Produce a high overheads at server-side
High
complexity
Store and maintain the information for each client
Need a special servers to implement the bitrate adaptation logic
Violate the DASH standard (client-based bitrate adaptation logic)
Sever/network assistance approach can be an alternative solutionSlide51
SVC-based Bitrate Adaptation
Each segment can be split into a subset of bit-streams (temporal,
spacial
, SNR)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 conditionsSlide52
SVC-based Bitrate Adaptation
Interesting algorithms
Kreuzberger
et al (2015), Sieber et al (2013),
Andelin et al (2012)
Challenges
and
Drawbacks
Cannot adapt properly due to rapid bandwidth fluctuations
Unacceptable
user satisfaction
Does not scalable when number of DASH clients increase
Scalability issues rise
Complexity of SVC encoding and decoding in term of time, processing resources
Produce a lot of overheadSlide53
SDN-based Bitrate Adaptation
Software
defined
networking is usedNetwork resources control and monitoring capabilities
simplify/rapidity of network resource programming and deployment
Avoid
the
purely
client-driven bitrate adaptation issuesThe bitrate adaptation logic is controlled, monitored and assisted by a central coordinator called SDN controller
QoE
improvement => interaction
between a SDN controller and
DASH clientSlide54
SDN-based Bitrate Adaptation
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)
Main challenges
Integration with DASH system
Intelligent network ressources management, allocation and monitoring for
each
client
QoS
and
QoE
guarantee
Support a large
number
of
competing
clients
Optimal
bitrate
level
decisions
, etc.Slide55
In-network based Bitrate Adaptation
Bitrate
adaptation
logic is based on in-network decisionsIn-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)
Slide56
In-network based Bitrate Adaptation
Challenges
and
DrawbacksGenerate a lot of overhead => Congestion
Affect
negatively
the end-user
QoE
and overall system performanceSupport heterogeneous systems ?
Some architecture is very difficult to implementSlide57
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,Slide58
Commercial Solution Bitrate Adaptation
Challenges
and
DrawbacksSuffer from suboptimal bitrate decisions
Fail to adapt quickly to rapid bandwidth variations
Scalability
issues
appear
buffer underrun, video instability, quality oscillations, unnecessary bitrate switches
Unpleasant
QoE
in many cases
Refer to results