MPEG-DASH Overview

MPEG-DASH is a relatively recent standard (ratified in December 2011 [12], tested in 2012, edited in 2014 [13]) that has being proposed by ISO/IEC MPEG and the 3rd Generation

Partnership Project (3GPP) to address the problems of interoperability and traditional approaches to web streaming as well as to improve Quality of Experience (QoE) levels. Vendor specific HTTP-based adaptive streaming solutions have been available since 2007. Move Networks, Inc. was the first to adopt HTTP-based streaming and other vendors followed. Commercial (vendor-specific) implementations include (a) Adobe’s Dynamic HTTP Streaming (HDS) [99] which is platform agnostic and supported by the Adobe Flash Player, (b) Apple’s HTTP Live Streaming (HLS) [100] based on Apple’s iOS and Google’s Android operating systems, and supported by Apple’s Quicktime media player, and (c) Microsoft Smooth Streaming [101] based on the Microsoft’s Windows operating system and supported by Microsoft’s Silverlight application framework. Each implementation provides adaptive bitrate streaming and uses the MPEG-4 H.264/AVC coded video as input.

MPEG-DASH is a standard for a client controlled media delivery model. Media content is typically stored on standard HTTP servers in multiple versions, further divided into segments of varying duration. The logic of a typical DASH-based adaptive system is located at the client side, which scales well. As a client/server paradigm, it uses existing HTTP-based multimedia content delivery infrastructure, such as web servers, HTTP caches and CDNs without the need for specialised servers such as the Flash Media Server (or other competing products). MPEG- DASH is HTTP/TCP based which eliminates the firewall and NAT gateway traversal issues that plague UDP-based approaches. Unlike progressive download, MPEG-DASH supports dynamic bitrate switching and live media services.

In a MPEG-DASH context, web servers host multiple presentations (versions/copies) of video content differing in temporal, spatial or fidelity quality (e.g. frame rate, resolution, colour depth, level of detail) ranging from lower quality renditions for 3G connections, up to very high quality (AVC/HEVC HD). Each representation consists of segments (i.e. fragments, media chunks) of predefined duration, e.g. 10 seconds. MPEG-DASH performs video streaming using consecutive downloads of these video segments. The process is initiated by the client, and the server responds with a video manifest (description) file. The client then proceeds by requesting content quality that matches initial conditions (e.g. connection type, buffer size, remaining battery life) without the need for negotiation with the hosting server. After a segment is received, the client simply requests (via the HTTP GET method) the next segment of the quality that matches changes of the device state (e.g. buffer fill level, battery life), network traffic (e.g. drop/increase in estimated throughput) or user preferences (e.g. viewer profile, current task) [98]. This process is illustrated in Figure 2-3.

Server DASH Client

GET Video A (600kbps) segment 1 GET Video MPD

GET Video A (700kbps) segment 2 GET Video A (900kbps) segment 3

Start with low quality Good throughput -> request better quality

Low throughput -> request lower quality

600kbps 700kbps 900kbps

700kbps

GET Video A (700kbps) segment x

Figure 2-3: MPEG-DASH Video Requesting Process

The MPEG-DASH model places decision-making at the client side. The client’s insight into performance yields the most informed adaptation decision on what quality to request from the server, which leads to optimum QoE levels under given delivery conditions. This part of the standard “does not provide a normative specification for such a client” [12, p. 7], however it provides an “informative client model” [12, p. 7] which is utilised in Section 2.4.5 to describe client-side architecture and behaviour.

time th ro u gh p u t Client Server vi d eo q u al ity MPD MPD MPD

Figure 2-4: MPEG-DASH Adaptation Overview

Figure 2-4 illustrates an example of the segment selection process where the server stores a video file in four qualities (Low, Medium, High and Highest), the video is divided in seven segments and is streamed over a network of variable bandwidth. The quality (bitrate) of segments requested by the client with a portable device (e.g. tablet), depends on the current network bandwidth. When bandwidth is very low, the client requests the lowest available quality (e.g. the second segment), as the bandwidth improves, the quality of requested segments also improves (e.g. third segment), finally, when the bandwidth improves further, the better quality is requested (e.g. segments four and five). Clearly, since a client’s requests must take into account network bandwidth, a client requires a bandwidth estimator. Approaches to client- side bandwidth estimation are described in Section 2.4.8.

This approach is also cost effective as there is no need to pay for specialised video streaming servers. The carrier’s network delivers just the video segments that are needed (as opposed to progressive download, where a long initial buffering is required prior to the playout).

MPEG-DASH is gaining popularity and the main industry players are collaborating in building compatible clients and content creation tools. These industry groups include: Open IPTV Forum (www.oipf.tv/), HbbTV (www.hbbtv.org/), UK Digital TV Group (www.dtg.org.uk/) and the DASH Industry Forum (www.dashif.org/). An example of mainstream DASH applications include BBC pilot using HTML 5 compatible browsers [102].

In summary, the idea behind MPEG-DASH is to harness the available, low cost HTTP infrastructure to meet expanding demands for streamed video. The web servers provide multiple versions of a video, thus meeting the requirements of heterogeneous viewing devices, making MPEG-DASH a practical solution for addressing video streaming demands due to the surge in availability of fast mobile Internet connections and the ubiquitous utilisation of portable devices.