Dynamic Adaptive Streaming over HTTP (DASH): Past, Present, and Future
Once upon a time people began to deliver (or stream) multimedia content over HTTP and, consequently, mainly TCP. Early deployments of HTTP streaming used progressive download, where the client opens a TCP connection to a server and progressively downloads the multimedia content. As soon as enough data is available on the client, the client could eventually start with the decoding and rendering respectively. However, in case of bandwidth fluctuations, clients cannot react, resulting in service interruptions, also referred to as stalls. Probably one of the first adaptive HTTP streaming solutions employed an explicit adaptation loop—inspired by RTP-based streaming—where clients perform bandwidth measurements and push the information towards the server. The server analyzes these reports and modifies the progressive download session on-demand.
Nowadays, various other industry solutions for the adaptive HTTP streaming exist but each following the same principles that eventually led to the standardization of Dynamic Adaptive Streaming over HTTP (DASH) but with some (minor) differences in terms of manifest and segment formats. This article aims to highlight the early days of DASH, evaluate the present, and provide an outlook into the future.
The History of DASH
Back in April 2010, MPEG issued the call for proposals on the HTTP Streaming of MPEG Media accompanied by the typically required documents such as context & objectives, use cases, and requirements. At this time, the main objectives of that were as follows:
- Efficient delivery of MPEG media over HTTP in an adaptive, progressive, download/streaming fashion;
- Support of live streaming of multimedia content;
- Efficient and ease of use of existing content distribution infrastructure components such as CDNs, proxies, caches, NATs and firewalls;
- Support of integrated services with multiple components;
- Support for signaling, delivery, utilization of multiple content protection and rights management schemes; and
- Support for efficient content forwarding and relay.
Actually and interestingly, the call for the HTTP streaming has been extracted from a bigger MPEG project due to urgent industry needs that have to be accommodated in order to avoid market fragmentation. This bigger MPEG project was called modern media transport, which is now known as MPEG Media Transport (MMT).
Figure 1. 93rd MPEG Meeting, Geneva, Switzerland, July 2010.
In July 2010 I was chairing the evaluation of responses submitted to the HTTP Streaming of MPEG Media Ad-hoc Group at the 93rd MPEG Meeting in Geneva, Switzerland (Figure 1). We had 15 submissions from 20 organizations (companies, institutions, and universities) and the 3GPP's Adaptive HTTP Streaming (AHS) was selected as a starting point which, at the time, consisted of a definition of the XML-based Media Presentation Description (MPD) and segment formats based on the ISO Base Media File Format (ISOBMFF). Additionally, the Open IPTV Forum (OIPF) had extended 3GPP’s AHS with segment formats based on the MPEG-2 Transport Stream (M2TS). In OIPF this is called HTTP Adaptive Streaming (HAS). The aim of MPEG and the challenge was now to come up with a standard that harmonized 3GPP’s AHS — comprising MPD and ISOBMFF segments — and OIPF’s HAS — extending AHS with MT2S segments — into a single standard while satisfying new use cases and requirements that might come up during the development of this standard. We all know where such efforts sometimes lead, but finally, both 3GPP and OIPF aligned their specifications to MPEG-DASH and others (e.g., HbbTV) have adopted MPEG-DASH. Please note that initially DASH was called MASH, media adaptive streaming over HTTP, which was dropped as it was too close to the name of a famous American TV series. The remainder of the DASH history is very well covered by Nicolas Weil’s timeline.
MPEG-DASH Today
If you want to know about DASH and how it actually works, I’ve collected some DASH tutorials given by myself and others, with slides and video material available here. The basic goal of today’s HTTP-based multimedia streaming solutions is to provide multiple versions of the same content (e.g., different bitrates), chop these versions into small segments (e.g., two seconds), and let the client decide which segment (of which version) to download next, based on its context (e.g., bandwidth). Typically, the relationship between the different versions is described by a manifest, which is provided to the client prior to the streaming session (Figure 2).
Figure 2. Today's HTTP streaming.
Nicholas Weil presents snapshot of current status of DASH—post-IBC 2013—including a directory of available implementations by various companies.
Still, some DASH issues remain …
One of the major open issues — at least for many network and service providers — is the lack of support in terms of session management. Within MPEG we tried to address this issue by hosting an official MPEG workshop collocated with the 105th MPEG meeting in July 2013 in Vienna, Austria. As the 87th IETF meeting was in Berlin at the same time, some IETF experts, specifically those working on content distribution networks interconnection (cdni), attended the MPEG workshop and shared their views. The outcome of this workshop led MPEG to start working on server- and network-assisted DASH with the aim to collect various server and network parameters that provide assistance for the DASH client operations and to define requirements for appropriate signaling mechanisms thereof (i.e., protocols and application programming interfaces).
The Future of MPEG-DASH
So what’s next?
I'm asked very often what is the (big) next step in ABR (note: adaptive bitrate is often used as a common term in this context) and — as you all know — it's always difficult to predict the future. Still, there are a few issues we can be relatively sure that will be at the forefront in the near term:
- Multi-path delivery, e.g., Multipath TCP (MPTCP), which is actually transparent to the application layer and, thus, the application logic inside the DASH client. Transport folks are promoting this as a feature, but DASH evangelists might have a different opinion as the adaptation logic is influenced by the throughput provided from the transport layer and unaware of the bandwidth of the different paths.
- DASH over HTTP/2.0, CCN, and — in general — protocols “other” than HTTP. No, this is not a mistake; please let me explain. It is true that the “H” in DASH stands for HTTP but the standard mandates that the usage of HTTP-URLs (i.e., URI schemes http and https) within the MPD. How one delivers the segments to the HTTP client is not specified and one might simply use a proxy (which could be located at the client or elsewhere) that translates everything that comes from (or goes to) the transport layer into HTTP request/response messages. However, there are also proponents that advocate allowing an explicit usage of protocols other than HTTP.
- Hybrid delivery in different ways, like broadband/broadcast which is used very often as the most prominent representative, use cases requiring inter-destination media synchronization, and the combination of DASH with conversational services.
I agree that these aspects do not describe the “next big thing,” but will be most likely important steps towards achieving the goal of a universal media experience.
Related Articles
MPEG-DASH is slowly but surely becoming the main competitor to HLS, driven by adoption by major players and intrinsic strengths. Here's who's using it now, who's going to be soon, and what challenges still need to be addressed.
08 Apr 2014
How dynamic is MPEG-DASH ecosystem after IBC 2013? Here is an analysis of the latest trends and an extensive industry DASH-compliant solutions directory.
10 Oct 2013