You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
2055 lines
90 KiB
2055 lines
90 KiB
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
|
|
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
|
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-us" lang="en-us">
|
|
<head>
|
|
<meta http-equiv="content-type" content="text/html; charset=UTF-8" />
|
|
<title>Media Fragments URI 1.0</title>
|
|
<style type="text/css">
|
|
code { font-family: monospace; }
|
|
|
|
div.constraint,
|
|
div.issue,
|
|
div.note,
|
|
div.notice { margin-left: 2em; }
|
|
|
|
ol.enumar { list-style-type: decimal; }
|
|
ol.enumla { list-style-type: lower-alpha; }
|
|
ol.enumlr { list-style-type: lower-roman; }
|
|
ol.enumua { list-style-type: upper-alpha; }
|
|
ol.enumur { list-style-type: upper-roman; }
|
|
|
|
|
|
div.exampleInner pre { margin-left: 1em;
|
|
margin-top: 0em; margin-bottom: 0em}
|
|
div.exampleOuter {border: 4px double gray;
|
|
margin: 0em; padding: 0em}
|
|
div.exampleInner { background-color: #d5dee3;
|
|
border-top-width: 4px;
|
|
border-top-style: double;
|
|
border-top-color: #d3d3d3;
|
|
border-bottom-width: 4px;
|
|
border-bottom-style: double;
|
|
border-bottom-color: #d3d3d3;
|
|
padding: 4px; margin: 0em }
|
|
div.exampleWrapper { margin: 4px }
|
|
div.exampleHeader { font-weight: bold;
|
|
margin: 4px}</style>
|
|
<link rel="stylesheet" type="text/css"
|
|
href="http://www.w3.org/StyleSheets/TR/W3C-WD.css" />
|
|
</head>
|
|
|
|
<body>
|
|
|
|
<div class="head">
|
|
<p><a href="http://www.w3.org/"><img src="http://www.w3.org/Icons/w3c_home"
|
|
alt="W3C" height="48" width="72" /></a></p>
|
|
|
|
<h1><a name="title" id="title"></a>Media Fragments URI 1.0</h1>
|
|
|
|
<h2><a name="w3c-doctype" id="w3c-doctype"></a>W3C Working Draft 17 December
|
|
2009</h2>
|
|
<dl>
|
|
<dt>This version:</dt>
|
|
<dd><a
|
|
href="http://www.w3.org/TR/2009/WD-media-frags-20091217">http://www.w3.org/TR/2009/WD-media-frags-20091217</a>
|
|
</dd>
|
|
<dt>Latest version:</dt>
|
|
<dd><a
|
|
href="http://www.w3.org/TR/media-frags">http://www.w3.org/TR/media-frags</a>
|
|
</dd>
|
|
<dt>Editors:</dt>
|
|
<dd><a href="http://www.eurecom.fr/~troncy/">Raphaël Troncy </a>, Center
|
|
for Mathematics and Computer Science (CWI Amsterdam)</dd>
|
|
<dd><a href="mailto:erik.mannens@ugent.be">Erik Mannens </a>, IBBT
|
|
Multimedia Lab, University of Ghent</dd>
|
|
<dt>Contributors:</dt>
|
|
<dd><a
|
|
href="http://www.deri.ie/about/team/member/Michael_Hausenblas/">Michael
|
|
Hausenblas </a>, DERI, National University of Ireland, Galway</dd>
|
|
<dd><a href="http://www.cwi.nl/~jack/">Jack Jansen </a>, Center for
|
|
Mathematics and Computer Science (CWI Amsterdam)</dd>
|
|
<dd><a href="http://www.w3.org/People/Lafon/">Yves Lafon </a>, W3C</dd>
|
|
<dd><a href="http://blog.gingertech.net/">Silvia Pfeiffer </a>, W3C Invited
|
|
Expert</dd>
|
|
<dd><a href="mailto:davy.vandeursen@ugent.be">Davy van Deursen </a>, IBBT
|
|
Multimedia Lab, University of Ghent</dd>
|
|
</dl>
|
|
|
|
<p class="copyright"><a
|
|
href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2009 <a
|
|
href="http://www.w3.org/"><acronym
|
|
title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a
|
|
href="http://www.csail.mit.edu/"><acronym
|
|
title="Massachusetts Institute of Technology">MIT</acronym></a>, <a
|
|
href="http://www.ercim.org/"><acronym
|
|
title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>,
|
|
<a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a
|
|
href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
|
|
<a
|
|
href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a>
|
|
and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document
|
|
use</a> rules apply.</p>
|
|
</div>
|
|
<hr />
|
|
|
|
<div>
|
|
<h2><a name="abstract" id="abstract"></a>Abstract</h2>
|
|
|
|
<p>This document describes the Media Fragments 1.0 specification. It specifies
|
|
the syntax for constructing media fragment URIs and explains how to handle them
|
|
when used over the HTTP protocol. The syntax is based on the specification of
|
|
particular field-value pairs that can be used in URI fragment and URI query
|
|
requests to restrict a media resource to a certain fragment. </p>
|
|
</div>
|
|
|
|
<div>
|
|
<h2><a name="status" id="status"></a>Status of this Document</h2>
|
|
|
|
<p><em>This section describes the status of this document at the time of its
|
|
publication. Other documents may supersede this document. A list of current W3C
|
|
publications and the latest revision of this technical report can be found in
|
|
the <a href="http://www.w3.org/TR/">W3C technical reports index</a> at
|
|
http://www.w3.org/TR/.</em></p>
|
|
|
|
<p>This is the <a
|
|
href="http://www.w3.org/2005/10/Process-20051014/tr.html#first-wd">First Public
|
|
Working Draft</a> of the Media Fragments URI 1.0 specification. It has been
|
|
produced by the <a href="http://www.w3.org/2008/WebVideo/Fragments/">Media
|
|
Fragments Working Group</a>, which is part of the <a
|
|
href="http://www.w3.org/2008/WebVideo/">W3C Video on the Web Activity</a>.</p>
|
|
|
|
<p>Please send comments about this document to <a
|
|
href="mailto:public-media-fragment@w3.org">public-media-fragment@w3.org</a>
|
|
mailing list (<a
|
|
href="http://lists.w3.org/Archives/Public/public-media-fragment/">public
|
|
archive</a>).</p>
|
|
|
|
<p>Publication as a Working Draft does not imply endorsement by the W3C
|
|
Membership. This is a draft document and may be updated, replaced or obsoleted
|
|
by other documents at any time. It is inappropriate to cite this document as
|
|
other than work in progress. </p>
|
|
|
|
<p>This document was produced by a group operating under the <a
|
|
href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 W3C
|
|
Patent Policy</a>. W3C maintains a <a rel="disclosure"
|
|
href="http://www.w3.org/2004/01/pp-impl/42785/status">public list of any patent
|
|
disclosures</a> made in connection with the deliverables of the group; that
|
|
page also includes instructions for disclosing a patent. An individual who has
|
|
actual knowledge of a patent which the individual believes contains <a
|
|
href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential
|
|
Claim(s)</a> must disclose the information in accordance with <a
|
|
href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section
|
|
6 of the W3C Patent Policy</a>. </p>
|
|
</div>
|
|
|
|
<div class="toc">
|
|
<h2><a name="contents" id="contents"></a>Table of Contents</h2>
|
|
|
|
<p class="toc">1 <a href="#introduction">Introduction</a><br />
|
|
2 <a href="#terminology">Terminology</a><br />
|
|
3 <a href="#fragment-query">URI fragment and URI query</a><br />
|
|
3.1 <a href="#URIquery-vs-fragments">When to choose URI fragments? When
|
|
to choose URI queries?</a><br />
|
|
3.2 <a href="#URIfragment-user-agent">Resolving URI fragments within
|
|
the user agent</a><br />
|
|
3.3 <a href="#URIfragment-server">Resolving URI fragments with server
|
|
help</a><br />
|
|
3.4 <a href="#URIfragment-proxies">Resolving URI fragments in a proxy
|
|
cacheable manner</a><br />
|
|
3.5 <a href="#URIquery-media-fragments">Resolving URI queries</a><br />
|
|
3.6 <a href="#URIquery-URIfragment">Combining URI fragments and URI
|
|
queries</a><br />
|
|
4 <a href="#media-fragment-syntax">Media Fragments Syntax</a><br />
|
|
4.1 <a href="#fragment-structure">General Structure</a><br />
|
|
4.2 <a href="#fragment-dimensions">Fragment Dimensions</a><br />
|
|
4.2.1 <a href="#naming-time">Temporal Dimension</a><br />
|
|
4.2.1.1 <a href="#npt-time">Normal Play Time
|
|
(NPT)</a><br />
|
|
4.2.1.2 <a href="#smpte-time">SMPTE time codes</a><br />
|
|
4.2.1.3 <a href="#clock-time">Wall-clock time
|
|
code</a><br />
|
|
4.2.2 <a href="#naming-space">Spatial Dimension</a><br />
|
|
4.2.3 <a href="#naming-track">Track Dimension</a><br />
|
|
4.2.4 <a href="#naming-name">Named Dimension</a><br />
|
|
4.3 <a href="#naming-syntax">ABNF Syntax</a><br />
|
|
5 <a href="#processing">Interpreting and Processing Media Fragments</a><br />
|
|
5.1 <a href="#processing-overview">Overview</a><br />
|
|
5.1.1 <a href="#processing-overview-standardisation">Media
|
|
Fragments Standardisation</a><br />
|
|
5.1.2 <a href="#processing-overview-interpretation">General
|
|
Interpretation</a><br />
|
|
5.1.3 <a href="#processing-overview-errors">Error
|
|
Handling</a><br />
|
|
5.2 <a href="#processing-protocol-frag">Protocol for URI fragment
|
|
Resolution in HTTP</a><br />
|
|
5.2.1 <a href="#processing-protocol-UA-mapped">UA mapped byte
|
|
ranges</a><br />
|
|
5.2.1.1 <a href="#processing-protocol-UA-mapped-new">UA
|
|
requests URI fragment for the first time</a><br />
|
|
5.2.1.2 <a
|
|
href="#processing-protocol-UA-mapped-unchanged">UA requests URI fragment it
|
|
already has buffered</a><br />
|
|
5.2.1.3 <a
|
|
href="#processing-protocol-UA-mapped-changed">UA requests URI fragment of a
|
|
changed resource</a><br />
|
|
5.2.2 <a href="#processing-protocol-Server-mapped">Server
|
|
mapped byte ranges</a><br />
|
|
5.2.3 <a href="#processing-protocol-proxy">Proxy cacheable
|
|
Server mapped byte ranges</a><br />
|
|
5.3 <a href="#processing-protocol-query">Protocol for URI query
|
|
Resolution in HTTP</a><br />
|
|
6 <a href="#Conclusions">Conclusions</a><br />
|
|
6.1 <a href="#qualification-resources">Qualification of Media
|
|
Resources</a><br />
|
|
</p>
|
|
|
|
<h3><a name="appendices" id="appendices"></a>Appendices</h3>
|
|
|
|
<p class="toc">A <a href="#references-normative">References</a><br />
|
|
B <a href="#acknowledgments">Acknowledgements</a> (Non-Normative)<br />
|
|
C <a href="#change-log">Change Log</a> (Non-Normative)<br />
|
|
</p>
|
|
</div>
|
|
<hr />
|
|
|
|
<div class="body">
|
|
|
|
<div class="div1">
|
|
<h2><a name="introduction" id="introduction"></a>1 Introduction</h2>
|
|
|
|
<p>Audio and video resources on the World Wide Web are currently treated as
|
|
"foreign" objects, which can only be embedded using a plugin that is capable of
|
|
decoding and interacting with the media resource. Specific media servers are
|
|
generally required to provide for server-side features such as direct access to
|
|
time offsets into a video without the need to retrieve the entire resource.
|
|
Support for such media fragment access varies between different media formats
|
|
and inhibits standard means of dealing with such content on the Web. </p>
|
|
|
|
<p>This specification provides for a media-format independent, standard means
|
|
of addressing media fragments on the Web using Uniform Resource Identifiers
|
|
(URI). In the context of this document, media fragments are regarded along
|
|
three different dimensions: temporal, spatial, and tracks. Further, a fragment
|
|
can be marked with a name and then addressed through a URI using that name. The
|
|
specified addressing schemes apply mainly to audio and video resources - the
|
|
spatial fragment addressing may also be used on images. </p>
|
|
|
|
<p>The aim of this specification is to enhance the Web infrastructure for
|
|
supporting the addressing and retrieval of subparts of time-based Web
|
|
resources, as well as the automated processing of such subparts for reuse.
|
|
Example uses are the sharing of such fragment URIs with friends via email, the
|
|
automated creation of such fragment URIs in a search engine interface, or the
|
|
annotation of media fragments with RDF. Such use case examples as well as other
|
|
side conditions on this specification and a survey of existing media fragment
|
|
addressing approaches are provided in the requirements <a href="#mf-req">[Use
|
|
cases and requirements for Media Fragments]</a> document that accompanies this
|
|
specification document. </p>
|
|
|
|
<p>The media fragment URIs specified in this document have been implemented and
|
|
demonstrated to work with media resources over the HTTP and RTP/RTSP protocols.
|
|
Existing media formats in their current representations and implementations
|
|
provide varying degrees of support for this specification. It is expected that
|
|
over time, media formats, media players, Web Browsers, media and Web servers,
|
|
as well as Web proxies will be extended to adhere to the full specification.
|
|
This specification will help make video a first-class citizen of the World Wide
|
|
Web. </p>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a name="terminology" id="terminology"></a>2 Terminology</h2>
|
|
|
|
<p>The keywords <strong>MUST</strong>, <strong>MUST NOT</strong>,
|
|
<strong>SHOULD</strong> and <strong>SHOULD NOT</strong> are to be interpreted
|
|
as defined in <a href="#rfc2119">[RFC 2119]</a>. </p>
|
|
|
|
<p>According to <a href="#rfc3986">[RFC 3986]</a>, URIs that contain a fragment
|
|
are actually not URIs, but URI references relative to the namespace of another
|
|
URI. In this document, when the term 'media fragment URIs' is used, it actually
|
|
means 'media fragment URI references'. </p>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a name="fragment-query" id="fragment-query"></a>3 URI fragment and URI
|
|
query</h2>
|
|
|
|
<p>To address a media fragment, one needs to find ways to convey the fragment
|
|
information. This specification builds on URIs <a href="#rfc3986">[RFC
|
|
3986]</a>. Every URI is defined as consisting of four parts, as follows: </p>
|
|
|
|
<div class="exampleOuter">
|
|
<p><scheme name> : <hierarchical part> [ ? <query> ] [ #
|
|
<fragment> ] </p>
|
|
</div>
|
|
|
|
<p>There are therefore two possibilities for representing the media fragment
|
|
addressing in URIs: the <em>URI query part</em> or the <em>URI fragment
|
|
part</em>. </p>
|
|
|
|
<div class="div2">
|
|
<h3><a name="URIquery-vs-fragments" id="URIquery-vs-fragments"></a>3.1 When to
|
|
choose URI fragments? When to choose URI queries?</h3>
|
|
|
|
<p>For media fragment addressing, both approaches - URI query and URI fragment
|
|
- are useful. </p>
|
|
|
|
<p>The main difference between a URI query and a URI fragment is that a URI
|
|
query produces a new resource, while a URI fragment provides a secondary
|
|
resource that has a relationship to the primary resource. URI fragments are
|
|
resolved from the primary resource without another retrieval action. This means
|
|
that a user agent should be capable to resolve a URI fragment on a resource it
|
|
has already received without having to fetch more data from the server. </p>
|
|
|
|
<p>A further requirement put on a URI fragment is that the media type of the
|
|
retrieved fragment should be the same as the media type of the primary
|
|
resource. Among other things, this means that a URI fragment that points to a
|
|
single video frame out of a longer video results in a one-frame video, not in a
|
|
still image. To extract a still image, one would need to create a URI query
|
|
scheme - something not envisaged here, but easy to devise. </p>
|
|
|
|
<p>There are different types of media fragment addressing in this
|
|
specification. As noted in the <a href="#mf-req">[Use cases and requirements
|
|
for Media Fragments]</a> document (section "Fitness Conditions on Media
|
|
Containers/Resources"): not all container formats and codecs are "fit" for
|
|
supporting the different types of fragment URIs. "Fitness" relates to the fact
|
|
that a media fragment can be extracted from the primary resource without syntax
|
|
element modifications or transcoding of the bitstream. </p>
|
|
|
|
<p>Resources that are "fit" can therefore be addressed with a URI fragment.
|
|
Resources that are "conditionally fit" can be addressed with a URI fragment
|
|
with an additional retrieval action that retrieves the modified syntax elements
|
|
but leaves the codec data untouched. Resources that are "unfit" require
|
|
transcoding. Such transcoded media fragments cannot be addressed with URI
|
|
fragments, but only with URI queries. </p>
|
|
|
|
<table border="1" summary="Editorial note: Raphael">
|
|
<tbody>
|
|
<tr>
|
|
<td align="left" valign="top" width="50%"><b>Editorial note:
|
|
Raphael</b></td>
|
|
<td align="right" valign="top" width="50%"> </td>
|
|
</tr>
|
|
<tr>
|
|
<td colspan="2" align="left" valign="top">I wonder if we should not paste
|
|
here the table in the Annexe B of the requirement document with the
|
|
various container formats and their "fit" value for the media fragment
|
|
dimensions considered</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<p>Therefore, when addressing a media fragment with the URI mechanism, the
|
|
author has to know whether this media fragment can be produced from the
|
|
(primary) resource itself without any transcoding activities or whether it
|
|
requires transcoding. In the latter case, the only choice is to use a URI query
|
|
and to use a server that supports transcoding and delivery of a (primary)
|
|
derivative resource to satisfy the query. </p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="URIfragment-user-agent" id="URIfragment-user-agent"></a>3.2
|
|
Resolving URI fragments within the user agent</h3>
|
|
|
|
<p>The most optimal means of using media fragments in an application is through
|
|
the use of URI fragments which the application resolves from the resource it
|
|
already holds. This is desirable since it does not require further downloads
|
|
and the user agent has the full context of the primary resource at hand. </p>
|
|
|
|
<p>An example of a URI fragment used to address a media fragment is
|
|
<code>http://www.example.org/video.ogv#t=60,100</code>. In this case, the user
|
|
agent knows that the primary resource is
|
|
<code>http://www.example.org/video.ogv</code> and that it is only expected to
|
|
display the portion of the primary resource that relates to the fragment
|
|
<code>#t=60,100</code>, i.e. seconds 60-100. Thus, the relationship between the
|
|
primary resource and the media fragment is maintained. </p>
|
|
|
|
<p>In traditional URI fragment retrieval, a user agent requests the complete
|
|
primary resource from the server and then applies the fragmentation locally. In
|
|
the media fragment case, this would result in a retrieval action on the
|
|
complete media resource, on which the user agent would then locally perform its
|
|
fragment extraction. Since media resources are typically very large, user
|
|
agents do not typically retrieve the complete media resource in one go, but
|
|
rather request byte ranges as required. This is a more economical use of
|
|
retrieval bandwidth. A user agent that knows how to map media fragments to byte
|
|
ranges will be able to satisfy a URI fragment request such as the above example
|
|
by itself. This is typically the case for user agents that know how to seek to
|
|
media fragments over the network. </p>
|
|
|
|
<p>For example, a user agent that deals with a media file that includes an
|
|
index of its seekable structures can resolve the media fragment addresses to
|
|
byte ranges from the index. This is the case e.g. with seekable QuickTime
|
|
files. Another example is a user agent that knows how to seek on a media file
|
|
through a sequence of byte range requests and eventually receives the correct
|
|
media fragment. This is the case e.g. with Ogg files in Firefox versions above
|
|
3.5. </p>
|
|
|
|
<p>If such a user agent natively supports the media fragment syntax as
|
|
specified in this document, it is deemed conformant to this specification for
|
|
fragments and for the particular dimension. </p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="URIfragment-server" id="URIfragment-server"></a>3.3 Resolving URI
|
|
fragments with server help</h3>
|
|
|
|
<p>For user agents that natively support the media fragment syntax, but have to
|
|
use their own seeking approach, this specification provides an optimisation
|
|
that can make the byte offset seeking more efficient. It requires a conformant
|
|
server with which the user agent will follow a protocol defined later in this
|
|
document. </p>
|
|
|
|
<p>In this approach, the user agent asks the server to do the byte range
|
|
mapping for the media fragment address itself and send back the appropriate
|
|
byte ranges. This can not be done through the URI, but has to be done through
|
|
adding protocol headers. User agents that interact with a conformant server to
|
|
follow this protocol will receive the appropriate byte ranges directly and will
|
|
not need to do costly seeking over the network. </p>
|
|
|
|
<p>Note that it is important that the server also informs the user agent what
|
|
actual media fragment range it was able to retrieve. This is important since in
|
|
the compressed domain it is not possible to extract data at an arbitrary
|
|
resolution, but only at the resolution that the data was packaged in. For
|
|
example, even if a user asked for
|
|
<code>http://www.example.org/video.ogv#t=60,100</code> and the user agent sent
|
|
a range request of <code>t=60,100</code> to the server, the server may only be
|
|
able to return the range <code>t=58,103</code> as the closest decodable range
|
|
that encapsulates all the required data. </p>
|
|
|
|
<p>Note that if done right, the native user agent support for media fragments
|
|
and the improved server support can be integrated without problems: the user
|
|
agent just needs to include the byte range and the media fragment range request
|
|
in one request. A server that does not understand the media fragment range
|
|
request will only react to the byte ranges, while a server that understands
|
|
them will ignore the byte range request and only reply with the correct byte
|
|
ranges. The user agent will understand from the response whether it received a
|
|
reply to the byte ranges or the media fragment ranges request and can react
|
|
accordingly. </p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="URIfragment-proxies" id="URIfragment-proxies"></a>3.4 Resolving
|
|
URI fragments in a proxy cacheable manner</h3>
|
|
|
|
<p>The current setup of the World Wide Web relies heavily on the use of caching
|
|
Web proxies to speed up the delivery of content. In the case of URI fragments
|
|
that are resolved by the server as indicated in the previous section, existing
|
|
Web proxies have no means of caching these requests since they only understand
|
|
byte ranges. </p>
|
|
|
|
<p>To make use of the existing Web proxy infrastructure of the Web, we need to
|
|
make sure that the user agent only asks for byte ranges, so they can be served
|
|
from the cache. This is possible if the server - instead of replying with the
|
|
actual data - replies with the mapped byte ranges for the requested media
|
|
fragment range. Then, the user agent is able to resend his range request this
|
|
time with bytes only, which can possibly already be satisfied from the cache.
|
|
Details of this will be specified later. </p>
|
|
|
|
<table border="1" summary="Editorial note: Raphael">
|
|
<tbody>
|
|
<tr>
|
|
<td align="left" valign="top" width="50%"><b>Editorial note:
|
|
Raphael</b></td>
|
|
<td align="right" valign="top" width="50%"> </td>
|
|
</tr>
|
|
<tr>
|
|
<td colspan="2" align="left" valign="top">Should we not foresee future
|
|
"smart" media caches that would be able to actually cache range request
|
|
in other units than bytes? </td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="URIquery-media-fragments" id="URIquery-media-fragments"></a>3.5
|
|
Resolving URI queries</h3>
|
|
|
|
<p>The described URI fragment addressing methods only work for byte-identical
|
|
segments of a media resource, since we assume a simple mapping between the
|
|
media fragment and bytes that each infrastructure element can deal with. Where
|
|
it is impossible to maintain byte-identity and some sort of transcoding of the
|
|
resource is necessary, the user agent is not able to resolve the fragmentation
|
|
by itself and a server interaction is required. In this case, URI queries have
|
|
to be used since they result in a server interaction and can deliver a
|
|
transcoded resource. </p>
|
|
|
|
<table border="1" summary="Editorial note: Raphael">
|
|
<tbody>
|
|
<tr>
|
|
<td align="left" valign="top" width="50%"><b>Editorial note:
|
|
Raphael</b></td>
|
|
<td align="right" valign="top" width="50%"> </td>
|
|
</tr>
|
|
<tr>
|
|
<td colspan="2" align="left" valign="top">Weak argument? I would rather
|
|
argue that if we cannot maintain byte-identity, then the fragment part
|
|
of a URI is simply not suitable per TAG finding that we would need to
|
|
request. The argument that the server has to do some complex processing
|
|
seems to me weaker. </td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<p>Another use for URI queries is when a user agent actually wants to receive a
|
|
completely new resource instead of just a byte range from an existing (primary)
|
|
resource. This is, for example, the case for playlists of media fragment
|
|
resources. Even if a media fragment could be resolved through a URI fragment,
|
|
the URI query may be more desirable since it does not carry with itself the
|
|
burden of the original primary resource - its file headers may be smaller, its
|
|
duration may be smaller, and it does not automatically allow access to the
|
|
remainder of the original primary resource. </p>
|
|
|
|
<p>When URI queries are used, the retrieval action has to additionally make
|
|
sure to create a fully valid new resource. For example, for the Ogg format,
|
|
this implies a reconstruction of Ogg headers to accurately describe the new
|
|
resource (e.g. a non-zero start-time or different encoding parameters). Such a
|
|
resource will be cached in Web proxies as a different resource to the original
|
|
primary resource. </p>
|
|
|
|
<p>An example URI query that includes a media fragment specification is
|
|
<code>http://www.example.org/video.ogv?t=60,100</code>. This results in a video
|
|
of duration 40s (assuming the original video was more than 100s long). </p>
|
|
|
|
<p>Note that this resource has no per-se relationship to the original primary
|
|
resource. As a user agent uses such a URI with e.g. a HTML5 video element, the
|
|
browser has no knowledge about the original resource and can only display this
|
|
video as a 40s long video starting at 0s. The context of the original resource
|
|
is lost. </p>
|
|
|
|
<p>A user agent may want to display the original start time of the resource as
|
|
the start time of the video in order to be consistent with the information in
|
|
the URI. It is possible to achieve this in one of two ways: either the video
|
|
file itself has some knowledge that it is an extract from a different file and
|
|
starts at an offset - or the user agent is told through the retrieval action
|
|
which original primary resource the retrieved resource relates to and can find
|
|
out information about it through another retrieval action. This latter option
|
|
will be regarded later in this document. </p>
|
|
|
|
<p>An example for a media resource that has knowledge about itself of the
|
|
required kind are Ogg files. Ogg files that have a skeleton track and were
|
|
created correctly from the primary resource will know that their start time is
|
|
not 0s but 60s in the above example. The browser can simply parse this
|
|
information out of the received bitstream and may display a timeline that
|
|
starts at 60s and ends at 100s in the video controls if it so desires. </p>
|
|
|
|
<p>Another option is that the browser parses the URI and knows about how media
|
|
resources have a fragment specification that follows a standard. Then the
|
|
browser can interpret the query parameters and extract the correct start and
|
|
end times and also the original primary resource. It can then also display a
|
|
timeline that starts at 60s and ends at 100s in the video controls. Further it
|
|
can allow a right-click menu to click through to the original resource if
|
|
required. </p>
|
|
|
|
<p>A use case where the video controls may neither start at 0s nor at 60s is a
|
|
mashed-up video created through a list of media fragment URIs. In such a
|
|
playlist, the user agent may prefer to display a single continuous timeline
|
|
across all the media fragments rather than a collection of individual timelines
|
|
for each fragment. Thus, the 60s to 100s fragment may e.g. be mapped to an
|
|
interval at 3min20 to 4min. </p>
|
|
|
|
<p>No new protocol headers are required to execute a URI query for media
|
|
fragment retrieval. Some optional protocol headers that improve the information
|
|
exchange will be recommended later in this document. </p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="URIquery-URIfragment" id="URIquery-URIfragment"></a>3.6 Combining
|
|
URI fragments and URI queries</h3>
|
|
|
|
<p>A combination of a URI query for a media fragment with a URI fragment yields
|
|
a URI fragment resolution on top of the newly created resource. Since a URI
|
|
with a query part creates a new resource, we have to do the fragment offset on
|
|
the new resource. This is simply a conformant behaviour to the URI standard <a
|
|
href="#rfc3986">[RFC 3986]</a>. </p>
|
|
|
|
<p>For example, <code>http://www.example.org/video.ogv?t=60,100#t=20</code>
|
|
will lead to the 20s fragment offset being applied to the new resource starting
|
|
at 60 going to 100. Thus, the reply to this is a 40s long resource whose
|
|
playback will start at an offset of 20s. </p>
|
|
|
|
<table border="1" summary="Editorial note: Silvia">
|
|
<tbody>
|
|
<tr>
|
|
<td align="left" valign="top" width="50%"><b>Editorial note:
|
|
Silvia</b></td>
|
|
<td align="right" valign="top" width="50%"> </td>
|
|
</tr>
|
|
<tr>
|
|
<td colspan="2" align="left" valign="top">We should at the end of the
|
|
document set up a table with all the different addressing types and
|
|
http headers and say what we deem is conformant and how to find out
|
|
whether a server or user agent is conformant or not. </td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a name="media-fragment-syntax" id="media-fragment-syntax"></a>4 Media
|
|
Fragments Syntax</h2>
|
|
|
|
<p>This section describes the external representation of a media fragment
|
|
specifier, and how this should be interpreted. The first two subsections are a
|
|
semi-informal introduction, with the formal grammar being specified in the last
|
|
subsection. </p>
|
|
|
|
<div class="div2">
|
|
<h3><a name="fragment-structure" id="fragment-structure"></a>4.1 General
|
|
Structure</h3>
|
|
|
|
<p>The fragment identifier consists of a list of name/value pairs, the
|
|
dimension specifiers, separated by the primary separator <code>&</code>.
|
|
Name and value are separated by an equal sign (<code>=</code>). In case value
|
|
is structured, colon (<code>:</code>) and comma (<code>,</code>) are used as
|
|
secondary separators. No whitespace is allowed (except inside strings).</p>
|
|
|
|
<p>Some examples of URIs with a media fragment, to show the general
|
|
structure:</p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>http://www.example.com/example.ogv#t=10s,20s
|
|
http://www.example.com/example.ogv#track='audio'
|
|
http://www.example.com/example.ogv#track='audio'&t=10s,20s</pre>
|
|
</div>
|
|
|
|
<p>Media fragments support fragmenting the media along four dimensions:</p>
|
|
<dl>
|
|
<dt class="label">temporal</dt>
|
|
<dd><p>This dimension denotes a specific time range in the original media,
|
|
such as "starting at second 10, continuing until second 20"; </p>
|
|
</dd>
|
|
<dt class="label">spatial</dt>
|
|
<dd><p>this dimension denotes a specific range of pixels in the original
|
|
media, such as "a rectangle with size (100,100) with its top-left at
|
|
coordinate (10,10)"; </p>
|
|
</dd>
|
|
<dt class="label">track</dt>
|
|
<dd><p>this dimension denotes one track (media type) in the original media,
|
|
such as "the english audio track"; </p>
|
|
</dd>
|
|
<dt class="label">named</dt>
|
|
<dd><p>this dimension denotes a named section of the original media, such
|
|
as "chapter 2". </p>
|
|
</dd>
|
|
</dl>
|
|
|
|
<p>Note that the track dimension refers to one of a set of parallel media
|
|
streams ("the english audio track for a video"), not to a, possibly
|
|
self-contained, section of the source media ("Audio track 2 of a CD"). The
|
|
self-contained section is handled by the name dimension. </p>
|
|
|
|
<p>The name dimension cannot be combined with other dimensions for this version
|
|
of the media fragments specification. Projection along the other three
|
|
dimensions is logically commutative, therefore they can be combined, and the
|
|
outcome is independent of the order of the dimensions. Each dimension can be
|
|
specified at most once. The name dimension cannot be combined with the other
|
|
dimensions, because the semantics depend on the underlying source media format:
|
|
some media formats support naming of temporal extents, others support naming of
|
|
groups of tracks, etc. Error semantics are discussed in <a
|
|
href="#processing-overview-errors"><b>5.1.3 Error Handling</b></a>. </p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="fragment-dimensions" id="fragment-dimensions"></a>4.2 Fragment
|
|
Dimensions</h3>
|
|
|
|
<div class="div3">
|
|
<h4><a name="naming-time" id="naming-time"></a>4.2.1 Temporal Dimension</h4>
|
|
|
|
<p>Temporal clipping is denoted by the name <code>t</code>, and specified as an
|
|
interval with a begin time and an end time (or an in-point and an out-point, in
|
|
video editing terms). Either or both may be omitted, with the begin time
|
|
defaulting to 0 seconds and the end time defaulting to the duration of the
|
|
source media. The interval is half-open: the begin time is considered part of
|
|
the interval whereas the end time is considered to be the first time point that
|
|
is not part of the interval. If a single number only is given, this is the
|
|
begin time. </p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>t=10,20 # => results in the time interval [10,20)
|
|
t=,20 # => results in the time interval [0,20)
|
|
t=10, # => results in the time interval [10,end)
|
|
t=10 # => also results in the time interval [10,end)</pre>
|
|
</div>
|
|
|
|
<p>Temporal clipping can be specified either as Normal Play Time (npt) <a
|
|
href="#rtsp">[RFC 2326]</a>, as SMPTE timecodes, <a href="#smpte">[SMPTE]</a>,
|
|
or as real-world clock time (clock) <a href="#rtsp">[RFC 2326]</a>. Begin and
|
|
end times are always specified in the same format. The format is specified by
|
|
name, followed by a colon (<code>:</code>), with <code>npt:</code> being the
|
|
default. </p>
|
|
|
|
<p>In this version of the media fragments specification there is no
|
|
extensibility mechanism to add time format specifiers. </p>
|
|
|
|
<div class="div4">
|
|
<h5><a name="npt-time" id="npt-time"></a>4.2.1.1 Normal Play Time (NPT)</h5>
|
|
|
|
<p>Normal Play Time can either be specified as seconds, with an optional
|
|
fractional part and an optional <code>s</code> to indicate seconds, or as
|
|
colon-separated hours, minutes and seconds (again with an optional fraction).
|
|
Minutes and seconds must be specified as exactly two digits, hours and
|
|
fractional seconds can be any number of digits. The hours, minutes and seconds
|
|
specification for NPT is a convenience only, it does not signal frame accuracy.
|
|
The specification of the "npt:" identifier is optional since NPT is the default
|
|
time scheme. </p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>t=npt:10s,20 # => results in the time interval [10,20)
|
|
t=npt:120s, # => results in the time interval [120,end)
|
|
t=npt:,121.5s # => results in the time interval [0,121.5)
|
|
t=0:02:00,121.5 # => results in the time interval [120,121.5)
|
|
t=npt:120,0:02:01.5 # => also results in the time interval [120,121.5)</pre>
|
|
</div>
|
|
|
|
<table border="1" summary="Editorial note: Jack">
|
|
<tbody>
|
|
<tr>
|
|
<td align="left" valign="top" width="50%"><b>Editorial note: Jack</b></td>
|
|
<td align="right" valign="top" width="50%"> </td>
|
|
</tr>
|
|
<tr>
|
|
<td colspan="2" align="left" valign="top"><p>Do we need a rationale, to
|
|
explain that we picked this syntax for timecodes up from rtsp and
|
|
smil?</p>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
|
|
<div class="div4">
|
|
<h5><a name="smpte-time" id="smpte-time"></a>4.2.1.2 SMPTE time codes</h5>
|
|
|
|
<p>SMPTE time codes are a way to address a specific frame (or field) without
|
|
running the risk of rounding errors causing a different frame to be selected.
|
|
The format is always colon-separated hours, minutes, seconds and frames. Frames
|
|
are optional, defaulting to 00. If the source format has a further subdivison
|
|
of frames (such as odd/even fields in interlaced video) these can be specified
|
|
further with a number after a dot (<code>.</code>). The SMPTE format name must
|
|
always be specified, because the interpretation of the fields depends on the
|
|
format. The SMPTE formats supported in this version of the specification are:
|
|
</p>
|
|
<ul>
|
|
<li><code>smpte</code>,</li>
|
|
<li><code>smpte-25</code>,</li>
|
|
<li><code>smpte-30</code> and </li>
|
|
<li><code>smpte-30-drop</code>.</li>
|
|
</ul>
|
|
|
|
<p><code>smpte</code> is a synonym for <code>smpte-30</code>. </p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>t=smpte-30:0:02:00,0:02:01:15 # => results in the time interval [120,121.5)
|
|
t=smpte-25:0:02:00:00,0:02:01:12.1 # => results in the time interval [120,121.5)</pre>
|
|
</div>
|
|
|
|
<p>Using SMPTE timecodes may result in frame-accurate begin and end times, but
|
|
only if the timecode format used in the media fragment specifier is the same as
|
|
that used in the original media item. </p>
|
|
</div>
|
|
|
|
<div class="div4">
|
|
<h5><a name="clock-time" id="clock-time"></a>4.2.1.3 Wall-clock time code</h5>
|
|
|
|
<p>Wall-clock time codes are a way to address real-world clock time that is
|
|
associated with a typically live video stream. These are the same time codes
|
|
that are being used by RTSP <a href="#rtsp">[RFC 2326]</a>, by SMIL <a
|
|
href="#smil30">[SMIL]</a>, and by HTML5 <a href="#html5">[HTML 5]</a>. The
|
|
scheme uses ISO 8601 UTC timestamps
|
|
(http://www.iso.org/iso/date_and_time_format). The format separates the date
|
|
from the time with a "T" character and the string ends with "Z" in the SMIL 3.0
|
|
way, which includes time zone capabilities. The time scheme identifier is
|
|
"clock". </p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>t=clock:2009-07-26T11:19:01Z,2009-07-26T11:20:01Z # => results in a 1 min interval
|
|
# on 26th Jul 2009 from 11hrs, 19min, 1sec
|
|
t=clock:2009-07-26T11:19:01Z # => starts on 26th Jul 2009 from 11hrs, 19min, 1sec
|
|
t=clock:,2009-07-26T11:20:01Z # => ends on 26th Jul 2009 from 11hrs, 20min, 1sec</pre>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a name="naming-space" id="naming-space"></a>4.2.2 Spatial Dimension</h4>
|
|
|
|
<p>Spatial clipping selects an area of pixels from visual media streams. For
|
|
this release of the media fragment specification, only rectangular selections
|
|
are supported. The rectangle can be specified as pixel coordinates or
|
|
percentages. </p>
|
|
|
|
<p>Rectangle selection is denoted by the name <code>xywh</code>. The value is
|
|
an optional format <code>pixel:</code> or <code>percent:</code> (defaulting to
|
|
pixel) and 4 comma-separated integers. The integers denote x, y, width and
|
|
height, respectively, with x=0, y=0 being the top left corner of the image. If
|
|
percent is used, x and width are interpreted as a percentage of the width of
|
|
the original media, and y and height are interpreted as a percentage of the
|
|
original height. </p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>xywh=160,120,320,240 # => results in a 320x240 box at x=160 and y=120
|
|
xywh=pixel:160,120,320,240 # => results in a 320x240 box at x=160 and y=120
|
|
xywh=percent:25,25,50,50 # => results in a 50%x50% box at x=25% and y=25%</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a name="naming-track" id="naming-track"></a>4.2.3 Track Dimension</h4>
|
|
|
|
<p>Track selection allows the extraction of a single track (audio, video,
|
|
subtitles, etc) from a media container that supports multiple tracks. Track
|
|
selection is denoted by the name <code>track</code>. The value is a string
|
|
enclosed in single quotes. Percent-escaping can be used in the string to
|
|
specify unsafe characters, see the grammar below for details. Interpretation of
|
|
the string depends on the container format of the original media: some formats
|
|
allow numbers only, some allow full names. </p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>track='1' # => results in only extracting track 1
|
|
track='video' # => results in only extracting track 'video'
|
|
track='Wide%20Angle%20Video' # => results in only extracting track 'Wide Angle Video'</pre>
|
|
</div>
|
|
|
|
<p>As the allowed track names are determined by the original source media, this
|
|
information has to be known before construction of the media fragment. There is
|
|
no support for generic media type names (audio, video) across container
|
|
formats: most container formats allow multiple tracks of each media type, which
|
|
would lead to ambiguities. </p>
|
|
|
|
<table border="1" summary="Editorial note: Jack">
|
|
<tbody>
|
|
<tr>
|
|
<td align="left" valign="top" width="50%"><b>Editorial note: Jack</b></td>
|
|
<td align="right" valign="top" width="50%"> </td>
|
|
</tr>
|
|
<tr>
|
|
<td colspan="2" align="left" valign="top"><p>The issue of generic track
|
|
names is still under discussion, <a
|
|
href="http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/4">ISSUE-4</a>
|
|
in the tracker has the details. </p>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a name="naming-name" id="naming-name"></a>4.2.4 Named Dimension</h4>
|
|
|
|
<p>Name-based selection is denoted by the name <code>id</code>, with the value
|
|
being a string enclosed in single quotes. Percent-escaping can be used in the
|
|
string to include unsafe characters such as single quote, see the grammer below
|
|
for details. Interpretation of the string depends on the underlying container
|
|
format: some container formats support named chapters or numbered chapters
|
|
(leading to temporal clipping), some may support naming of groups of tracks or
|
|
other objects. As with track selection, determining which names are valid
|
|
requires knowledge of the original media item. </p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>id='1' # => results in only extracting the section called '1'
|
|
id='chapter-1' # => results in only extracting the section called 'chapter-1'
|
|
id='Airline%20Edit' # => results in only extracting the section called 'Airline Edit'</pre>
|
|
</div>
|
|
|
|
<p>Note that, despite the use of the name <code>id</code>, there is no
|
|
correspondence to XML <code>id</code>: the values are uninterpreted strings,
|
|
from the point of view of media fragment handling. </p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="naming-syntax" id="naming-syntax"></a>4.3 ABNF Syntax</h3>
|
|
|
|
<p>The composition of a URI fragment or query string for a media resource
|
|
relies on a series of field-value pairs to be added behind the URI fragment
|
|
('#') or query ('?') identifier. The field-value pairs are each separated by an
|
|
equal sign. The series of pairs is separated by an ampersand, '&' or
|
|
semicolon, ';'.</p>
|
|
|
|
<p>A general URI fragment or query string specified on a media resource may
|
|
contain several field-value pairs. They are not restricted to the ones
|
|
specified here, since applications may want to use additional other parameters
|
|
to communicate further requests to custom servers. A conformant server or user
|
|
agent will need to be able to parse a random URI query or fragment string for a
|
|
media resource and identify the relevant parts. E.g. the relevant field-value
|
|
pair out of a media fragment URI like this
|
|
<code>http://www.example.com/video.ogv#&&=&=tom;jerry=&t=34&t=meow:0#</code>
|
|
is <code>t=34</code>.</p>
|
|
|
|
<p>In this section we present the ABNF (<a href="#abnf">[ABNF]</a>) syntax for
|
|
the field-value pairs that relate to a media fragment URI. The names for the
|
|
non-terminals more-or-less follow the names used in the previous subsections,
|
|
with one clear difference: the start symbol is called
|
|
<code>mediasegment</code>, because we want to allow application of it to both
|
|
URI fragment and URI query strings.</p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>segment = mediasegment / *( pchar / "/" / "?" ) ; augmented fragment
|
|
; definition taken from
|
|
; rfc3986
|
|
;
|
|
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Media Segment ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
|
|
;
|
|
mediasegment = namesegment / axissegment
|
|
axissegment = ( timesegment / spacesegment / tracksegment )
|
|
*( "&" ( timesegment / spacesegment / tracksegment )
|
|
;
|
|
; note that this does not capture the restriction to one kind of fragment
|
|
; in the axisfragment definition, unless we list explicitely the 14 cases.
|
|
;
|
|
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Time Segment ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
|
|
;
|
|
timesegment = timeprefix "=" timeparam
|
|
timeprefix = %x74 ; "t"
|
|
timeparam = npttimedef / smptetimedef / clocktimedef
|
|
npttimedef = [ deftimeformat ":"] ( npttime [ "," npttime ] ) / ( "," npttime )
|
|
smptetimedef = smpteformat ":"( frametime [ "," frametime ] ) / ( "," frametime )
|
|
clocktimedef = clockformat ":"( clocktimetime [ "," clocktime ] ) / ( "," clocktime )
|
|
deftimeformat = %x6E.70.74 ; "npt"
|
|
smpteformat = %x73.6D.70.74.65 ; "smpte"
|
|
/ %x73.6D.70.74.65.2D.32.35 ; "smpte-25"
|
|
/ %x73.6D.70.74.65.2D.33.30 ; "smpte-30"
|
|
/ %x73.6D.70.74.65.2D.33.30.2D.64.72.6F.70 ; "smpte-30-drop"
|
|
clockformat = %x63.6C.6F.63.6B ; "clock"
|
|
timeunit = %x73 ; "s"
|
|
npttime = ( 1*DIGIT [ "." 1*DIGIT ] [timeunit] ) /
|
|
( 1*DIGIT ":" 2DIGIT ":" 2DIGIT [ "." 1*DIGIT] )
|
|
frametime = 1*DIGIT ":" 2DIGIT ":" 2DIGIT [ ":" 2DIGIT [ "." 2DIGIT ] ]
|
|
clocktime = (datetime / walltime / date)
|
|
datetime = date "T" walltime
|
|
date = years "-" months "-" days
|
|
walltime = (HHMM / HHMMSS) tzd
|
|
HHMM = hours24 ":" minutes
|
|
HHMMSS = hours24 ":" minutes ":" seconds ["." fraction]
|
|
years = 4DIGIT
|
|
months = 2DIGIT ; range from 01 to 12
|
|
days = 2DIGIT ; range from 01 to 31
|
|
hours24 = 2DIGIT ; range from 00 to 23
|
|
minutes = 2DIGIT ; range from 00 to 59
|
|
seconds = 2DIGIT ; range from 00 to 59
|
|
fraction = DIGIT+
|
|
tzd = "Z" / (("+" / "-") hours24 ":" minutes )
|
|
;
|
|
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Space Segment ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
|
|
;
|
|
spacesegment = xywhdef
|
|
xywhdef = xywhprefix "=" xywhparam
|
|
xywhprefix = %x78.79.77.68 ; "xywh"
|
|
xywhparam = [ xywhunit ":" ] 1*DIGIT "," 1*DIGIT "," 1*DIGIT "," 1*DIGIT
|
|
xywhunit = %x70.69.78.65.6C ; "pixel"
|
|
/ %x70.65.72.63.65.6E.74 ; "percent"
|
|
;
|
|
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Track Segment ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
|
|
;
|
|
tracksegment = trackprefix "=" trackparam
|
|
trackprefix = %x74.72.61.63.6B ; "track"
|
|
trackparam = utf8string
|
|
;
|
|
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Name Segment ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
|
|
;
|
|
namesegment = nameprefix "=" nameparam
|
|
nameprefix = %x69.64 ; "id"
|
|
nameparam = utf8string
|
|
;
|
|
;;;;;;;;;;;;;;;;;;;;;;;;;;;; Imported definitions ;;;;;;;;;;;;;;;;;;;;;;;;;;;;
|
|
;
|
|
DIGIT = <DIGIT, defined in rfc4234#3.4>
|
|
pchar = <pchar, defined in rfc3986>
|
|
unreserved = <unreserved, defined in rfc3986>
|
|
pct-encoded = <pct-encoded, defined in rfc3986>
|
|
utf8string = "'" *( unreserved / pct-encoded ) "'" ; utf-8 character
|
|
; encoded URI-style</pre>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a name="processing" id="processing"></a>5 Interpreting and Processing
|
|
Media Fragments</h2>
|
|
|
|
<p>There are many open questions about how to resolve a media fragment URI that
|
|
are not being answered simply from the specification of the syntax. An
|
|
implementer will need to know all of these. This starts with issues around
|
|
standardisation and uptake, followed by issues of interpretation of the syntax,
|
|
followed by concrete protocol exchange scenarios for the different situations
|
|
explained above in section <a href="#fragment-query"><b>3 URI fragment and URI
|
|
query</b></a>. </p>
|
|
|
|
<table border="1" summary="Editorial note: Silvia">
|
|
<tbody>
|
|
<tr>
|
|
<td align="left" valign="top" width="50%"><b>Editorial note:
|
|
Silvia</b></td>
|
|
<td align="right" valign="top" width="50%"> </td>
|
|
</tr>
|
|
<tr>
|
|
<td colspan="2" align="left" valign="top"><p>NOTE to implementers: if you
|
|
come across some not yet mentioned here, please email to
|
|
public-media-fragment@w3.org. </p>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<div class="div2">
|
|
<h3><a name="processing-overview" id="processing-overview"></a>5.1 Overview</h3>
|
|
|
|
<div class="div3">
|
|
<h4><a name="processing-overview-standardisation"
|
|
id="processing-overview-standardisation"></a>5.1.1 Media Fragments
|
|
Standardisation</h4>
|
|
|
|
<p>When we talk about semantics of fragment identifiers in URIs, we need to
|
|
start with RFC3986, section <a href="#URIquery-media-fragments"><b>3.5
|
|
Resolving URI queries</b></a> . We note that, wherever fragments are not
|
|
defined in the respective media type registration, the general rule from
|
|
RFC3986, as stated above, applies. For the current IETF/IANA registration
|
|
process and requirements see RFC4288. Note that regarding fragments, as stated
|
|
in sec 4.11 of RFC4288, there is only a SHOULD-requirement. Most media types
|
|
are expected not to specify fragments and their semantics, see also review of
|
|
media types regarding fragment identifiers. </p>
|
|
|
|
<p>The Media Fragment WG has no authority to update registries of all targeted
|
|
media types. To the best of our knowledge there are only few media types that
|
|
actually have a registered fragment specification, including Ogg, MPEG-4, and
|
|
MPEG-21. For all others, the semantics of the fragment are considered to be
|
|
unknown. The media fragment specification to be defined through the Media
|
|
Fragment WG will be a recommendation to media type owners. We recommend to
|
|
update or add the fragment semantics specification to their media type
|
|
registration once a generic scheme has been determined. At minimum, those
|
|
schemes that have an existing, diverging fragment specification should be
|
|
harmonized. To achieve uptake of the scheme, updates to the server and client
|
|
software for the different media types will be required. </p>
|
|
|
|
<table border="1" summary="Editorial note: Silvia">
|
|
<tbody>
|
|
<tr>
|
|
<td align="left" valign="top" width="50%"><b>Editorial note:
|
|
Silvia</b></td>
|
|
<td align="right" valign="top" width="50%"> </td>
|
|
</tr>
|
|
<tr>
|
|
<td colspan="2" align="left" valign="top"><p>See also the <a
|
|
href="http://www.w3.org/2008/WebVideo/Fragments/wiki/MediaTypeReview">review</a>.
|
|
</p>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a name="processing-overview-interpretation"
|
|
id="processing-overview-interpretation"></a>5.1.2 General Interpretation</h4>
|
|
|
|
<p>This is a list of hints to implementers on how to interpret media fragment
|
|
URIs. There is no particular order to them.</p>
|
|
|
|
<p><em>Media type:</em> The media type of a resource retrieved through a URI
|
|
fragment request is the same as that of the primary resource. Thus, retrieval
|
|
of e.g. a single frame from a video will result in a one-frame-long video. Or,
|
|
retrieval of all the audio tracks from a video resource will result in a video
|
|
and not a audio resource. When using a URI query approach, media type changes
|
|
are possible. E.g. a spatial fragment from a video at a certain time offset
|
|
could be retrieved as a jpeg using a specific HTTP "Accept" header in the
|
|
request. </p>
|
|
|
|
<p><em>Synchronisation:</em> Synchronisation between different tracks of a
|
|
media resource needs to be maintained when retrieving media fragments of that
|
|
resource. This is true for both, URI fragment and URI query retrieval. With URI
|
|
queries, when transcoding is required, a non-perceivable change in the
|
|
synchronisation is acceptable.</p>
|
|
|
|
<p><em>Embedded Timecodes:</em> When a media resource contains embedded time
|
|
codes, these need to be maintained for media fragment retrieval, in particular
|
|
when the URI fragment method is used. When URI queries are used and transcoding
|
|
takes place, the embedded time codes should remain when they are useful and
|
|
required.</p>
|
|
|
|
<p><em>Resolution Order:</em> Where multiple dimensions are combined in one URI
|
|
fragment request, implementations are expected to first do track and temporal
|
|
selection on the container level, and then do spatial clipping on the codec
|
|
level. Named selection is done for whatever the name stands for: a track, a
|
|
temporal section, or a spatial region. </p>
|
|
|
|
<p><em>Reasonable Byte Clipping:</em> A media fragment that is retrieved using
|
|
URI fragment requests needs to be implementable without transcoding solely
|
|
based on byte ranges. Temporal or spatial clipping needs to be as close as
|
|
reasonably possible to what the media fragment specified. "Reasonably close"
|
|
means the nearest compression entity to the requested fragment that completely
|
|
contains the requested fragment. This means, e.g. for temporal fragments if a
|
|
request is made for <code>http://www.example.org/video.ogv#t=60,100</code>, but
|
|
the closest decodable range is <code>t=58,102</code> because this is where a
|
|
packet boundary lies for audio and video, then it will be this range that is
|
|
returned. Similarly for spatial ranges. The UA is then capable of displaying
|
|
only the requested subpart, and should also just do that. For some container
|
|
formats this is a non-issue, because the container format allows specification
|
|
of logical begin and end. </p>
|
|
|
|
<p><em>External Clipping:</em> There is no obligatory resolution method for a
|
|
situation where a media fragment URI is being used in the context of another
|
|
clipping method. Formally, it is up to the context embedding the media fragment
|
|
URI to decide whether the outside clipping method overrides the media fragment
|
|
URI or cascades, i.e. is defined on the resulting resource. In the absence of
|
|
strong reasons to do otherwise we suggest cascading. An example is a SMIL
|
|
element as follows: <code><smil:video clipBegin="5" clipEnd="15"
|
|
src="http://www.example.com/example.mp4#t=100,200"/></code>. This should
|
|
start playback of the original media resource at second 105, and stop at 115.
|
|
</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a name="processing-overview-errors"
|
|
id="processing-overview-errors"></a>5.1.3 Error Handling</h4>
|
|
|
|
<p>There are a large number of error situations possible. This section
|
|
describes what to do in each case.</p>
|
|
|
|
<p><em>Non-existent dimension:</em> Attempting to do fragment selection on a
|
|
dimension that does not exist in the source media, such as temporal clipping on
|
|
a still image or spatial clipping on an audio file, should be considered a
|
|
no-op and not throw an error. </p>
|
|
|
|
<p><em>Over-specified Dimension:</em> If a dimension (temporal, spatial, track)
|
|
is used multiple times, only the last occurrence is considered. For example,
|
|
<code>http://www.example.com/video.orgv#t=10&t=20</code> will lead to the
|
|
same result as <code>http://www.example.com/video.orgv#t=20</code>. </p>
|
|
|
|
<table border="1" summary="Editorial note: Jack">
|
|
<tbody>
|
|
<tr>
|
|
<td align="left" valign="top" width="50%"><b>Editorial note: Jack</b></td>
|
|
<td align="right" valign="top" width="50%"> </td>
|
|
</tr>
|
|
<tr>
|
|
<td colspan="2" align="left" valign="top"><p>It is still a contentious
|
|
issue whether an over-specified dimension should be an error or not in
|
|
the group. Feedback is requested. </p>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<p><em>Under-specified Dimension:</em> The result of doing spatial clipping on
|
|
a media resource that has multiple video tracks is undefined if no track
|
|
selection is also applied.</p>
|
|
|
|
<table border="1" summary="Editorial note: Michael">
|
|
<tbody>
|
|
<tr>
|
|
<td align="left" valign="top" width="50%"><b>Editorial note:
|
|
Michael</b></td>
|
|
<td align="right" valign="top" width="50%"> </td>
|
|
</tr>
|
|
<tr>
|
|
<td colspan="2" align="left" valign="top"><p>We need to define more error
|
|
semantics. Some areas:</p>
|
|
<ol class="enumar">
|
|
<li><p>Nonexistent (t= with begin and end past end-of-media, unknown
|
|
id, unknown track)</p>
|
|
</li>
|
|
<li><p>Partially existent (t= with end past EOM, xywh spec that
|
|
extends past bounds): could be clipped to the actual size of the
|
|
resource</p>
|
|
</li>
|
|
<li><p>Non-existent that can be determined statically, for example
|
|
t=20,10</p>
|
|
</li>
|
|
<li><p>Incompatible: if the named dimension is used, all the other
|
|
dimensions are ignored. Alternatively: this is an error.</p>
|
|
</li>
|
|
</ol>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="processing-protocol-frag" id="processing-protocol-frag"></a>5.2
|
|
Protocol for URI fragment Resolution in HTTP</h3>
|
|
|
|
<p>This section defines what protocol steps are necessary in HTTP <a
|
|
href="#rfc2616">[RFC 2616]</a> to resolve and deliver a media fragment
|
|
specified as a URI fragment.</p>
|
|
|
|
<table border="1" summary="Editorial note: Silvia">
|
|
<tbody>
|
|
<tr>
|
|
<td align="left" valign="top" width="50%"><b>Editorial note:
|
|
Silvia</b></td>
|
|
<td align="right" valign="top" width="50%"> </td>
|
|
</tr>
|
|
<tr>
|
|
<td colspan="2" align="left" valign="top"><p>We could do RTSP as well, as
|
|
mentioned earlier.</p>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<div class="div3">
|
|
<h4><a name="processing-protocol-UA-mapped"
|
|
id="processing-protocol-UA-mapped"></a>5.2.1 UA mapped byte ranges</h4>
|
|
|
|
<p>As described in section <a href="#URIfragment-user-agent"><b>3.2 Resolving
|
|
URI fragments within the user agent</b></a>, the most optimal case is a user
|
|
agent that knows how to map media fragments to byte ranges. In this case, the
|
|
HTTP exchanges are exactly the same as for any other Web resource where byte
|
|
ranges are requested <a href="#rfc2616">[RFC 2616]</a>. </p>
|
|
|
|
<p>For completeness reasons, here are the three cases a media fragment enabled
|
|
UA and a media Server will encounter:</p>
|
|
|
|
<div class="div4">
|
|
<h5><a name="processing-protocol-UA-mapped-new"
|
|
id="processing-protocol-UA-mapped-new"></a>5.2.1.1 UA requests URI fragment for
|
|
the first time</h5>
|
|
|
|
<p>A user requests a media fragment URI:</p>
|
|
<ul>
|
|
<li><p>User → UA (1):</p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>http://www.example.com/video.ogv#t=10,20</pre>
|
|
</div>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>The UA has to check if a local copy of the requested fragment is available
|
|
in its buffer - not in this case. But it knows how to map the fragment to byte
|
|
ranges: 19147 - 22890. So, it requests these byte ranges from the server:</p>
|
|
<ul>
|
|
<li><p>UA (1) → Proxy (2) → Origin Server (3):</p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>GET /video.ogv HTTP/1.1
|
|
Host: www.example.com
|
|
Accept: video/*
|
|
Range: bytes=19147-22890</pre>
|
|
</div>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>The server extracts the bytes corresponding to the requested range and
|
|
replies in a 206 HTTP response:</p>
|
|
<ul>
|
|
<li><p>Origin Server (3) → Proxy (4) → UA (5):</p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>HTTP/1.1 206 Partial Content
|
|
Accept-Ranges: bytes
|
|
Content-Length: 3743
|
|
Content-Type: video/ogg
|
|
Content-Range: bytes 19147-22880/35614993
|
|
Etag: "b7a60-21f7111-46f3219476580"
|
|
|
|
{binary data}</pre>
|
|
</div>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>Assuming the UA has received the byte ranges that it requires to serve
|
|
t=10,20, which may well be slightly more, it will serve the decoded content to
|
|
the User from the appropriate time offset. Otherwise it may keep requesting
|
|
byte ranges to retrieve the required time segments.</p>
|
|
</div>
|
|
|
|
<div class="div4">
|
|
<h5><a name="processing-protocol-UA-mapped-unchanged"
|
|
id="processing-protocol-UA-mapped-unchanged"></a>5.2.1.2 UA requests URI
|
|
fragment it already has buffered</h5>
|
|
|
|
<p>A user requests a media fragment URI:</p>
|
|
<ul>
|
|
<li><p>User → UA (1):</p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>http://www.example.com/video.ogv#t=10,20</pre>
|
|
</div>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>The UA has to check if a local copy of the requested fragment is available
|
|
in its buffer - it is in this case. But the resource could have changed on the
|
|
server, so it needs to send a conditional GET. It knows the byte ranges: 19147
|
|
- 22890. So, it requests these byte ranges from the server under condition of
|
|
it having changed:</p>
|
|
<ul>
|
|
<li><p>UA (1) → Proxy (2) → Origin Server (3):</p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>GET /video.ogv HTTP/1.1
|
|
Host: www.example.com
|
|
Accept: video/*
|
|
If-Modified-Since: Sat, 01 Aug 2009 09:34:22 GMT
|
|
If-None-Match: "b7a60-21f7111-46f3219476580"
|
|
Range: bytes=19147-22890</pre>
|
|
</div>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>The server checks if the resource has changed by checking the date - in this
|
|
case, the resource was not modified. So, the server replies with a 304 HTTP
|
|
response. (Note that a If-Range header cannot be used, because if the entity
|
|
has changed, the entire resource would be sent.)</p>
|
|
<ul>
|
|
<li><p>Origin Server (3) → Proxy (4) → UA (5):</p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>HTTP/1.1 304 Not Modified
|
|
Accept-Ranges: bytes
|
|
Content-Length: 3743
|
|
Content-Type: video/ogg
|
|
Content-Range: bytes 19147-22880/35614993
|
|
Etag: "b7a60-21f7111-46f3219476580"</pre>
|
|
</div>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>So, the UA serves the decoded resource to the User our of its existing
|
|
buffer.</p>
|
|
</div>
|
|
|
|
<div class="div4">
|
|
<h5><a name="processing-protocol-UA-mapped-changed"
|
|
id="processing-protocol-UA-mapped-changed"></a>5.2.1.3 UA requests URI fragment
|
|
of a changed resource</h5>
|
|
|
|
<p>A user requests a media fragment URI and the UA sends the exact same GET
|
|
request as described in the previous subsection.</p>
|
|
|
|
<p>This time, the server checks if the resource has changed by checking the
|
|
date and it has been modified. Since the byte mapping may not be correct any
|
|
longer, the server can only tell the UA that the resource has changed and leave
|
|
all further actions to the UA. So, it sends a 412 HTTP response:</p>
|
|
<ul>
|
|
<li><p>Origin Server (3) → Proxy (4) → UA (5):</p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>HTTP/1.1 412 Precondition Failed
|
|
Accept-Ranges: bytes
|
|
Content-Length: 3743
|
|
Content-Type: video/ogg
|
|
Content-Range: bytes 19147-22880/22222222
|
|
Etag: "xxxxx-yyyyyyy-zzzzzzzzzzzzz"</pre>
|
|
</div>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>So, the UA can only assume the resource has changed and re-retrieve what it
|
|
needs to get back to being able to retrieve fragments. For most resources this
|
|
may mean retrieving the header of the file. After this it is possible again to
|
|
do a byte range retrieval.</p>
|
|
</div>
|
|
|
|
<table border="1" summary="Editorial note: Silvia">
|
|
<tbody>
|
|
<tr>
|
|
<td align="left" valign="top" width="50%"><b>Editorial note:
|
|
Silvia</b></td>
|
|
<td align="right" valign="top" width="50%"> </td>
|
|
</tr>
|
|
<tr>
|
|
<td colspan="2" align="left" valign="top"><p>Somebody could create
|
|
time-sequence diagrams for the protocol action. </p>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a name="processing-protocol-Server-mapped"
|
|
id="processing-protocol-Server-mapped"></a>5.2.2 Server mapped byte ranges</h4>
|
|
|
|
<p>As described in section <a href="#URIfragment-server"><b>3.3 Resolving URI
|
|
fragments with server help</b></a>, some User Agents cannot undertake the
|
|
framgent-to-byte mapping themselves, because the mapping is not obvious. In
|
|
this case, the HTTP request of the User Agent will include the fragment hoping
|
|
that the server can do the byte range mapping itself and send back the
|
|
appropriate byte ranges.</p>
|
|
|
|
<p>We'll go through the protocol exchange action step by step. It starts with a
|
|
user's request for a media fragment URI:</p>
|
|
<ul>
|
|
<li><p>User → UA (1):</p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>http://www.example.com/video.ogv#t=10,20</pre>
|
|
</div>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>The UA has to check if a local copy of the requested fragment is available
|
|
in its buffer. If it is, we revert back to the processing described in sections
|
|
<a href="#processing-protocol-UA-mapped-unchanged"><b>5.2.1.2 UA requests URI
|
|
fragment it already has buffered</b></a> and <a
|
|
href="#processing-protocol-UA-mapped-changed"><b>5.2.1.3 UA requests URI
|
|
fragment of a changed resource</b></a>, since the UA already knows the mapping
|
|
to byte ranges.</p>
|
|
|
|
<p>When the UA doesn't know how to map time to bytes, it tries requesting this
|
|
time range from the server:</p>
|
|
<ul>
|
|
<li><p>UA (1) → Proxy (2) → Origin Server (3):</p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>GET /video.ogv HTTP/1.1
|
|
Host: www.example.com
|
|
Accept: video/*
|
|
Range: t:npt=10-20</pre>
|
|
</div>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>The example shows a temporal Range request, which introduces the "t"
|
|
dimension and the "npt" unit. The specification for all new Range dimensions is
|
|
given through:</p>
|
|
<ul>
|
|
<li><p><em>temporal:</em> t:<unit>=<start> - <end></p>
|
|
</li>
|
|
<li><p><em>spatial:</em>
|
|
xywh:<unit>=<topleftx>,<toplefty>,<width>,<height></p>
|
|
</li>
|
|
<li><p><em>track:</em> track=<trackname></p>
|
|
</li>
|
|
<li><p><em>name:</em> id=<name></p>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>The unit is not optional. It can be "npt", "smpte", "smpte-25", "smpte-30",
|
|
"smpte-30-drop" or "clock" for temporal and "pixel" or "percent" for spatial.
|
|
Where "ntp" is used for a temporal Range, only specification in seconds is
|
|
possible without the "s". Where "clocktime" is used for a temporal Range, only
|
|
"datetime" is possible and "walltime" is fully specified in HHMMSS with
|
|
fraction and full timezone. Indeed, all optional elements in the URI
|
|
specification become required in the Range header.</p>
|
|
|
|
<table border="1" summary="Editorial note: Silvia">
|
|
<tbody>
|
|
<tr>
|
|
<td align="left" valign="top" width="50%"><b>Editorial note:
|
|
Silvia</b></td>
|
|
<td align="right" valign="top" width="50%"> </td>
|
|
</tr>
|
|
<tr>
|
|
<td colspan="2" align="left" valign="top"><p>Somebody should create an
|
|
ABNF for these new Range dimensions. </p>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<p>If the server doesn't understand a Range header, it MUST ignore the header
|
|
field that includes that range-set. This is in sync to the HTTP RFC <a
|
|
href="#rfc2616">[RFC 2616]</a>. This means that where a server doesn't support
|
|
media fragments, the complete resource will be delivered. It also means that we
|
|
can combine both, byte range and fragment range headers in one request, since
|
|
the server will only react to the Range header it understands.</p>
|
|
|
|
<p>Assuming the server can map the given Range to one or more byte ranges, it
|
|
will reply with these in a 206 HTTP response. Where multiple byte ranges are
|
|
required to satisfy the Range request, these are transmitted as a multipart
|
|
message-body. The media type for this purpose is called "multipart/byteranges".
|
|
This is in sync with the HTTP RFC <a href="#rfc2616">[RFC 2616]</a>.</p>
|
|
|
|
<p>Here is the reply to the example above, assuming a single byte range is
|
|
sufficient:</p>
|
|
<ul>
|
|
<li><p>Origin Server (3) → Proxy (4) → UA (5):</p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>HTTP/1.1 206 Partial Content
|
|
Accept-Ranges: bytes, t, xywh, track, id
|
|
Content-Length: 3743
|
|
Content-Type: video/ogg
|
|
Content-Range: bytes 19147-22880/35614993
|
|
Content-Range: t:npt 11.85-21.16/653.791
|
|
Etag: "b7a60-21f7111-46f3219476580"
|
|
|
|
{binary data}</pre>
|
|
</div>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>Note that in comparison to the specification in the request Range header,
|
|
the reply Content-Range header also adds the instance-length after a slash "/"
|
|
character. Also note that through the extended list in the Accept-Ranges it is
|
|
possible to identify which fragment schemes a server supports.</p>
|
|
<ul>
|
|
<li><p><em>temporal:</em> t:<unit>=<start> -
|
|
<end>/<duration></p>
|
|
</li>
|
|
<li><p><em>spatial:</em>
|
|
xywh:<unit>=<topleftx>,<toplefty>,<width>,<height>/<total_width>,<total_height></p>
|
|
</li>
|
|
<li><p><em>track:</em>
|
|
track=<trackname1>[,<trackname2>]*/<duration></p>
|
|
</li>
|
|
<li><p><em>name:</em> id=<name>/*</p>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>For temporal it is the total duration in seconds, for spatial the total
|
|
width and height dimension, for track again the total duration in seconds, for
|
|
id just "*" since it could be any of the other dimensions.</p>
|
|
|
|
<p>Also note that, as we return both, byte and temporal ranges, the UA and any
|
|
intermediate caching proxy is enabled to map byte positions with time offsets
|
|
and fall back to byte range request where the fragment is re-requested.</p>
|
|
|
|
<p>In the case where a media fragment results in a multipart message-body, the
|
|
bytes Content-Range headers will be spread throughout the binary data ranges,
|
|
but the Content-Range of the media fragment will only be with the main header.
|
|
For example:</p>
|
|
<ul>
|
|
<li><p>Origin Server (3) → Proxy (4) → UA (5):</p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>HTTP/1.1 206 Partial Content
|
|
Accept-Ranges: bytes, t, xywh, track, id
|
|
Content-Length: 3743
|
|
Content-Type: video/ogg
|
|
Content-Range: track audio1,video1/653.791
|
|
Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
|
|
Etag: "b7a60-21f7111-46f3219476580"
|
|
|
|
--THIS_STRING_SEPARATES
|
|
Content-type: video/ogg
|
|
Content-Range: bytes 123-2589/35614993
|
|
{binary data}
|
|
--THIS_STRING_SEPARATES
|
|
Content-type: video/ogg
|
|
Content-Range: bytes 14560-27891/35614993
|
|
{binary data}
|
|
--THIS_STRING_SEPARATES
|
|
Content-type: video/ogg
|
|
Content-Range: bytes 58909-81230/35614993
|
|
{binary data}
|
|
--THIS_STRING_SEPARATES--</pre>
|
|
</div>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>Note that a caching proxy that does not understand a Range header must not
|
|
cache "206 Partial Content" responses as per HTTP RFC <a href="#rfc2616">[RFC
|
|
2616]</a>. Thus, the new Range requests won't be cached by legacy Web
|
|
proxies.</p>
|
|
|
|
<table border="1" summary="Editorial note: Silvia">
|
|
<tbody>
|
|
<tr>
|
|
<td align="left" valign="top" width="50%"><b>Editorial note:
|
|
Silvia</b></td>
|
|
<td align="right" valign="top" width="50%"> </td>
|
|
</tr>
|
|
<tr>
|
|
<td colspan="2" align="left" valign="top"><p>Need to discuss if two
|
|
Content-Range headers are ok and solve our cacheability problems. Or if
|
|
we need to invent a new header name (Conrad's "Fragment:") for
|
|
delivering the mapping. It is important for the UA, but also for the
|
|
caching proxy, that may be media enabled and thus know what to do with
|
|
it.</p>
|
|
|
|
<p>Further, there is discussion in the group still whether "track" and
|
|
"id" dimension can actually be handled in the same way as temporal and
|
|
spatial, see <a
|
|
href="http://www.w3.org/2008/WebVideo/Fragments/wiki/Server-parsed_Fragments">Conrad's
|
|
Fragment proposal</a>.</p>
|
|
|
|
<p>Also should specify the ABNF for the Content-Range header.</p>
|
|
|
|
<p>And somebody should paint time-sequence diagrams for the protocol
|
|
action - or update the existing ones to match with the description
|
|
here.</p>
|
|
|
|
<p>Further note that we may want to specify a list of track names and
|
|
not just one - isn't yet done in the ABNF for the media fragment URIs
|
|
above.</p>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a name="processing-protocol-proxy"
|
|
id="processing-protocol-proxy"></a>5.2.3 Proxy cacheable Server mapped byte
|
|
ranges</h4>
|
|
|
|
<p>As described in section <a href="#URIfragment-proxies"><b>3.4 Resolving URI
|
|
fragments in a proxy cacheable manner</b></a>, the server mapped byte ranges
|
|
approach can be extended to play with existing caching Web proxy
|
|
infrastructure. This is important, since video is a huge bandwidth eater in the
|
|
current Internet and falling back to using existing Web proxy infrastructure is
|
|
important, particularly since progressive download and direct access mechanisms
|
|
for video rely heavily on this functionality. Over time, the proxy
|
|
infrastructure will learn how to cache media fragment URIs directly as
|
|
described in the previous section and then will not require this extra
|
|
effort.</p>
|
|
|
|
<p>To enable media-fragment-URI-supporting UAs to make their retrieval
|
|
cachable, we introduce some extra HTTP headers, which will help tell the server
|
|
and the proxy what to do.</p>
|
|
|
|
<p>Let's play it through on an example. A user requests a media fragment URI:
|
|
</p>
|
|
<ul>
|
|
<li><p>User → UA (1):</p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>http://www.example.com/video.ogv#t=10,20</pre>
|
|
</div>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>The UA has to check if a local copy of the requested fragment is available
|
|
in its buffer. In our case here, it is not. If it was, we would revert back to
|
|
the processing described in sections <a
|
|
href="#processing-protocol-UA-mapped-unchanged"><b>5.2.1.2 UA requests URI
|
|
fragment it already has buffered</b></a> and <a
|
|
href="#processing-protocol-UA-mapped-changed"><b>5.2.1.3 UA requests URI
|
|
fragment of a changed resource</b></a>, since the UA already knows the mapping
|
|
to byte ranges. The UA issues a HTTP GET request with the fragment and
|
|
requesting to retrieve just the mapping to byte ranges:</p>
|
|
<ul>
|
|
<li><p>UA (1) → Proxy (2) → Origin Server (3):</p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>GET /video.ogv HTTP/1.1
|
|
Host: www.example.com
|
|
Accept: video/*
|
|
Range: t:npt=10-20
|
|
Accept-Range-Redirect: bytes</pre>
|
|
</div>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>The server converts the given time range to a byte range and sends an empty
|
|
reply that refers the UA to the right byte range for the correct time range.
|
|
The message body of this answer contains the control section of
|
|
fragf2f.mp4#12,21 (if required). </p>
|
|
<ul>
|
|
<li><p>Origin Server (3) → Proxy (4) → UA (5):</p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>HTTP/1.1 307 Temporary Redirect
|
|
Location: http://www.example.com/video.ogv
|
|
Accept-Ranges: bytes, t, xywh, track, id
|
|
Content-Length: 0
|
|
Content-Type: video/ogg
|
|
Content-Range: t:npt 11.85-21.16/653.791
|
|
Range-Redirect: 19147-22880
|
|
Vary: Accept-Range-Redirect</pre>
|
|
</div>
|
|
</li>
|
|
</ul>
|
|
|
|
<table border="1" summary="Editorial note: Silvia">
|
|
<tbody>
|
|
<tr>
|
|
<td align="left" valign="top" width="50%"><b>Editorial note:
|
|
Silvia</b></td>
|
|
<td align="right" valign="top" width="50%"> </td>
|
|
</tr>
|
|
<tr>
|
|
<td colspan="2" align="left" valign="top"><p>I have removed
|
|
X-Accept-Range-Redirect - the X-Range-Redirect header already indicates
|
|
that a mapping to byte ranges has been undertaken and the Accept-Ranges
|
|
header shows which fragment addressing types the server can resolve.
|
|
Need to discuss.</p>
|
|
|
|
<p>I have also removed the delivery of header information - for a URI
|
|
fragment resolution, that's not necessary. When applying this to a URI
|
|
query, however, it will be necessary, since the URI query delivers a
|
|
completely new resource.</p>
|
|
|
|
<p>I further added the Content-Range header, because it will tell the
|
|
client what actual fragment data is being delivered, so this is
|
|
required for the UA to get the actual mapping between fragment and byte
|
|
ranges.</p>
|
|
|
|
<p>I am using "307 Temporary Redirect" and thus Range-Redirect (rather
|
|
than Range-Refer) to return the reply without data in the reply.</p>
|
|
|
|
<p>We need an ABNF specification for Range-Redirect, which could
|
|
contain a large number of ranges, then to be separated by comma.</p>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<p>The UA proceeds to put the actual fragment request through as a normal byte
|
|
range request as in section <a
|
|
href="#processing-protocol-UA-mapped-new"><b>5.2.1.1 UA requests URI fragment
|
|
for the first time</b></a>:</p>
|
|
<ul>
|
|
<li><p>UA (5) → Proxy (6) → Origin Server (7):</p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>GET /video.ogv HTTP/1.1
|
|
Host: www.example.com
|
|
Accept: video/*
|
|
Range: 19147-22880</pre>
|
|
</div>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>The Origin Server puts the data together and sends it to the UA:</p>
|
|
<ul>
|
|
<li><p>Origin Server (7) → Proxy (8) → UA (9):</p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>HTTP/1.1 206 Partial Content
|
|
Accept-Ranges: bytes, t, xywh, track, id
|
|
Content-Length: 3743
|
|
Content-Type: video/ogg
|
|
Content-Range: bytes 19147-22880/35614993
|
|
Content-Range: t:npt 11.85-21.16/653.791
|
|
Etag: "b7a60-21f7111-46f3219476580"
|
|
|
|
{binary data}</pre>
|
|
</div>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>The UA decodes the data and displays it from the requested offset. The
|
|
caching Web proxy in the middle has now cached the byte range, since it adhered
|
|
to the normal byte range request protocol. All existing caching proxies will
|
|
work with this. New caching Web proxies may learn to interpret media fragments
|
|
natively, so won't require the extra packet exchange described in this
|
|
section.</p>
|
|
|
|
<table border="1" summary="Editorial note: Silvia">
|
|
<tbody>
|
|
<tr>
|
|
<td align="left" valign="top" width="50%"><b>Editorial note:
|
|
Silvia</b></td>
|
|
<td align="right" valign="top" width="50%"> </td>
|
|
</tr>
|
|
<tr>
|
|
<td colspan="2" align="left" valign="top"><p>somebody should paint
|
|
time-sequence diagrams for the protocol action - or update the existing
|
|
one to match with the description here.</p>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="processing-protocol-query" id="processing-protocol-query"></a>5.3
|
|
Protocol for URI query Resolution in HTTP</h3>
|
|
|
|
<p>This section describes the protocol steps used in HTTP <a
|
|
href="#rfc2616">[RFC 2616]</a> to resolve and deliver a media fragment
|
|
specified as a URI query.</p>
|
|
|
|
<p>A user requests a media fragment URI using a URI query:</p>
|
|
<ul>
|
|
<li><p>User → UA (1):</p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>http://www.example.com/video.ogv?t=10,20</pre>
|
|
</div>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>This is a full resource, so it is a simple HTTP retrieval process. The UA
|
|
has to check if a local copy of the requested resource is available in its
|
|
buffer. If yes, it does a conditional GET with e.g. an If-Modified-Since and
|
|
If-None-Match HTTP header.</p>
|
|
|
|
<p>Assuming the resource has not been retrieved before, the following is sent
|
|
to the server:</p>
|
|
<ul>
|
|
<li><p>UA (1) → Proxy (2) → Origin Server (3):</p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>GET /video.ogv?t=10,20 HTTP/1.1
|
|
Host: www.example.com
|
|
Accept: video/*</pre>
|
|
</div>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>If the server doesn't understand these query parameters, it typically
|
|
ignores them and returns the complete resource. This is not a requirement by
|
|
the URI or the HTTP standard, but the way it is typically implemented in Web
|
|
browsers.</p>
|
|
|
|
<p>A media fragment supporting server has to create a complete media resource
|
|
for the URI query, which in the case of Ogg requires creation of a new resource
|
|
by adapting the existing Ogg file headers and combining them with the extracted
|
|
byte range that relates to the given fragment. Some of the codec data may also
|
|
need to be re-encoded since, e.g. t=10 does not fall clearly on a decoding
|
|
boundary, but the retrieved resource must match as closely as possible the URI
|
|
query. This new resource is sent back as a reply:</p>
|
|
<ul>
|
|
<li><p>Origin Server (3) → Proxy (4) → UA (5):</p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>HTTP/1.1 200 OK
|
|
Content-Length: 3782
|
|
Content-Type: video/ogg
|
|
Etag: "b7a60-21f7111-46f3219476580"
|
|
|
|
{binary data}</pre>
|
|
</div>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>The UA serves the decoded resource to the User. Caching in Web proxies works
|
|
as it has always worked - most modern Web servers and UAs implement a caching
|
|
strategy for URIs that contain a query using one of the three methods for
|
|
marking freshness: heuristic freshness analysis, the Cache-Control header, or
|
|
the Expires header. In this case, many copies of different segments of the
|
|
original resource video.ogv may end up in proxy caches. An intelligent media
|
|
proxy in future may devise a strategy to buffer such resources in a more
|
|
efficient manner, where headers and byte ranges are stored differently.</p>
|
|
|
|
<p>It is possible to add an additional HTTP response header called "Link" that
|
|
refers the new resource back to the original resource and enables the UA to
|
|
retrieve further information about the original resource, such as its full
|
|
length. In this case, the user agent is also enable to choose to display the
|
|
dimensions of the primary resource or the one created by the query.</p>
|
|
|
|
<p>Further, media fragment URI queries can be extended to enable UAs to use the
|
|
Range-Redirect HTTP header to also revert back to a byte range request. This is
|
|
analogous to section <a href="#processing-protocol-proxy"><b>5.2.3 Proxy
|
|
cacheable Server mapped byte ranges</b></a>.</p>
|
|
|
|
<p>Not that a server that doesn't support media fragments through either URI
|
|
fragment or query addressing, will return the full resource in either case. It
|
|
is therefore not possible to first try URI fragment addressing, and when that
|
|
fails to try URI query addressing.</p>
|
|
|
|
<table border="1" summary="Editorial note: Silvia">
|
|
<tbody>
|
|
<tr>
|
|
<td align="left" valign="top" width="50%"><b>Editorial note:
|
|
Silvia</b></td>
|
|
<td align="right" valign="top" width="50%"> </td>
|
|
</tr>
|
|
<tr>
|
|
<td colspan="2" align="left" valign="top"><p>somebody should paint
|
|
time-sequence diagrams for the protocol action.</p>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a name="Conclusions" id="Conclusions"></a>6 Conclusions</h2>
|
|
|
|
<div class="div2">
|
|
<h3><a name="qualification-resources" id="qualification-resources"></a>6.1
|
|
Qualification of Media Resources</h3>
|
|
|
|
<p>HTTP byte ranges can only be used to request media fragments if these media
|
|
fragments can be expressed in terms of byte ranges. This restriction implies
|
|
that media resources should fulfil the following conditions: </p>
|
|
<ul>
|
|
<li><p>The media fragments can be extracted in the compressed domain;</p>
|
|
</li>
|
|
<li><p>No syntax element modifications in the bitstream are needed to perform
|
|
the extraction.</p>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>Not all media formats will be compliant with these two conditions. Hence, we
|
|
distinguish the following categories: </p>
|
|
<ol class="enumar">
|
|
<li><p>The media resource meets the two conditions (i.e., fragments can be
|
|
extracted in the compressed domain and no syntax element modifications are
|
|
necessary). In this case, caching media fragments of such media resources
|
|
is possible using HTTP byte ranges, because their media fragments are
|
|
addressable in terms of byte ranges. </p>
|
|
</li>
|
|
<li><p>Media fragments can be extracted in the compressed domain, but syntax
|
|
element modifications are required. These media fragments are cacheable
|
|
using HTTP byte ranges on condition that the syntax element modifications
|
|
are needed in media-headers applying to the whole media resource/fragment.
|
|
In this case, those media-headers could be sent to the client in the first
|
|
response of the server, which is a response to a request on a specific
|
|
resource different from the byte-range content. </p>
|
|
</li>
|
|
<li><p>Media fragments cannot be extracted in the compressed domain. In this
|
|
case, transcoding operations are necessary to extract media fragments.
|
|
Since these media fragments are not expressible in terms of byte ranges, it
|
|
is not possible to cache these media fragments using HTTP byte ranges. Note
|
|
that media formats which enable extracting fragments in the compressed
|
|
domain, but are not compliant with category 2 (i.e., syntax element
|
|
modifications are not only applicable to the whole media resource), also
|
|
belong to this category. </p>
|
|
</li>
|
|
</ol>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="back">
|
|
|
|
<div class="div1">
|
|
<h2><a name="references-normative" id="references-normative"></a>A
|
|
References</h2>
|
|
<dl>
|
|
<dt class="label"><a name="rfc2119" id="rfc2119"></a>RFC 2119</dt>
|
|
<dd>S. Bradner. <a href="http://www.ietf.org/rfc/rfc2119.txt"><cite>Key
|
|
Words for use in RFCs to Indicate Requirement Levels</cite></a>. IETF RFC
|
|
2119, March 1997. Available at <a
|
|
href="http://www.ietf.org/rfc/rfc2119.txt">http://www.ietf.org/rfc/rfc2119.txt</a>.
|
|
</dd>
|
|
<dt class="label"><a name="rtsp" id="rtsp"></a>RFC 2326</dt>
|
|
<dd><cite>Real Time Streaming Protocol (RTSP)</cite>. IETF RFC 2326, April
|
|
1998. Available at <a
|
|
href="http://www.ietf.org/rfc/rfc2326.txt">http://www.ietf.org/rfc/rfc2326.txt</a>.
|
|
</dd>
|
|
<dt class="label"><a name="rfc2616" id="rfc2616"></a>RFC 2616</dt>
|
|
<dd><cite>Hypertext Transfer Protocol -- HTTP/1.1</cite>. IETF RFC 2616,
|
|
June 1999. Available at <a
|
|
href="http://www.ietf.org/rfc/rfc2616.txt">http://www.ietf.org/rfc/rfc2616.txt</a>.
|
|
</dd>
|
|
<dt class="label"><a name="ogg" id="ogg"></a>RFC 3533</dt>
|
|
<dd><cite>The Ogg Encapsulation Format Version 0</cite>. IETF RFC 3533, May
|
|
2003. Available at <a
|
|
href="http://www.ietf.org/rfc/rfc3533.txt">http://www.ietf.org/rfc/rfc3533.txt</a>.
|
|
</dd>
|
|
<dt class="label"><a name="rfc3986" id="rfc3986"></a>RFC 3986</dt>
|
|
<dd>T. Berners-Lee and R. Fielding and L. Masinter. <a
|
|
href="http://www.ietf.org/rfc/rfc3986.txt"><cite>Uniform Resource
|
|
Identifier (URI): Generic Syntax</cite></a>. IETF RFC 3986, January 2005.
|
|
Available at <a
|
|
href="http://www.ietf.org/rfc/rfc3986.txt">http://www.ietf.org/rfc/rfc3986.txt</a>.
|
|
</dd>
|
|
<dt class="label"><a name="rfc5147" id="rfc5147"></a>RFC 5147</dt>
|
|
<dd>E. Wilde and M. Duerst.<a
|
|
href="http://tools.ietf.org/html/rfc5147"><cite>URI Fragment Identifiers
|
|
for the text/plain Media Type</cite></a>. IETF RFC 5147, April 2008.
|
|
Available at <a
|
|
href="http://tools.ietf.org/html/rfc5147">http://tools.ietf.org/html/rfc5147</a>.
|
|
</dd>
|
|
<dt class="label"><a name="html40" id="html40"></a>HTML 4.0</dt>
|
|
<dd>D. Ragett and A. Le Hors and I. Jacobs.<a
|
|
href="http://www.w3.org/TR/REC-html40/intro/intro.html#fragment-uri"><cite>HTML
|
|
Fragment identifiers</cite></a>. W3C Rec, December 1999. Available at <a
|
|
href="http://www.w3.org/TR/REC-html40/intro/intro.html#fragment-uri">http://www.w3.org/TR/REC-html40/intro/intro.html#fragment-uri</a>.
|
|
</dd>
|
|
<dt class="label"><a name="html5" id="html5"></a>HTML 5</dt>
|
|
<dd>Ian Hickson, Google (ed).<a
|
|
href="http://www.whatwg.org/specs/web-apps/current-work/"><cite>HTML5</cite></a>.
|
|
WHATWG Draft Standard, 25th August 2009. Available at <a
|
|
href="http://www.whatwg.org/specs/web-apps/current-work/">http://www.whatwg.org/specs/web-apps/current-work/</a>.
|
|
</dd>
|
|
<dt class="label"><a name="svg" id="svg"></a>SVG</dt>
|
|
<dd>J. Ferraiolo.<a
|
|
href="http://www.w3.org/TR/2001/REC-SVG-20010904/linking#FragmentIdentifiersSVG"><cite>SVG
|
|
Fragment identifiers</cite></a>. W3C Rec, September 2001. Available at <a
|
|
href="http://www.w3.org/TR/2001/REC-SVG-20010904/linking#FragmentIdentifiersSVG">http://www.w3.org/TR/2001/REC-SVG-20010904/linking#FragmentIdentifiersSVG</a>.
|
|
</dd>
|
|
<dt class="label"><a name="smil30" id="smil30"></a>SMIL</dt>
|
|
<dd>Sjoerd Mullender, CWI (ed).<a
|
|
href="http://www.w3.org/TR/2008/REC-SMIL3-20081201/"><cite>Synchronized
|
|
Multimedia Integration Language (SMIL 3.0)</cite></a>. W3C Recommendation
|
|
01 December 2008. Available at <a
|
|
href="http://www.w3.org/TR/2008/REC-SMIL3-20081201/">http://www.w3.org/TR/2008/REC-SMIL3-20081201/</a>.
|
|
</dd>
|
|
<dt class="label"><a name="xpointer" id="xpointer"></a>xpointer</dt>
|
|
<dd>P. Grosso and E. Maler and J. Marsh and N. Walsh.<a
|
|
href="http://www.w3.org/TR/xptr-framework/"><cite>XPointer
|
|
Framework</cite></a>. W3C Rec, March 2003. Available at <a
|
|
href="http://www.w3.org/TR/xptr-framework/">http://www.w3.org/TR/xptr-framework/</a>.
|
|
</dd>
|
|
<dt class="label"><a name="mpeg-7" id="mpeg-7"></a>MPEG-7</dt>
|
|
<dd><cite>Information Technology - Multimedia Content Description Interface
|
|
(MPEG-7)</cite>. Standard No. ISO/IEC 15938:2001, International
|
|
Organization for Standardization(ISO), 2001. </dd>
|
|
<dt class="label"><a name="temporalURI" id="temporalURI"></a>temporal URI</dt>
|
|
<dd>S. Pfeiffer and C. Parker and A. Pang.<a
|
|
href="http://annodex.net/TR/draft-pfeiffer-temporal-fragments-03.html"><cite>Specifying
|
|
time intervals in URI queries and fragments of time-based Web
|
|
resources</cite></a>. Internet Draft, March 2005. Available at <a
|
|
href="http://annodex.net/TR/draft-pfeiffer-temporal-fragments-03.html">http://annodex.net/TR/draft-pfeiffer-temporal-fragments-03.html</a>.
|
|
</dd>
|
|
<dt class="label"><a name="cmml" id="cmml"></a>CMML</dt>
|
|
<dd><cite>Continuous Media Markup Language (CMML), Version 2.1</cite>. IETF
|
|
Internet-Draft 4th March 2006 <a
|
|
href="http://www.annodex.net/TR/draft-pfeiffer-cmml-03.txt">http://www.annodex.net/TR/draft-pfeiffer-cmml-03.txt</a>.
|
|
</dd>
|
|
<dt class="label"><a name="roe" id="roe"></a>ROE</dt>
|
|
<dd><cite>Rich Open multitrack media Exposition (ROE)</cite>. Xiph Wiki.
|
|
Retrieved 13 April 2009 at <a
|
|
href="http://wiki.xiph.org/index.php/ROE">http://wiki.xiph.org/index.php/ROE</a>.
|
|
</dd>
|
|
<dt class="label"><a name="skeleton" id="skeleton"></a>Skeleton</dt>
|
|
<dd><cite>Ogg Skeleton</cite>. Xiph Wiki. Retrieved 13 April 2009 at <a
|
|
href="http://wiki.xiph.org/OggSkeleton">http://wiki.xiph.org/OggSkeleton</a>.
|
|
</dd>
|
|
<dt class="label"><a name="mpeg21" id="mpeg21"></a>MPEG-21</dt>
|
|
<dd><cite>Information Technology - Multimedia Framework (MPEG-21)</cite>.
|
|
Standard No. ISO/IEC 21000:2002, International Organization for
|
|
Standardization(ISO), 2002. Available at <a
|
|
href="http://www.chiariglione.org/mpeg/working_documents/mpeg-21/fid/fid-is.zip">http://www.chiariglione.org/mpeg/working_documents/mpeg-21/fid/fid-is.zip</a>.
|
|
</dd>
|
|
<dt class="label"><a name="smpte" id="smpte"></a>SMPTE</dt>
|
|
<dd><cite>SMPTE RP 136 Time and Control Codes for 24, 25 or 30
|
|
Frame-Per-Second Motion-Picture Systems</cite> </dd>
|
|
<dt class="label"><a name="abnf" id="abnf"></a>ABNF</dt>
|
|
<dd><cite>Augmented BNF for Syntax Specifications: ABNF</cite>, Internet
|
|
STD 68 (as of April 2009: <a
|
|
href="http://tools.ietf.org/html/rfc5234">RFC 5234</a>). </dd>
|
|
<dt class="label"><a name="isoBaseMediaFF" id="isoBaseMediaFF"></a>ISO Base
|
|
Media File Format</dt>
|
|
<dd><cite>Information technology - Coding of audio-visual objects - Part
|
|
12: ISO base media file format</cite>. Retrieved 13 April 2009 at <a
|
|
href="http://standards.iso.org/ittf/PubliclyAvailableStandards/c051533_ISO_IEC_14496-12_2008.zip">http://standards.iso.org/ittf/PubliclyAvailableStandards/c051533_ISO_IEC_14496-12_2008.zip</a>
|
|
</dd>
|
|
<dt class="label"><a name="mf-req" id="mf-req"></a>Use cases and requirements
|
|
for Media Fragments</dt>
|
|
<dd><cite>Use cases and requirements for Media Fragments</cite>. W3C
|
|
Working Draft 30 April 2009: <a
|
|
href="http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-reqs/">http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-reqs/</a>
|
|
</dd>
|
|
</dl>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a name="acknowledgments" id="acknowledgments"></a>B Acknowledgements
|
|
(Non-Normative)</h2>
|
|
|
|
<p>This document is the work of the <a
|
|
href="http://www.w3.org/2008/WebVideo/Fragments/">W3C Media Fragments Working
|
|
Group</a>. Members of the Working Group are (at the time of writing, and in
|
|
alphabetical order): Eric Carlson (Apple, Inc.), Michael Hausenblas (DERI
|
|
Galway at the National University of Ireland, Galway, Ireland), Jack Jansen
|
|
(CWI), Yves Lafon (W3C/ERCIM), Erik Mannens (IBBT), Thierry Michel (W3C/ERCIM),
|
|
Guillaume (Jean-Louis) Olivrin (Meraka Institute), Soohong Daniel Park (Samsung
|
|
Electronics Co., Ltd.), Conrad Parker (W3C Invited Experts), Silvia Pfeiffer
|
|
(W3C Invited Experts), David Singer (Apple, Inc.), Raphaël Troncy (CWI),
|
|
Vassilis Tzouvaras (K-Space), Davy Van Deursen (IBBT) </p>
|
|
|
|
<p>The people who have contributed to <a
|
|
href="http://lists.w3.org/Archives/Public/public-media-fragment/">discussions
|
|
on public-media-fragment@w3.org </a> are also gratefully acknowledged. In
|
|
particular: Olivier Aubert, Werner Bailer, Pierre-Antoine Champin, Cyril
|
|
Concolato, Franck Denoual, Martin J. Dürst, Jean Pierre Evain, Ken
|
|
Harrenstien, Kilroy Hughes, Philip Jägenstedt, Ryo Kawaguchi, Véronique
|
|
Malaisé, Henrik Nordstrom, Yannick Prié, Yves Raimond, Julian Reschke,
|
|
Geoffrey Sneddon, Felix Sasaki, Philip Taylor, Christian Timmerer, Jorrit
|
|
Vermeiren and Munjo Yu. </p>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a name="change-log" id="change-log"></a>C Change Log (Non-Normative)</h2>
|
|
|
|
<p>@@This paragraph will be replaced by the change log. DO NOT TOUCH@@</p>
|
|
</div>
|
|
</div>
|
|
</body>
|
|
</html>
|