HTTP ADAPTIVE STREAMING WITH MEDIA FRAGMENT URIS Wim Van Lancker, Davy Van Deursen, Erik Mannens, RikVan de Walle Ghent University – IBBT Ghent, Belgium {wim.vanlancker, davy.vandeursen, erik.mannens, rik.vandewalle}@ugent.be ABSTRACT HTTP adaptive streaming was introduced with the general idea that user agents interpret a manifest file (describing dif- ferent representations and segments of the media); where- after they retrieve the media content using sequential HTTP progressive download operations. MPEG started with the standardization of an HTTP streaming protocol, defining the structure and semantics of a manifest file and additional re- strictions and extensions for container formats. At the same time, W3C is working on a specification for addressing me- dia fragments on the Web using Uniform Resource Identi- fiers. The latter not only defines the URI syntax for media fragment identifiers but also the protocol for retrieving me- dia fragments over HTTP. In this paper, we elaborate on the role of Media Fragment URIs within HTTP adaptive stream- ing scenarios. First, we elaborate on how different media rep- resentations can be addressed by means of Media Fragment URIs, by using track fragments. Additionally, we illustrate how HTTP adaptive streaming is realized relying on the Me- dia Fragments URI retrieval protocol. To validate the pre- sented ideas, we implemented Apple’s HTTP Live streaming technique using Media Fragment URIs. Index Terms— HTTP Streaming, Media Delivery, Media Fragment URIs 1. INTRODUCTION Multimedia content has become an essential part of the World Wide Web. Moreover, Web-based media is exploding: it is used for entertainment, education, advertising, product reviews, etc. Media delivery on the Web evolved from download-and-play over progressive download to real-time streaming protocols such as the Real Time Streaming Proto- col (RTSP). Recently, a new media delivery technique, called HTTP adaptive streaming, was introduced showing an inter- esting combination of the features of real-time streaming pro- tocols and HTTP progressive download. The research activities as described in this paper were funded by Ghent University, the Interdisciplinary Institute for Broadband Technology (IBBT), the Institute for the Promotion of Innovation by Science and Technology in Flanders (IWT), the Fund for Scientific Research-Flanders (FWO-Flanders), and the European Union. Various proprietary implementations are already avail- able: Microsoft’s Smooth Streaming, Apple’s HTTP Live streaming, and Adobe’s Dynamic HTTP Streaming. Almost all current proprietary solutions for HTTP streaming define the structure and semantics of a manifest file, describing the high-level structure of the media content in terms of repre- sentations and temporal segments. Additionally, extensions and restrictions are defined for one or more existing container formats encapsulating the media content. User Agents (UA) interpret the manifest file and retrieve the media content us- ing sequential HTTP progressive download operations. Cur- rently, MPEG is standardizing HTTP adaptive streaming as media delivery protocol, Dynamic Adaptive Streaming over HTTP (DASH, [1]), which is based on 3GPP Adaptive HTTP Streaming. In this paper, we investigate how Media Fragment URIs can be used within HTTP adaptive streaming scenarios. Note that Wu et al. already indicated the relevance of Media Frag- ments within HTTP streaming [2]. The specification of Media Fragment URIs is currently being developed within W3C by the Media Fragment Working Group 1 (MFWG). Its mission is to address media fragments on the Web using Uniform Re- source Identifiers (URIs). Although most HTTP streaming solutions rely on the use of regular HTTP 1.1 Web servers, we assume in this paper the availability of Media Fragments- aware servers for HTTP streaming and describe the impact of this availability for HTTP streaming solutions. Addition- ally, since the Media Fragments 1.0 specification also fore- sees a scenario for serving Media Fragment URIs using reg- ular HTTP 1.1 Web servers, we will elaborate on how this scenario fits in the current HTTP streaming solutions. 2. MEDIA FRAGMENTS 1.0 The Media Fragments 1.0 specification supports three differ- ent axes for media fragments: temporal (i.e., a time range), spatial (i.e., a spatial region), and track (i.e., a track contained in the media resource). Since the spatial fragment axis is not relevant in the context of HTTP streaming, we will not fur- ther discuss it. Further, the specification recommends both 1 http://www.w3.org/2008/WebVideo/Fragments/