The document discusses the tradeoff between latency and server load in DASH live streaming, highlighting how large segment sizes can hinder real-time experiences, while smaller sizes increase server requests. It introduces a solution using HTTP/2.0's push feature, allowing clients to define segment requests without explicit requests, and discusses various DASH push header options. Alternatives such as playing segments while receiving them are also mentioned, which may reduce client latency but not server-induced latency.

1. 1
DASH
&
HTTP2.0

2. 2
Overview
DASH Live has a latency / server load tradeoff:
Large segment size create latency which hinders the
real-time live experience
Shorter segment size requires more segment requests
so it loads the server
HTTP2.0 has push option in which the server
pushes content to the client without the client
EXPLICIT request

3. 3
Solution
Upon each request, the client will be able to
define the number of segments that will be
pushed by the server without an Explicit
request
Implementation using specific DASH push
header in HTTP2.0

4. 4
HTTP2.0 push header options
 “DASH-PUSH: type=push-next; K=5” – for segments
 “DASH-PUSH: type=push-time; T=10” – for seconds
 “DASH-PUSH: type=uri-list; seg1.mp4;seg2.mp4…” – for
segment names
 DASH-PUSH: type=uri-template; seg{1}.mp4; 1:2:3” – for
template segment names
 DASH-PUSH: type=uri-wildcard; text/css” – for all resources
of type text/css

5. 5
Other solutions
An alternative solution would be to play a
segment while still receiving it.
This solution would decrease some of the
latency on the client but would not lower the
latency created by the serve while it creates
the segment

6. 6
Resources
http://
tools.ietf.org/html/draft-ruellan-httpbis-dash-http

7. 6
Resources
http://
tools.ietf.org/html/draft-ruellan-httpbis-dash-http