DASH/2.0 @ ICME 2013

Title: Dynamic Adaptive Streaming over HTTP/2.0

Authors: Christopher Mueller, Stefan Lederer, Christian Timmerer and Hermann Hellwagner

Abstract:┬áMPEG Dynamic Adaptive Streaming over HTTP (DASH) is a new streaming standard that has been recently ratified as an international standard (IS). In comparison to other streaming systems, e.g., HTTP progressive download, DASH is able to handle varying bandwidth conditions providing smooth streaming. Furthermore, it enables NAT and Firewall traversal, flexible and scalable deployment as well as reduced infrastructure costs due to the reuse of existing Internet infrastructure components, e.g., proxies, caches, and Content Distribution Networks (CDN). Recently, the Hypertext Transfer Protocol Bis (httpbis) working group of the IETF has officially started the development of HTTP 2.0. Initially three major proposals have been submitted to the IETF i.e., Googles’ SPDY, Microsofts’ HTTP Speed+Mobility and Network-Friendly HTTP Upgrade, but SPDY has been chosen as working draft for HTTP 2.0. In this paper we implemented MPEG-DASH over HTTP 2.0 (i.e., SPDY), demonstrating its potential benefits and drawbacks. Moreover, several experimental evaluations have been performed that compare HTTP 2.0 with HTTP 1.1 and HTTP 1.0 in the context of DASH. In particular, the protocol overhead, the performance for different round trip times, and DASH with HTTP 2.0 in a lab test scenario has been evaluated in detail.

This entry was posted in DASH. Bookmark the permalink.

2 Responses to DASH/2.0 @ ICME 2013

  1. Hi Christopher,
    I’ve about 25 years of professional experience in MPEG technologies. I follow MPEG DASH since 2011. It is very interesting that — at least — it DOES exist a standard in streaming: DASH is the first standard about streaming, and really it seems to reprint the story of “old” MPEG2 TS… something come from satellite operators, algorithms from universities etc etc. But I want to ask you one thing: in case of VoD unicast streaming (that for me recalls the transfer of thousand “tons” of bytes toward the user (thousand slices per client, for all clients) is probably mandatory, but in case of live streaming of plain live broadcasting — such as the plain television — why not to investigate the intelligent usage of MPEG caches as used by VLC-like live streaming ? I’m testing that through an Apache proxying, it seems to be possible to feed from a small computer web server (a single core xeon) many clients without the expensive proportionality of the unicast. It probably could be arranged in adaptive way (adding a DASH hat), Try to open the stream http://iginomanfre.it/HD_4000 with VLC, it is a 1080p stream live … (other examples from http://www.iginomanfre.it/html/android.html, and around).
    Isn’t more “green” to stream “multicast-like” one (one only) live stream (o one — again one only — set of multibitrate stream) instead of thousand replications of them one per client ?

    Best regards, Igino Manfre’

    • Christopher Mueller says:

      Hi Igino,

      Nice explanation and of course it would be good if DASH could reprint the story of MP2TS ;) .

      About caching and unicast: MPEG caches are good and if deployed the can speed up things heavily. Anyway if you are using HTTP you have already a tremendous number of caches that you can utilize and on the content side you can use multiple servers (CDNs) in parallel to distribute the load due to the stateless design of HTTP. DASH enables, with its chunked media approach, an application layer multicast through these caches, e.g., two clients behind a HTTP cache that select the same segments will share the data from the cache and from the content server to the cache the segment will only be transferred once.

      Best Regards
      Chris

Leave a Reply

Your email address will not be published. Required fields are marked *

*


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>