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.
3536 lines
152 KiB
3536 lines
152 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; }
|
|
|
|
dt.label { display: run-in; }
|
|
|
|
li, p { margin-top: 0.3em;
|
|
margin-bottom: 0.3em; }
|
|
|
|
.diff-chg { background-color: yellow; }
|
|
.diff-del { background-color: red; text-decoration: line-through;}
|
|
.diff-add { background-color: lime; }
|
|
|
|
table { empty-cells: show; }
|
|
|
|
table caption {
|
|
font-weight: normal;
|
|
font-style: italic;
|
|
text-align: left;
|
|
margin-bottom: .5em;
|
|
}
|
|
|
|
div.issue {
|
|
color: red;
|
|
}
|
|
.rfc2119 {
|
|
font-variant: small-caps;
|
|
}
|
|
|
|
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}
|
|
|
|
div.boxedtext {
|
|
border: solid #bebebe 1px;
|
|
margin: 2em 1em 1em 2em;
|
|
}
|
|
|
|
span.practicelab {
|
|
margin: 1.5em 0.5em 1em 1em;
|
|
font-weight: bold;
|
|
font-style: italic;
|
|
}
|
|
|
|
span.practicelab { background: #dfffff; }
|
|
|
|
span.practicelab {
|
|
position: relative;
|
|
padding: 0 0.5em;
|
|
top: -1.5em;
|
|
}
|
|
p.practice
|
|
{
|
|
margin: 1.5em 0.5em 1em 1em;
|
|
}
|
|
|
|
@media screen {
|
|
p.practice {
|
|
position: relative;
|
|
top: -2em;
|
|
padding: 0;
|
|
margin: 1.5em 0.5em -1em 1em;
|
|
}
|
|
}
|
|
/**/ </style>
|
|
<link type="text/css" rel="stylesheet"
|
|
href="http://www.w3.org/StyleSheets/TR/W3C-WD.css" />
|
|
|
|
</head>
|
|
|
|
<body>
|
|
|
|
<div class="head">
|
|
<p><a href="http://www.w3.org/"><img width="72" height="48" alt="W3C"
|
|
src="http://www.w3.org/Icons/w3c_home" /></a></p>
|
|
|
|
<h1><a id="title" name="title"></a>Media Fragments URI 1.0</h1>
|
|
|
|
<h2><a id="w3c-doctype" name="w3c-doctype"></a>W3C Working Draft 17 March
|
|
2011</h2>
|
|
<dl>
|
|
<dt>This version:</dt>
|
|
<dd><a
|
|
href="http://www.w3.org/TR/2011/WD-media-frags-20110317">http://www.w3.org/TR/2011/WD-media-frags-20110317</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>Previous version:</dt>
|
|
<dd><a
|
|
href="http://www.w3.org/TR/2010/WD-media-frags-20100624">http://www.w3.org/TR/2010/WD-media-frags-20100624</a>
|
|
</dd>
|
|
<dt>Editors:</dt>
|
|
<dd><a href="http://www.eurecom.fr/~troncy/">Raphaël Troncy </a>,
|
|
EURECOM</dd>
|
|
<dd><a href="http://multimedialab.elis.ugent.be/emannens">Erik Mannens
|
|
</a>, IBBT Multimedia Lab, University of Ghent</dd>
|
|
<dd><a href="http://blog.gingertech.net/">Silvia Pfeiffer </a>, W3C Invited
|
|
Expert</dd>
|
|
<dd><a href="http://multimedialab.elis.ugent.be/dvdeurse">Davy Van Deursen
|
|
</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="mailto:philipj@opera.com">Philip Jägenstedt </a>, Opera
|
|
Software</dd>
|
|
<dd><a href="http://www.cwi.nl/~jack/">Jack Jansen </a>, CWI, Centrum
|
|
Wiskunde & Informatica, Amsterdam</dd>
|
|
<dd><a
|
|
href="mailto:ylafon@w3.org">Yves
|
|
Lafon </a>, W3C</dd>
|
|
<dd><a href="http://www.kfish.org/">Conrad Parker </a>, W3C Invited
|
|
Expert</dd>
|
|
</dl>
|
|
|
|
<p class="copyright"><a
|
|
href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2011 <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 id="abstract" name="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 name-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 id="status" name="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 Second Last Call Working Draft 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>This W3C Working Draft version of the Media Fragments URI 1.0 specification
|
|
incorporates requests for changes from comments sent during the first Last Call
|
|
Review, as agreed with the commenters and changes following implementation
|
|
experiences from the Working Group. The Working Group wishes to have these
|
|
changes reviewed before proceeding to Candidate Recommendation. </p>
|
|
|
|
<p>The W3C Membership and other interested parties are invited to review the
|
|
document and send comments through 10 April 2011. 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
|
|
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 id="contents" name="contents"></a>Table of Contents</h2>
|
|
|
|
<p class="toc">1 <a href="#introduction">Introduction</a><br />
|
|
2 <a href="#standardisation">Standardisation Issues</a><br />
|
|
2.1 <a href="#standardisation-terminology">Terminology</a><br />
|
|
2.2 <a href="#standardisation-approach">Media Fragments
|
|
Standardisation</a><br />
|
|
2.2.1 <a href="#standardisation-URI-fragments">URI
|
|
Fragments</a><br />
|
|
2.2.2 <a href="#standardisation-URI-queries">URI Queries</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="#general-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.2.5 <a href="#common-syntax">Common Syntax</a><br />
|
|
5 <a href="#media-fragment-processing">Media Fragments Processing</a><br />
|
|
5.1 <a href="#processing-media-fragment-uri">Processing Media Fragment
|
|
URI</a><br />
|
|
5.1.1 <a href="#processing-name-value-components">Processing
|
|
name-value components</a><br />
|
|
5.1.2 <a href="#processing-name-value-lists">Processing
|
|
name-value lists</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.2.1 <a
|
|
href="#processing-protocol-server-mapped-default">Server mapped byte ranges
|
|
with corresponding binary data</a><br />
|
|
5.2.2.2 <a
|
|
href="#processing-protocol-server-mapped-setup">Server mapped byte ranges with
|
|
corresponding binary data and codec setup data</a><br />
|
|
5.2.2.3 <a
|
|
href="#processing-protocol-server-mapped-proxy">Proxy cacheable server mapped
|
|
byte ranges</a><br />
|
|
5.2.3 <a href="#server-triggered-redirect">Server triggered
|
|
redirect</a><br />
|
|
5.3 <a href="#processing-protocol-query">Protocol for URI query
|
|
Resolution in HTTP</a><br />
|
|
6 <a href="#media-fragment-semantics">Media Fragments Semantics</a><br />
|
|
6.1 <a href="#error-general">Errors on the General URI level</a><br />
|
|
6.1.1 <a href="#error-general-non-existent">Non-existent
|
|
dimension:</a><br />
|
|
6.1.2 <a href="#error-general-underspec">Under-specified
|
|
Dimension</a><br />
|
|
6.2 <a href="#error-temporal">Errors on the temporal dimensions</a><br
|
|
/>
|
|
6.2.1 <a href="#error-temporal-valid">Valid requests</a><br />
|
|
6.2.2 <a href="#error-temporal-empty">Empty</a><br />
|
|
6.2.3 <a
|
|
href="#error-temporal-non-existent">Non-existent</a><br />
|
|
6.2.4 <a href="#error-temporal-validity">Validity error</a><br
|
|
/>
|
|
6.2.5 <a href="#error-temporal-smpte-mismatch">SMPTE time code
|
|
mismatch</a><br />
|
|
6.3 <a href="#error-spatial">Errors on the spatial dimensions</a><br />
|
|
6.4 <a href="#error-track">Errors on the track dimensions</a><br />
|
|
6.5 <a href="#error-named">Errors on the named dimensions</a><br />
|
|
7 <a href="#implementor-notes">Notes to Implementors (non-normative)</a><br />
|
|
7.1 <a href="#media-fragment-browser">Browsers Rendering Media
|
|
Fragments</a><br />
|
|
7.2 <a href="#media-fragment-display">Clients Displaying Media
|
|
Fragments</a><br />
|
|
7.3 <a href="#media-fragment-clients">All Media Fragment Clients</a><br
|
|
/>
|
|
7.4 <a href="#media-fragment-servers">Media Fragment Servers</a><br />
|
|
7.5 <a href="#media-fragment-webapps">Media Fragment Web
|
|
Applications</a><br />
|
|
8 <a href="#conclusions">Conclusions</a><br />
|
|
8.1 <a href="#qualification-resources">Qualification of Media
|
|
Resources</a><br />
|
|
</p>
|
|
|
|
<h3><a id="appendices" name="appendices"></a>Appendices</h3>
|
|
|
|
<p class="toc">A <a href="#references-normative">References</a><br />
|
|
B <a href="#collected-syntax-uri">Collected ABNF Syntax for URI</a>
|
|
(Non-Normative)<br />
|
|
C <a href="#collected-syntax-http">Collected ABNF Syntax for HTTP Headers</a>
|
|
(Non-Normative)<br />
|
|
D <a href="#rtsp-media-fragment-processing">Processing media fragment URIs in
|
|
RTSP</a> (Non-Normative)<br />
|
|
D.1 <a href="#mapping-mf-to-rtsp-methods">How to map Media Fragment
|
|
URIs to RTSP protocol methods</a><br />
|
|
D.1.1 <a href="#rtsp-mf-dimensions">Dealing with the media
|
|
fragment URI dimensions in RTSP</a><br />
|
|
D.1.1.1 <a href="#rtsp-temporal">Temporal Media
|
|
Fragment URIs</a><br />
|
|
D.1.1.2 <a href="#rtsp-track">Track Media Fragment
|
|
URIs</a><br />
|
|
D.1.1.3 <a href="#rtsp-spatial">Spatial Media Fragment
|
|
URIs</a><br />
|
|
D.1.1.4 <a href="#rtsp-named">Named Media Fragment
|
|
URIs</a><br />
|
|
D.1.2 <a href="#rtsp-combined-mf-dimensions">Putting the media
|
|
fragment URI dimensions together in RTSP</a><br />
|
|
D.1.3 <a href="#rtsp-caching">Caching and RTSP for media
|
|
fragment URIs</a><br />
|
|
E <a href="#acknowledgments">Acknowledgements</a> (Non-Normative)<br />
|
|
F <a href="#change-log">Change Log</a> (Non-Normative)<br />
|
|
</p>
|
|
</div>
|
|
<hr />
|
|
|
|
<div class="body">
|
|
|
|
<div class="div1">
|
|
<h2><a id="introduction" name="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 <cite><a
|
|
href="#mf-req">Use cases and requirements for Media Fragments</a></cite>
|
|
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 protocol. This
|
|
specification is not defining the protocol aspect of RTSP handling of a media
|
|
fragment in the normative sections. We expect the media fragment URI syntax to
|
|
be generic and a possible mapping between this syntax and RTSP messages can be
|
|
found in an appendix of this specification <a
|
|
href="#rtsp-media-fragment-processing"><b>D Processing media fragment URIs in
|
|
RTSP</b></a>. 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 id="standardisation" name="standardisation"></a>2 Standardisation
|
|
Issues</h2>
|
|
|
|
<div class="div2">
|
|
<h3><a id="standardisation-terminology"
|
|
name="standardisation-terminology"></a>2.1 Terminology</h3>
|
|
|
|
<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 <cite><a href="#rfc2119">RFC 2119</a></cite>. </p>
|
|
|
|
<p>According to <cite><a href="#rfc3986">RFC 3986</a></cite>, the term "URI"
|
|
does not include relative references. In this document, we consider both URIs
|
|
and relative references. Consequently, we use the term "URI reference" as
|
|
defined in <cite><a href="#rfc3986">RFC 3986</a></cite> (section 4.1). For
|
|
simplicity reasons, this document, however, only uses the term "media fragment
|
|
URI" in place of "media fragment URI reference". </p>
|
|
|
|
<p>The following terms are used frequently in this document and need to be
|
|
clearly understood: </p>
|
|
<ul>
|
|
<li>URI fragment = anything behind a "#" in a URI</li>
|
|
<li>URI query = anything behind a "?" and before a "#" in a URI</li>
|
|
<li>media fragment URI = a URI addressing subparts of a media resource - that
|
|
could be through URI queries or URI fragments</li>
|
|
</ul>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="standardisation-approach" name="standardisation-approach"></a>2.2
|
|
Media Fragments Standardisation</h3>
|
|
|
|
<p>The basis for the standardisation of media fragment URIs is the URI
|
|
specification, <cite><a href="#rfc3986">RFC 3986</a></cite>. Providing media
|
|
fragment identification information in URIs refers here to the specification of
|
|
the structure of a URI fragment or a URI query. This document will explain how
|
|
URI fragments and URI queries are structured to identify media fragments. It
|
|
normalises the name-value parameters used in URI fragments and URI queries to
|
|
address media fragments. These build on existing CGI parameter conventions. </p>
|
|
|
|
<p>In this section, we look at implications of standardising the structure of
|
|
media fragment URIs. </p>
|
|
|
|
<div class="div3">
|
|
<h4><a id="standardisation-URI-fragments"
|
|
name="standardisation-URI-fragments"></a>2.2.1 URI Fragments</h4>
|
|
|
|
<p>The URI specification <cite><a href="#rfc3986">RFC 3986</a></cite> says
|
|
about the format of a URI fragment in Section 3.5: </p>
|
|
|
|
<p><i>"The fragment's format and resolution is [..] dependent on the media type
|
|
[RFC2046] of a potentially retrieved representation. [..] Fragment identifier
|
|
semantics are independent of the URI scheme and thus cannot be redefined by
|
|
scheme specifications."</i> </p>
|
|
|
|
<p>This essentially means that only media type definitions (as registered
|
|
through the process defined in <cite><a href="#rfc4288">RFC 4288</a></cite>)
|
|
are able to introduce a standard structure on URI fragments for that mime type.
|
|
One part of the registration process of a media type can include information
|
|
about how fragment identifiers in URIs are constructed for use in conjunction
|
|
with this media type. </p>
|
|
|
|
<p>Note that the registration of URI fragment construction rules as expressed
|
|
in Section 4.11 of <cite><a href="#rfc4288">RFC 4288</a></cite> is only a
|
|
SHOULD-requirement. An analysis of all media type registrations showed that
|
|
there is not a single media type registration in the audio/*, image/*, video/*
|
|
branches that is currently defining fragments or fragment semantics. </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 <a
|
|
href="http://www.w3.org/2008/WebVideo/Fragments/wiki/MediaTypeReview">few media
|
|
types that actually have a specified fragment format</a> even if it is not
|
|
registered with the media type: these include Ogg, MPEG-4, and MPEG-21.
|
|
Further, only a small number of software packages actually supports these
|
|
fragment formats. For all others, the semantics of the fragment are considered
|
|
to be unknown. </p>
|
|
|
|
<p>As such, the intention of this document is to propose a specification to all
|
|
media type owners in the audio/*, image/*, and video/* branches for a
|
|
structured approach to URI fragments and for specification of commonly agreed
|
|
dimensions to address media fragments (i.e. subparts of a media resource)
|
|
through URI fragments. We recommend media type owners to harmonize their
|
|
existing schemes with the ones proposed in this document and update or add the
|
|
fragment semantics specification to their media type registration. </p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="standardisation-URI-queries"
|
|
name="standardisation-URI-queries"></a>2.2.2 URI Queries</h4>
|
|
|
|
<p>The URI specification <cite><a href="#rfc3986">RFC 3986</a></cite> says
|
|
about the format of a URI query in Section 3.4: </p>
|
|
|
|
<p><i>"The query component [..] serves to identify a resource within the scope
|
|
of the URI's scheme and naming authority (if any). [..] Query components are
|
|
often used to carry identifying information in the form of "key=value" pairs
|
|
[..]."</i> </p>
|
|
|
|
<p>URI query specifications are more closely linked to the URI scheme, some of
|
|
which do not even use a query component. We are mostly concerned with the HTTP
|
|
<cite><a href="#rfc2616">RFC 2616</a></cite> and the RTP/RTSP <cite><a
|
|
href="#">rfc2326</a></cite> protocols here, which both support query
|
|
components. HTTP says nothing about how a URI query has to be interpreted. RTSP
|
|
explicitly says that fragment and query identifiers do not have a well-defined
|
|
meaning at this time, with the interpretation left to the RTSP server. </p>
|
|
|
|
<p>The URI specification <cite><a href="#rfc3986">RFC 3986</a></cite> says
|
|
generally that the data within the URI is often parsed by both the user agent
|
|
and one or more servers. It refers in particular to HTTP in Section 7.3: </p>
|
|
|
|
<p><i>"In HTTP, for example, a typical user agent will parse a URI into its
|
|
five major components, access the authority's server, and send it the data
|
|
within the authority, path, and query components. A typical server will take
|
|
that information, parse the path into segments and the query into key/value
|
|
pairs, and then invoke implementation-specific handlers to respond to the
|
|
request."</i> </p>
|
|
|
|
<p>Since the interpretation of query components resides with the functionality
|
|
of servers, the intention of this document wrt query components is to recommend
|
|
standard name-value pair formats for use in addressing media fragments through
|
|
URI queries. We recommend server and server-type software providers to
|
|
harmonize their existing schemes in use with media resources to support the
|
|
nomenclature proposed in this specification. </p>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a id="fragment-query" name="fragment-query"></a>3 URI fragment and URI
|
|
query</h2>
|
|
|
|
<table border="1" summary="Editorial note">
|
|
<tbody>
|
|
<tr>
|
|
<td width="50%" valign="top" align="left"><b>Editorial note</b></td>
|
|
<td width="50%" valign="top" align="right"> </td>
|
|
</tr>
|
|
<tr>
|
|
<td valign="top" align="left" colspan="2">This section is
|
|
non-normative</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<p>To address a media fragment, one needs to find ways to convey the fragment
|
|
information. This specification builds on URIs <cite><a href="#rfc3986">RFC
|
|
3986</a></cite>. 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 id="URIquery-vs-fragments" name="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 <cite><a href="#mf-req">Use cases and
|
|
requirements for Media Fragments</a></cite> 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>
|
|
|
|
<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 id="URIfragment-user-agent" name="URIfragment-user-agent"></a>3.2
|
|
Resolving URI fragments within the user agent</h3>
|
|
|
|
<p>A user agent may itself resolve and control the presentation of media
|
|
fragment URIs. The simplest case arises where the user agent has already
|
|
downloaded the entire resource and can perform the extraction from its locally
|
|
cached copy. For some media types, it may also be possible to perform the
|
|
extraction over the network without any special protocol assistance. For
|
|
temporal fragments this requires a user agent to be able to seek on the media
|
|
resource using existing protocol mechanisms. </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 - something generally unviable for such large resources.
|
|
</p>
|
|
|
|
<p>Therefore, media resources are not always retrieved over HTTP using a single
|
|
request. They may be retrieved as a sequence of byte range requests on the
|
|
original resource URI, or may be retrieved as a sequence of requests to
|
|
different URIs each representing a small part of the media. The reasons for
|
|
such mechanisms include bandwidth conservation, where a client chooses to space
|
|
requests out over time during playback in order to maximize bandwidth available
|
|
for other activities, and bandwidth adaptation, where a client selects among
|
|
various representations with varying bitrate depending on the current bandwidth
|
|
availability. </p>
|
|
|
|
<p>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. 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>Similarly, a user agent that knows how to map media fragments to a sequence
|
|
of URIs can satisfy a URI fragment request by itself. This is typically the
|
|
case for user agents that perform adaptive streaming. For example, a user agent
|
|
that deals with a media resource that contains a sequence of URIs, each a media
|
|
file of a few seconds duration, can resolve the media fragment addresses to a
|
|
subsequence of those URIs. This is the case with QuickTime adaptive bitrate
|
|
streaming or IIS Smooth Streaming. </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 id="URIfragment-server" name="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 id="URIfragment-proxies" name="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 width="50%" valign="top" align="left"><b>Editorial note:
|
|
Raphael</b></td>
|
|
<td width="50%" valign="top" align="right"> </td>
|
|
</tr>
|
|
<tr>
|
|
<td valign="top" align="left" colspan="2">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 id="URIquery-media-fragments" name="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>
|
|
|
|
<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 id="URIquery-URIfragment" name="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
|
|
<cite><a href="#rfc3986">RFC 3986</a></cite>. </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 width="50%" valign="top" align="left"><b>Editorial note:
|
|
Silvia</b></td>
|
|
<td width="50%" valign="top" align="right"> </td>
|
|
</tr>
|
|
<tr>
|
|
<td valign="top" align="left" colspan="2">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 id="media-fragment-syntax" name="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. </p>
|
|
|
|
<p>Guiding principles for the definition of the media fragments syntax were as
|
|
follows: </p>
|
|
<ul>
|
|
<li>a. The MF syntax for queries and fragments should be identical</li>
|
|
<li>b. The MF syntax should be unambiguous</li>
|
|
<li>c. The MF syntax should allow any UTF-8 character in track or id
|
|
names</li>
|
|
<li>d. The MF syntax should adhere to applicable formal standards</li>
|
|
<li>e. The MF syntax should adhere to de-facto usage of queries and
|
|
fragments</li>
|
|
<li>f. The MF syntax should be as concise as possible, with no unneeded
|
|
grammatical fluff</li>
|
|
</ul>
|
|
|
|
<div class="div2">
|
|
<h3><a id="general-structure" name="general-structure"></a>4.1 General
|
|
Structure</h3>
|
|
|
|
<p>A list of name-value pairs is encoded in the query or fragment component of
|
|
a URI. The name and value components are separated by an equal sign
|
|
(<code>=</code>), while multiple name-value pairs are separated by an ampersand
|
|
(<code>&</code>). </p>
|
|
|
|
<div class="exampleInner">
|
|
<a id="namevalues" name="namevalues"></a>
|
|
<pre>name = fragment - "&" - "="
|
|
value = fragment - "&"
|
|
namevalue = name [ "=" value ]
|
|
namevalues = namevalue *( "&" namevalue )</pre>
|
|
</div>
|
|
|
|
<p>The names and values can be arbitrary Unicode strings, encoded in <cite><a
|
|
href="#utf-8">UTF-8</a></cite> and percent-encoded as per <cite><a
|
|
href="#rfc3986">RFC 3986</a></cite>. Here are some examples of URIs with
|
|
name-value pairs in the fragment component, to demonstrate the general
|
|
structure: </p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>http://www.example.com/example.ogv#a=b&c=d
|
|
http://www.example.com/example.ogv#t=10,20
|
|
http://www.example.com/example.ogv#track=audio&t=10,20
|
|
http://www.example.com/example.ogv#id=Cap%C3%ADtulo%202</pre>
|
|
</div>
|
|
|
|
<p>While arbitrary name-value pairs can be encoded in this manner, this
|
|
specification defines a fixed set of dimensions. The dimension keyword name is
|
|
encoded in the name component, while dimension-specific syntax is encoded in
|
|
the value component. </p>
|
|
|
|
<p>Section <a href="#processing-name-value-components"><b>5.1.1 Processing
|
|
name-value components</b></a> defines in more detail how to process the
|
|
name-value pair syntax, arriving at a list of name-value Unicode string pairs.
|
|
The syntax definitions in <a href="#fragment-dimensions"><b>4.2 Fragment
|
|
Dimensions</b></a> apply to these Unicode strings. </p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="fragment-dimensions" name="fragment-dimensions"></a>4.2 Fragment
|
|
Dimensions</h3>
|
|
|
|
<p>Media fragments support addressing 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 or more tracks in the original media,
|
|
such as "the english audio and the video 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>The temporal, spatial and track dimensions are logically independent and can
|
|
be combined; the outcome is independent of the order of the dimensions. </p>
|
|
|
|
<p>The track dimension refers to one of a set of parallel media streams (e.g.
|
|
"the english audio track for a video"), not to a (possibly self-contained)
|
|
section of the source media (e.g. "Audio track 2 of a CD"). </p>
|
|
|
|
<p>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="#media-fragment-semantics"><b>6
|
|
Media Fragments Semantics</b></a>. </p>
|
|
|
|
<div class="div3">
|
|
<h4><a id="naming-time" name="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>
|
|
|
|
<p>Examples:</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) <cite><a
|
|
href="#rtsp">RFC 2326</a></cite>, as SMPTE timecodes, <cite><a
|
|
href="#smpte">SMPTE</a></cite>, or as real-world clock time (clock) <cite><a
|
|
href="#rtsp">RFC 2326</a></cite>. 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>
|
|
|
|
<div class="exampleInner">
|
|
<a id="timesegment" name="timesegment"></a>
|
|
<pre>timeprefix = %x74 ; "t"
|
|
timeparam = <a href="#npttimedef">npttimedef</a> / <a href="#smptetimedef">smptetimedef</a> / <a href="#clocktimedef">clocktimedef</a></pre>
|
|
</div>
|
|
|
|
<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 id="npt-time" name="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 to indicate miliseconds, 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. This
|
|
specification builds on the RTSP specification of NPT <cite><a href="#rtsp">RFC
|
|
2326</a></cite>. </p>
|
|
|
|
<div class="exampleInner">
|
|
<a id="npttimedef" name="npttimedef"></a>
|
|
<pre>npt-sec = 1*DIGIT [ "." *DIGIT ] ; definitions taken
|
|
npt-hhmmss = npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT] ; from <cite><a href="#rtsp">RFC 2326</a></cite>,
|
|
npt-mmss = npt-mm ":" npt-ss [ "." *DIGIT]
|
|
npt-hh = 1*DIGIT ; any positive number
|
|
npt-mm = 2DIGIT ; 0-59
|
|
npt-ss = 2DIGIT ; 0-59
|
|
|
|
npttimedef = [ deftimeformat ":"] ( npttime [ "," npttime ] ) / ( "," npttime )
|
|
|
|
deftimeformat = %x6E.70.74 ; "npt"
|
|
npttime = npt-sec / npt-mmss / npt-hhmmss</pre>
|
|
</div>
|
|
|
|
<p>Examples:</p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>t=npt:10,20 # => results in the time interval [10,20)
|
|
t=npt:120, # => results in the time interval [120,end)
|
|
t=npt:,121.5 # => 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>
|
|
</div>
|
|
|
|
<div class="div4">
|
|
<h5><a id="smpte-time" name="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">
|
|
<a id="smptetimedef" name="smptetimedef"></a>
|
|
<pre>smptetimedef = smpteformat ":"( frametime [ "," frametime ] ) / ( "," frametime )
|
|
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"
|
|
frametime = 1*DIGIT ":" 2DIGIT ":" 2DIGIT [ ":" 2DIGIT [ "." 2DIGIT ] ]</pre>
|
|
</div>
|
|
|
|
<p>Examples:</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.40 # => results in the time interval [120,121.5)
|
|
# (80 or 100 subframes per frame seem typical)</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 id="clock-time" name="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 typically with a live video stream. These are the same time codes
|
|
that are being used by RTSP <cite><a href="#rtsp">RFC 2326</a></cite>, by SMIL
|
|
<cite><a href="#smil30">SMIL</a></cite>, and by HTML5 <cite><a
|
|
href="#html5">HTML 5</a></cite>. 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", which includes
|
|
time zone capabilities. To that effect, the ABNF grammar is referring to
|
|
<cite><a href="#rfc3339">RFC 3339</a></cite>, which include the relevant part
|
|
of ISO 8601 in ABNF form. The time scheme identifier is "clock". </p>
|
|
|
|
<div class="exampleInner">
|
|
<a id="clocktimedef" name="clocktimedef"></a>
|
|
<pre>datetime = <date-time, defined in <cite><a href="#rfc3339">RFC 3339</a></cite>>
|
|
|
|
clocktimedef = clockformat ":"( clocktime [ "," clocktime ] ) / ( "," clocktime )
|
|
clockformat = %x63.6C.6F.63.6B ; "clock"
|
|
clocktime = (datetime / walltime / date)
|
|
|
|
; WARNING: if your date-time contains '+' (or any other reserved character, per <cite><a href="#rfc3986">RFC 3986</a></cite>),
|
|
; it should be percent-encoded when used in a URI.</pre>
|
|
</div>
|
|
|
|
<p>For convenience, the definition is copied here</p>
|
|
|
|
<div class="exampleInner">
|
|
<a id="datetime" name="datetime"></a>
|
|
<pre>; defined in <cite><a href="#rfc3339">RFC 3339</a></cite>
|
|
;
|
|
date-fullyear = 4DIGIT
|
|
date-month = 2DIGIT ; 01-12
|
|
date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on
|
|
; month/year
|
|
time-hour = 2DIGIT ; 00-23
|
|
time-minute = 2DIGIT ; 00-59
|
|
time-second = 2DIGIT ; 00-58, 00-59, 00-60 based on leap second
|
|
; rules
|
|
time-secfrac = "." 1*DIGIT
|
|
time-numoffset = ("+" / "-") time-hour ":" time-minute
|
|
time-offset = "Z" / time-numoffset
|
|
|
|
partial-time = time-hour ":" time-minute ":" time-second
|
|
[time-secfrac]
|
|
full-date = date-fullyear "-" date-month "-" date-mday
|
|
full-time = partial-time time-offset
|
|
|
|
date-time = full-date "T" full-time</pre>
|
|
</div>
|
|
|
|
<p>Examples:</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 id="naming-space" name="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>Pixels coordinates are interpreted after taking into account the resource's
|
|
dimensions, aspect ratio, clean aperture, resolution, and so forth, as defined
|
|
for the format used by the resource. If an anamorphic format does not define
|
|
how to apply the aspect ratio to the video data's dimensions to obtain the
|
|
"correct" dimensions, then the user agent must apply the ratio by increasing
|
|
one dimension and leaving the other unchanged. </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">
|
|
<a id="spacesegment" name="spacesegment"></a>
|
|
<pre>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"</pre>
|
|
</div>
|
|
|
|
<p>Examples:</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 id="naming-track" name="naming-track"></a>4.2.3 Track Dimension</h4>
|
|
|
|
<p>Track selection allows the extraction of tracks (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. Percent-escaping
|
|
can be used in the string to specify unsafe characters (including separators
|
|
such as semi-colon), see the grammar below for details. Multiple track
|
|
specification is allowed, but requires the specification of multiple track
|
|
parameters. 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">
|
|
<a id="tracksegment" name="tracksegment"></a>
|
|
<pre>trackprefix = %x74.72.61.63.6B ; "track"
|
|
trackparam = unistring</pre>
|
|
</div>
|
|
|
|
<p>Examples:</p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>track=1 # => results in only extracting track 1
|
|
track=video&track=subtitle # => results in extracting track 'video' and track 'subtitle'
|
|
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. Note that there are existing discovery mechanisms
|
|
for retrieving the track names of a media resource, such as the Rich Open
|
|
multitrack media Exposition format (ROE) <cite><a href="#roe">ROE</a></cite> or
|
|
the Media Annotations API <cite><a href="#mediaAnnotations">Media
|
|
Annotations</a></cite>. </p>
|
|
|
|
<table border="1" summary="Editorial note: Davy">
|
|
<tbody>
|
|
<tr>
|
|
<td width="50%" valign="top" align="left"><b>Editorial note: Davy</b></td>
|
|
<td width="50%" valign="top" align="right"> </td>
|
|
</tr>
|
|
<tr>
|
|
<td valign="top" align="left" colspan="2"><p>We can also reference the
|
|
HTML5 Media Multitrack API here, when it's mentioned in the HTML5 spec.
|
|
</p>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="naming-name" name="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 a 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">
|
|
<a id="namesegment" name="namesegment"></a>
|
|
<pre>nameprefix = %x69.64 ; "id"
|
|
nameparam = unistring</pre>
|
|
</div>
|
|
|
|
<p>Examples:</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 class="div3">
|
|
<h4><a id="common-syntax" name="common-syntax"></a>4.2.5 Common Syntax</h4>
|
|
|
|
<div class="exampleInner">
|
|
<pre>DIGIT = <DIGIT, defined in <cite><a href="#rfc5234">RFC 5234</a></cite>>
|
|
pchar = <pchar, defined in <cite><a href="#rfc3986">RFC 3986</a></cite>>
|
|
unreserved = <unreserved, defined in <cite><a href="#rfc3986">RFC 3986</a></cite>>
|
|
pct-encoded = <pct-encoded, defined in <cite><a href="#rfc3986">RFC 3986</a></cite>>
|
|
fragment = <pct-encoded, defined in <cite><a href="#rfc3986">RFC 3986</a></cite>>
|
|
|
|
unichar = <any Unicode code point>
|
|
unistring = *unichar</pre>
|
|
</div>
|
|
|
|
<p>For convenience, the following definitions are copied here. Only the
|
|
definitions in the original documents are considered normative</p>
|
|
|
|
<div class="exampleInner">
|
|
<a id="importeddefs" name="importeddefs"></a>
|
|
<pre>; defined in <cite><a href="#rfc5234">RFC 5234</a></cite>
|
|
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
|
|
DIGIT = %x30-39 ; 0-9
|
|
HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
|
|
|
|
; defined in <cite><a href="#rfc3986">RFC 3986</a></cite>
|
|
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
|
|
pct-encoded = "%" HEXDIG HEXDIG
|
|
sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="
|
|
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
|
|
fragment = *( pchar / "/" / "?" )</pre>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a id="media-fragment-processing" name="media-fragment-processing"></a>5
|
|
Media Fragments Processing</h2>
|
|
|
|
<p>This section defines the different exchange scenarios for the situations
|
|
explained in section <a href="#fragment-query"><b>3 URI fragment and URI
|
|
query</b></a> over the HTTP protocol. </p>
|
|
|
|
<p>The formal grammar defined in the section <a
|
|
href="#media-fragment-syntax"><b>4 Media Fragments Syntax</b></a> describes
|
|
what producers of media fragment should output. It is not taking into account
|
|
possible percent-encoding that are valid according to <cite><a
|
|
href="#rfc3986">RFC 3986</a></cite> and the grammar is not a specification of
|
|
how a media fragment should be parsed. Therefore, section <a
|
|
href="#processing-media-fragment-uri"><b>5.1 Processing Media Fragment
|
|
URI</b></a> defines how to parse media fragment URIs. </p>
|
|
|
|
<p>In a well known context where the MIME TYPE of the resource requested is
|
|
known, various recipes are proposed depending on the dimension addressed in the
|
|
media fragment URI, the container and codec formats used by the media resource,
|
|
or some advanced processing features implemented by the User Agent. Hence, if
|
|
the container format of the media resource is fully indexable (e.g. MP4, Ogg or
|
|
WebM) and if the time dimension is requested in the media fragment URI, the
|
|
User Agent MAY priviledge the recipe described in the section <a
|
|
href="#processing-protocol-frag"><b>5.2 Protocol for URI fragment Resolution in
|
|
HTTP</b></a> since it will be in a position of issuing directly a normal RANGE
|
|
request expressed in terms of byte ranges. On the other hand, if the container
|
|
format of the media resource is a legacy format such as AVI, the Use Agent MAY
|
|
priviledge the recipe described in the section <a
|
|
href="#processing-protocol-Server-mapped"><b>5.2.2 Server mapped byte
|
|
ranges</b></a>, issuing a RANGE request expressed with a custom unit such as
|
|
seconds and waiting for the server to provide the mapping in terms of byte
|
|
ranges. Finally, if the track dimension is requested in the media fragment URI,
|
|
the User Agent MAY priviledge the recipe described in the section <a
|
|
href="#server-triggered-redirect"><b>5.2.3 Server triggered redirect</b></a>.
|
|
</p>
|
|
|
|
<p>The User Agent MAY also implement a so-called optimistic processing of URI
|
|
fragments in particular cases where the MIME TYPE of the resource requested is
|
|
not yet known. Hence, if a URL fragment occurs within a particular context such
|
|
as the value of the @src attribute of a media element (audio, video or source)
|
|
and if the time dimension is requested in the media fragment URI, the User
|
|
Agent MAY follow the scenario specified in section <a
|
|
href="#processing-protocol-Server-mapped"><b>5.2.2 Server mapped byte
|
|
ranges</b></a> and issues directly a range request using custom units assuming
|
|
that the resource requested is likely to be a media resource. If the MIME-type
|
|
of this resource turns out to be a media type, the server SHOULD interpret the
|
|
RANGE request as specified in section <a
|
|
href="#processing-protocol-Server-mapped"><b>5.2.2 Server mapped byte
|
|
ranges</b></a>. Otherwise it SHOULD just ignore the RANGE header. </p>
|
|
|
|
<div class="div2">
|
|
<h3><a id="processing-media-fragment-uri"
|
|
name="processing-media-fragment-uri"></a>5.1 Processing Media Fragment URI</h3>
|
|
|
|
<p>This sections defines how to parse media fragment URIs defined in section <a
|
|
href="#media-fragment-syntax"><b>4 Media Fragments Syntax</b></a>, along with
|
|
notes on some of the caveats to be aware of. Implementors are free to use any
|
|
equivalent technique(s). </p>
|
|
|
|
<table border="1" summary="Editorial note: Raphael">
|
|
<tbody>
|
|
<tr>
|
|
<td width="50%" valign="top" align="left"><b>Editorial note:
|
|
Raphael</b></td>
|
|
<td width="50%" valign="top" align="right"> </td>
|
|
</tr>
|
|
<tr>
|
|
<td valign="top" align="left" colspan="2">To generate a simple figure
|
|
that shows this processing: URI parsing (percent decoding) =>
|
|
name=value pairs => (rfc2047encoding) HTTP </td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<div class="div3">
|
|
<h4><a id="processing-name-value-components"
|
|
name="processing-name-value-components"></a>5.1.1 Processing name-value
|
|
components</h4>
|
|
|
|
<p>This section defines how to convert an octet string (from the query or
|
|
fragment component of a URI) into a list of name-value Unicode string pairs.
|
|
</p>
|
|
<ol class="enumar">
|
|
<li><p>Parse the octet string according to the <a
|
|
href="#namevalues">namevalues</a> syntax, yielding a list of name-value
|
|
pairs, where name and value are both octet string. In accordance with
|
|
<cite><a href="#rfc3986">RFC 3986</a></cite>, the name and value components
|
|
must be parsed and separated before percent-encoded octets are decoded. </p>
|
|
</li>
|
|
<li><p>For each name-value pair: </p>
|
|
<ol class="enumla">
|
|
<li><p>Decode percent-encoded octets in name and value as defined by
|
|
<cite><a href="#rfc3986">RFC 3986</a></cite>. If either name or value
|
|
are not valid percent-encoded strings, then remove the name-value pair
|
|
from the list. </p>
|
|
</li>
|
|
<li><p>Convert name and value to Unicode strings by interpreting them as
|
|
<cite><a href="#utf-8">UTF-8</a></cite>. If either name or value are
|
|
not valid UTF-8 strings, then remove the name-value pair from the list.
|
|
</p>
|
|
</li>
|
|
</ol>
|
|
</li>
|
|
</ol>
|
|
|
|
<p>Note that the output is well defined for any input. </p>
|
|
|
|
<p>Examples: </p>
|
|
|
|
<table border="1">
|
|
<tbody>
|
|
<tr>
|
|
<th>Input</th>
|
|
<th>Output</th>
|
|
<th>Notes</th>
|
|
</tr>
|
|
<tr>
|
|
<td>"t=1"</td>
|
|
<td>[("t", "1")]</td>
|
|
<td>simple case</td>
|
|
</tr>
|
|
<tr>
|
|
<td>"t=1&t=2"</td>
|
|
<td>[("t", "1"), ("t", "2")]</td>
|
|
<td>repeated name</td>
|
|
</tr>
|
|
<tr>
|
|
<td>"a=b=c"</td>
|
|
<td>[("a", "b=c")]</td>
|
|
<td>"=" in value</td>
|
|
</tr>
|
|
<tr>
|
|
<td>"a&b=c"</td>
|
|
<td>[("a", ""), ("b", "c")]</td>
|
|
<td>missing value</td>
|
|
</tr>
|
|
<tr>
|
|
<td>"%74=%6ept%3A%310"</td>
|
|
<td>[("t", "npt:10")]</td>
|
|
<td>unnecssary percent-encoding</td>
|
|
</tr>
|
|
<tr>
|
|
<td>"id=%xy&t=1"</td>
|
|
<td>[("t", "1")]</td>
|
|
<td>invalid percent-encoding</td>
|
|
</tr>
|
|
<tr>
|
|
<td>"id=%E4r&t=1"</td>
|
|
<td>[("t", "1")]</td>
|
|
<td>invalid UTF-8</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<p>While the processing defined in this section is designed to be largely
|
|
compatible with the parsing of the URI query component in many HTTP server
|
|
environments, there are incompatible differences that implementors should be
|
|
aware of: </p>
|
|
<ul>
|
|
<li><p>"&" is the only primary separator for name-value pairs, but some
|
|
server-side languages also treat ";" as a separator. </p>
|
|
</li>
|
|
<li><p>name-value pairs with invalid percent-encoding should be ignored, but
|
|
some server-side languages silently mask such errors. </p>
|
|
</li>
|
|
<li><p>The "+" character should not be treated specially, but some
|
|
server-side languages replace it with a space (" ") character. </p>
|
|
</li>
|
|
<li><p>Multiple occurrences of the same name must be preserved, but some
|
|
server-side languages only preserve the last occurrence. </p>
|
|
</li>
|
|
</ul>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="processing-name-value-lists"
|
|
name="processing-name-value-lists"></a>5.1.2 Processing name-value lists</h4>
|
|
|
|
<p>This section defines how to convert a list of name-value Unicode string
|
|
pairs into the media fragment dimensions. </p>
|
|
|
|
<p>Given the dimensions defined in section <a
|
|
href="#fragment-dimensions"><b>4.2 Fragment Dimensions</b></a>, each has a pair
|
|
of production rules that corresponds to the name and value component
|
|
respectively: </p>
|
|
|
|
<table border="1">
|
|
<tbody>
|
|
<tr>
|
|
<th>Keyword</th>
|
|
<th>Dimension</th>
|
|
</tr>
|
|
<tr>
|
|
<td>t</td>
|
|
<td><a href="#naming-time"><b>4.2.1 Temporal Dimension</b></a></td>
|
|
</tr>
|
|
<tr>
|
|
<td>xywh</td>
|
|
<td><a href="#naming-space"><b>4.2.2 Spatial Dimension</b></a></td>
|
|
</tr>
|
|
<tr>
|
|
<td>track</td>
|
|
<td><a href="#naming-track"><b>4.2.3 Track Dimension</b></a></td>
|
|
</tr>
|
|
<tr>
|
|
<td>id</td>
|
|
<td><a href="#naming-name"><b>4.2.4 Named Dimension</b></a></td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
<ol class="enumar">
|
|
<li><p>Initially, all dimension are undefined. </p>
|
|
</li>
|
|
<li><p>For each name-value pair: </p>
|
|
<ol class="enumla">
|
|
<li><p>If name matches a keyword in the above table, interpret value as
|
|
per the corresponding section. </p>
|
|
</li>
|
|
<li><p>Otherwise, the name-value pair does not represent a media fragment
|
|
dimension. Validators should emit a warning. User agents must ignore
|
|
the name-value pair. </p>
|
|
</li>
|
|
</ol>
|
|
</li>
|
|
</ol>
|
|
|
|
<p>Note: Because the name-value pairs are processed in order, the last valid
|
|
occurence of any dimension is the one that is used. </p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="processing-protocol-frag" name="processing-protocol-frag"></a>5.2
|
|
Protocol for URI fragment Resolution in HTTP</h3>
|
|
|
|
<p>This section defines the protocol steps in HTTP <cite><a href="#rfc2616">RFC
|
|
2616</a></cite> to resolve and deliver a media fragment specified as a URI
|
|
fragment.</p>
|
|
|
|
<div class="div3">
|
|
<h4><a id="processing-protocol-UA-mapped"
|
|
name="processing-protocol-UA-mapped"></a>5.2.1 UA mapped byte ranges</h4>
|
|
|
|
<table border="1" summary="Editorial note">
|
|
<tbody>
|
|
<tr>
|
|
<td width="50%" valign="top" align="left"><b>Editorial note</b></td>
|
|
<td width="50%" valign="top" align="right"> </td>
|
|
</tr>
|
|
<tr>
|
|
<td valign="top" align="left" colspan="2"><p>This section is ready to
|
|
implement.</p>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<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. This is the case
|
|
typically where a user agent has already downloaded those parts of a media
|
|
resource that allow it to do or guess the mapping, e.g. headers or a resource,
|
|
or an index of a resource. </p>
|
|
|
|
<p>In this case, the HTTP exchanges are exactly the same as for any other Web
|
|
resource where byte ranges are requested <cite><a href="#rfc2616">RFC
|
|
2616</a></cite>. </p>
|
|
|
|
<p>How the UA retrieves the byte ranges is dependent on the media type of the
|
|
media resource. We here show examples with only one byte range retrieval per
|
|
time range, which may in practice turn into several such retrieval actions
|
|
necessary to acquire the correct time range. </p>
|
|
|
|
<p>Here are the three principle cases a media fragment enabled UA and a media
|
|
Server will encounter:</p>
|
|
|
|
<div class="div4">
|
|
<h5><a id="processing-protocol-UA-mapped-new"
|
|
name="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>
|
|
<img
|
|
src="MF-SD-ClientSide-5.2.1.1.png"
|
|
alt="Illustration of a UA requesting a URI fragment for the first time" /></div>
|
|
|
|
<div class="div4">
|
|
<h5><a id="processing-protocol-UA-mapped-unchanged"
|
|
name="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>
|
|
<img
|
|
src="MF-SD-ClientSide-5.2.1.2.png"
|
|
alt="Illustration of a UA requesting a URI fragment it already has buffered"
|
|
/></div>
|
|
|
|
<div class="div4">
|
|
<h5><a id="processing-protocol-UA-mapped-changed"
|
|
name="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>
|
|
<img
|
|
src="MF-SD-ClientSide-5.2.1.3.png"
|
|
alt="Illustration of a UA requesting a URI fragment it has buffered, but that changed"
|
|
/></div>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="processing-protocol-Server-mapped"
|
|
name="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
|
|
fragment-to-byte mapping themselves, because the mapping is not obvious. This
|
|
typically applies to media formats where the setup of the decoding pipeline
|
|
does not imply knowledge of how to map fragments to byte ranges, e.g. Ogg
|
|
without OggIndex. Thus, the User Agent would be capable of decoding a
|
|
continuous resource, but would not know which bytes to request for a media
|
|
fragment. </p>
|
|
|
|
<p>In this case, the User Agent could either guess what byte ranges it has to
|
|
retrieve and the retrieval action would follow the previous case. Or it could
|
|
hope that the server provides a special service, which would allow it to
|
|
retrieve the byte ranges with a simple request of the media fragment ranges.
|
|
Thus, the HTTP request of the User Agent will include a request for the
|
|
fragment hoping that the server can do the byte range mapping and send back the
|
|
appropriate byte ranges. This is realized by introducing new dimensions for the
|
|
HTTP Range header, next to the byte dimension. </p>
|
|
|
|
<p>The specification for all new Range Request Header dimensions is given
|
|
through the following ABNF as an extension to the HTTP Range Request Header
|
|
definition (see
|
|
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35.2): </p>
|
|
|
|
<div class="exampleInner">
|
|
<a id="rangerequestheaderdef" name="rangerequestheaderdef"></a>
|
|
<pre>Range = "Range" ":" ranges-specifier
|
|
ranges-specifier = byte-ranges-specifier | fragment-specifier
|
|
;
|
|
; note that ranges-specifier is extended from <cite><a href="#rfc2616">RFC 2616</a></cite>
|
|
; to cover alternate fragment range specifiers
|
|
;
|
|
fragment-specifier = "include-setup" | fragment-range *( "," fragment-range )
|
|
[ ";" "include-setup" ]
|
|
fragment-range = time-ranges-specifier | track-ranges-specifier | name-ranges-specifier
|
|
;
|
|
; note that this doesn't capture the restriction to one fragment dimension occurring
|
|
; maximally once only in the fragment-specifier definition.
|
|
;
|
|
time-ranges-specifier = npttimeoption / smptetimeoption / clocktimeoption
|
|
npttimeoption = pfxdeftimeformat "=" npt-sec "-" [ npt-sec ]
|
|
smptetimeoption = pfxsmpteformat "=" frametime "-" [ frametime ]
|
|
clocktimeoption = pfxclockformat "=" datetime "-" [ datetime ]
|
|
|
|
track-ranges-specifier = trackprefix "=" trackparam *( ";" trackparam )
|
|
|
|
name-ranges-specifier = nameprefix "=" nameparam</pre>
|
|
</div>
|
|
|
|
<p>This specification is meant to be analogous to the one in URIs, but it is a
|
|
bit stricter. The time unit is not optional. For instance, it can be "npt",
|
|
"smpte", "smpte-25", "smpte-30", "smpte-30-drop" or "clock" for temporal. Where
|
|
"ntp" is used for a temporal range, only specification in seconds is possible.
|
|
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 basically become
|
|
required in the Range header. </p>
|
|
|
|
<p>There is an optional 'include-setup' flag on the fragment range specifier -
|
|
this flag signals to the server whether delivery of the decoder setup
|
|
information (i.e. typically file header information) is also required as part
|
|
of the reply to this request. This can help avoid an extra roundtrip where a
|
|
Media Fragment URI is, e.g. directly typed into a Web browser. </p>
|
|
|
|
<p>If there were multiple track parameters provided in the media fragment URI,
|
|
they are all aggregated together here in a single track ranges specifier, where
|
|
the track names are separated by semi-colon. Note that if a track name did
|
|
include a semi-colon in the media fragment URI, it is now percent escaped. </p>
|
|
|
|
<p>Note that the specification does not foresee a Range dimension for spatial
|
|
media fragments since they are typically resolved and interpreted by the User
|
|
Agent (i.e., spatial fragment extraction is not performed on server-side) for
|
|
the following reasons: </p>
|
|
<ul>
|
|
<li><p>spatial media fragments are typically not expressible in terms of byte
|
|
ranges. Spatial fragment extraction would thus require transcoding
|
|
operations resulting in new resources rather than fragments of the original
|
|
media resource. As described in section <a href="#fragment-query"><b>3 URI
|
|
fragment and URI query</b></a>, spatial fragment extraction is in this case
|
|
better represented by URI queries. </p>
|
|
</li>
|
|
<li><p>When a User Agent receives an extracted spatial media fragment, it is
|
|
not trivial to visualize the context of this fragment (see also section <a
|
|
href="#media-fragment-display"><b>7.2 Clients Displaying Media
|
|
Fragments</b></a>). More specifically, spatial context requires a
|
|
meaningful background, which will not be available at the User Agent when
|
|
the spatial fragment is extracted by the server. </p>
|
|
</li>
|
|
</ul>
|
|
|
|
<table border="1" summary="Editorial note: Davy">
|
|
<tbody>
|
|
<tr>
|
|
<td width="50%" valign="top" align="left"><b>Editorial note: Davy</b></td>
|
|
<td width="50%" valign="top" align="right"> </td>
|
|
</tr>
|
|
<tr>
|
|
<td valign="top" align="left" colspan="2"><p>Special attention should be
|
|
paid for named fragments and more specifically when a named fragment
|
|
represents a spatial fragment. We should clearly describe 1. what named
|
|
fragments are and 2. how they are resolved.</p>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<p>Next to the introduction of new dimensions for the HTTP Range request
|
|
header, we also introduce a new HTTP response header, called
|
|
Content-Range-Mapping, which provides the mapping of the retrieved byte range
|
|
to the original Range request, which was not in bytes. It serves two
|
|
purposes:</p>
|
|
<ul>
|
|
<li><p>It Indicates the actual mapped range in terms of fragment dimensions.
|
|
This is necessary since the server might not be able to provide a byte
|
|
range mapping that corresponds exactly to the requested range. Therefore,
|
|
the User Agent needs to be aware of this variance. </p>
|
|
</li>
|
|
<li><p>It provides context information regarding the parent resource in case
|
|
the Range request contained a temporal dimension. More specifically, the
|
|
header contains the start and end time of the parent resource. This way,
|
|
the User Agent is able to understand and visualize the temporal context of
|
|
the media fragment. </p>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>The specification for the Content-Range-Mapping header is based on the
|
|
specification of the Content-Range header (see
|
|
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.16) and is shown
|
|
below. Note that the Content-Range-Mapping header adds in case of the temporal
|
|
dimension the instance start and end in terms of seconds after a slash "/"
|
|
character in analogy to the Content-Range header. Also, we introduce an
|
|
extension to the Accept-Ranges header (see
|
|
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.5). </p>
|
|
|
|
<div class="exampleInner">
|
|
<a id="contentrangemappingheaderdef" name="contentrangemappingheaderdef"></a>
|
|
<pre>Content-Range-Mapping = "Content-Range-Mapping" ":" '{'
|
|
( content-range-mapping-spec [ ";" def-include-setup ] ) / def-include-setup
|
|
'}' '=' '{'
|
|
byte-content-range-mapping-spec '}'
|
|
|
|
def-include-setup = %x69.6E.63.6C.75.64.65.2D.73.65.74.75.70 ; "include-setup"
|
|
|
|
byte-range-mapping-spec = bytes-unit SP
|
|
byte-range-resp-spec *( "," byte-range-resp-spec ) "/"
|
|
( instance-length / "*" )
|
|
|
|
content-range-mapping-spec = time-mapping-spec | track-mapping-spec | name-mapping-spec
|
|
time-mapping-spec = timeprefix ":" time-mapping-options
|
|
time-mapping-options = npt-mapping-option / smpte-mapping-option / clock-mapping-option
|
|
npt-mapping-option = deftimeformat SP npt-sec "-" npt-sec "/"
|
|
[ npt-sec ] "-" [ npt-sec ]
|
|
smpte-mapping-option = smpteformat SP frametime "-" frametime "/"
|
|
[ frametime ] "-" [ frametime ]
|
|
clock-mapping-option = clockformat SP datetime "-" datetime "/"
|
|
[ datetime ] "-" [ datetime ]
|
|
|
|
track-mapping-spec = trackprefix SP trackparam *( ";" trackparam )
|
|
|
|
name-mapping-spec = nameprefix SP nameparam
|
|
|
|
Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges
|
|
acceptable-ranges = 1#range-unit *( "," 1#range-unit )| "none"
|
|
;
|
|
; note this does not represent the restriction that range-units can only appear once at most
|
|
;
|
|
range-unit = bytes-unit | other-range-unit
|
|
bytes-unit = "bytes"
|
|
other-range-unit = token | timeprefix | trackprefix | nameprefix</pre>
|
|
</div>
|
|
|
|
<p>Three cases can be distinguished when a User Agent needs assistance by a
|
|
server to perform the byte range mapping. In the next subsections, we'll go
|
|
through the protocol exchange action step by step. </p>
|
|
|
|
<div class="div4">
|
|
<h5><a id="processing-protocol-server-mapped-default"
|
|
name="processing-protocol-server-mapped-default"></a>5.2.2.1 Server mapped byte
|
|
ranges with corresponding binary data</h5>
|
|
<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. If the requested fragment is not available in its buffer, the
|
|
UA sends an HTTP request to the server, including a Range header with temporal
|
|
dimension. The request is shown below: </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>If the server does not understand a Range header, it MUST ignore the header
|
|
field that includes that range-set. This is in sync to the HTTP RFC <cite><a
|
|
href="#rfc2616">RFC 2616</a></cite>. This means that where a server does not
|
|
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 <cite><a href="#rfc2616">RFC 2616</a></cite>.
|
|
</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, track, id
|
|
Content-Length: 3743
|
|
Content-Type: video/ogg
|
|
Content-Range: bytes 19147-22880/35614993
|
|
Content-Range-Mapping: { t:npt 9.85-21.16/0.0-653.79 } = { bytes 19147-22880/35614993 }
|
|
Etag: "b7a60-21f7111-46f3219476580"
|
|
|
|
{binary data}</pre>
|
|
</div>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>Note the presence of the new reply header called Content-Range-Mapping,
|
|
which provides the mapping of the retrieved byte range to the original
|
|
Content-Range request, which was not in bytes. 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. Also note that through the extended list in the
|
|
Accept-Ranges it is possible to identify which fragment schemes a server
|
|
supports. </p>
|
|
<img
|
|
src="MF-SD-ServerSide.png"
|
|
alt="Illustration of a UA requesting a URI time to byte range mapping from the server "
|
|
/>
|
|
|
|
<p>In the case where a media fragment results in a multipart message-body, the
|
|
Content-Range headers will be spread throughout the binary data ranges, but the
|
|
Content-Range-Mapping of the media fragment will only be with the main header.
|
|
Note that requesting track fragments typically result in multipart
|
|
message-bodies, on condition that the parent resource is characterized by
|
|
interleaved tracks. 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, track, id
|
|
Content-Length: 3743
|
|
Content-Type: video/ogg
|
|
Content-Range-Mapping: { track audio1;video1 } = { bytes 123-2589, 14560-27891,58909-81230/35614993 }
|
|
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 <cite><a
|
|
href="#rfc2616">RFC 2616</a></cite>. Thus, the new Range requests won't be
|
|
cached by legacy Web proxies. </p>
|
|
</div>
|
|
|
|
<div class="div4">
|
|
<h5><a id="processing-protocol-server-mapped-setup"
|
|
name="processing-protocol-server-mapped-setup"></a>5.2.2.2 Server mapped byte
|
|
ranges with corresponding binary data and codec setup data</h5>
|
|
|
|
<p>When the User Agent needs help from the server to setup the initial decoding
|
|
pipeline (i.e., the User Agent has no codec setup information at its disposal),
|
|
the User Agent can request, next to the bytes corresponding to the requested
|
|
fragment, the bytes necessary to setup its decoder. This is possible by adding
|
|
the 'include-setup' flag to the Range header, as illustrated below: </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;include-setup</pre>
|
|
</div>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>Analogous to section <a
|
|
href="#processing-protocol-server-mapped-default"><b>5.2.2.1 Server mapped byte
|
|
ranges with corresponding binary data</b></a>, the server can map the given
|
|
Range to one or more byte ranges, it will reply with these in a 206 HTTP
|
|
response. Additionally, the server adds the bytes corresponding with the
|
|
requested setup information to the response. Since this setup information
|
|
usually appears in front of a media resource, the response typically results in
|
|
a multipart message-body. The response is shown below: </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, track, id
|
|
Content-Length: 3795
|
|
Content-Type: video/ogg
|
|
Content-Range-Mapping: { t:npt 11.85-21.16/0.0-653.79;include-setup } = { bytes 0-52,19147-22880/35614993 }
|
|
Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
|
|
Etag: "b7a60-21f7111-46f3219476580"
|
|
|
|
--THIS_STRING_SEPARATES
|
|
Content-type: video/ogg
|
|
Content-Range: bytes 0-52/35614993
|
|
{binary data}
|
|
--THIS_STRING_SEPARATES
|
|
Content-type: video/ogg
|
|
Content-Range: bytes 19147-22880/35614993
|
|
{binary data}
|
|
--THIS_STRING_SEPARATES--</pre>
|
|
</div>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>Note that the Content-Range-Mapping header indicates that the codec setup
|
|
information is included in the response. In this example, the response consists
|
|
of two parts of byte ranges: the first part corresponds to the setup
|
|
information, the second part corresponds to the requested fragment. </p>
|
|
<img
|
|
src="MF-SD-ServerSideSetup.png"
|
|
alt="Illustration of a UA requesting a URI time to byte range mapping from the server, including the codec setup information "
|
|
/></div>
|
|
|
|
<div class="div4">
|
|
<h5><a id="processing-protocol-server-mapped-proxy"
|
|
name="processing-protocol-server-mapped-proxy"></a>5.2.2.3 Proxy cacheable
|
|
server mapped byte ranges</h5>
|
|
|
|
<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
|
|
cacheable, we introduce some extra HTTP headers, which will help tell the
|
|
server and the proxy what to do. There is an Accept-Range-Redirect request
|
|
header which signals to the server that only a redirect to the correct byte
|
|
ranges is necessary and the result should be delivered in the Range-Redirect
|
|
header. </p>
|
|
|
|
<p>The ABNF for these additional two HTTP headers is given as follows:</p>
|
|
|
|
<div class="exampleInner">
|
|
<a id="rangeredirectdefs" name="rangeredirectdefs"></a>
|
|
<pre>Accept-Range-Redirect = "Accept-Range-Redirect" ":" bytes-unit
|
|
|
|
Range-Redirect = "Range-Redirect" ":" byte-range-resp-spec *( "," byte-range-resp-spec )</pre>
|
|
</div>
|
|
|
|
<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.
|
|
</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, track, id
|
|
Content-Length: 0
|
|
Content-Type: video/ogg
|
|
Content-Range-Mapping: { t:npt 11.85-21.16/0.0-653.79 } = { bytes 19147-22880/* }
|
|
Range-Redirect: 19147-22880
|
|
Vary: Accept-Range-Redirect</pre>
|
|
</div>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>Note that codec setup information can also be requested in combination with
|
|
the Accept-Range-Redirect header, which can be realized by adding the
|
|
'include-setup' flag to the Range request header. </p>
|
|
|
|
<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, track, id
|
|
Content-Length: 3743
|
|
Content-Type: video/ogg
|
|
Content-Range: bytes 19147-22880/35614993
|
|
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>
|
|
<img
|
|
src="MF-SD-ProxyCacheable.png"
|
|
alt="Illustration of a UA requesting a URI time to byte range mapping from the server with proxy capability of byte ranges"
|
|
/></div>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="server-triggered-redirect"
|
|
name="server-triggered-redirect"></a>5.2.3 Server triggered redirect</h4>
|
|
|
|
<p>When a server decides not to serve the requested media fragment in terms of
|
|
byte ranges (i.e., serving the requested media fragment as specified in section
|
|
<a href="#processing-protocol-Server-mapped"><b>5.2.2 Server mapped byte
|
|
ranges</b></a>), it can redirect the UA to a representation of this fragment
|
|
(for instance by transforming the media fragment URI into a media fragment
|
|
query, as specified in section <a href="#processing-protocol-query"><b>5.3
|
|
Protocol for URI query Resolution in HTTP</b></a>). This is particularly useful
|
|
in cases where too many byte ranges would need to e extracted to satisfy the
|
|
range request. </p>
|
|
|
|
<p>A user requests a media fragment URI using a URI fragment:</p>
|
|
<ul>
|
|
<li><p>User → UA (1):</p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>http://www.example.com/video.ogv#track=video1</pre>
|
|
</div>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>Subsequently, the UA requests the media fragment from the server using the
|
|
Range header:</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: track=video1</pre>
|
|
</div>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>The server decides not to serve the requested media fragment in terms of
|
|
byte ranges (for instance, because the track media fragment results in too many
|
|
byte ranges). The server redirects the UA to an alternate representation. For
|
|
example, the URI fragment can be transformed into a URI query. Further, a Link
|
|
header is added stating that the redirected location is a fragment of the
|
|
originally requested resource. </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?track=video1
|
|
Accept-Ranges: bytes, t, track, id
|
|
Content-Length: 0
|
|
Content-Type: video/ogg
|
|
Link: <http://www.example.com/video.ogv#track=video1>; rel="fragment"
|
|
Vary: *</pre>
|
|
</div>
|
|
</li>
|
|
</ul>
|
|
|
|
<table border="1" summary="Editorial note: Davy">
|
|
<tbody>
|
|
<tr>
|
|
<td width="50%" valign="top" align="left"><b>Editorial note: Davy</b></td>
|
|
<td width="50%" valign="top" align="right"> </td>
|
|
</tr>
|
|
<tr>
|
|
<td valign="top" align="left" colspan="2"><p>We need to register the
|
|
'fragment' Link Relation <cite><a href="#webLinking">Web
|
|
Linking</a></cite>. </p>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<p>Finally, the UA follows the redirect, which in this case corresponds to the
|
|
process specified in section <a href="#processing-protocol-query"><b>5.3
|
|
Protocol for URI query Resolution in HTTP</b></a>.</p>
|
|
|
|
<p>The server can also decide to combine a redirect and a media fragment
|
|
URI:</p>
|
|
<ul>
|
|
<li><p>User → UA (1):</p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>http://www.example.com/video.ogv#track=video1&t=10,20</pre>
|
|
</div>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>The UA requests the media fragment to the server using the Range header:</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: track=video1,t:npt=10-20</pre>
|
|
</div>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>The server decides not to serve the requested media fragment in terms of
|
|
byte ranges and redirects the UA to an alternate representation. However, in
|
|
this case, the server decides to handle the track fragment through a URI query
|
|
and the temporal fragment through a URI fragment: </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?track=video1#t=10,20
|
|
Accept-Ranges: bytes, t, track, id
|
|
Content-Length: 0
|
|
Content-Type: video/ogg
|
|
Link: <http://www.example.com/video.ogv#track=video1&t=10,20>; rel="fragment"
|
|
Vary: *</pre>
|
|
</div>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>Finally, the UA follows the redirect, which in this case corresponds to the
|
|
process specified in section <a href="#processing-protocol-query"><b>5.3
|
|
Protocol for URI query Resolution in HTTP</b></a> for the track fragment,
|
|
combined with the process specified in section <a
|
|
href="#processing-protocol-Server-mapped"><b>5.2.2 Server mapped byte
|
|
ranges</b></a> for the temporal fragment. </p>
|
|
<img
|
|
src="MF-SD-ServerTriggeredRedirect.png"
|
|
alt="Illustration of a UA requesting a combined track and temporal media fragment URI and a server using a server triggered redirect."
|
|
/></div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="processing-protocol-query" name="processing-protocol-query"></a>5.3
|
|
Protocol for URI query Resolution in HTTP</h3>
|
|
|
|
<p>This section describes the protocol steps used in HTTP <cite><a
|
|
href="#rfc2616">RFC 2616</a></cite> 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"
|
|
Link: <http://www.example.com/video.ogv#t=10,20>; rel="alternate"
|
|
|
|
{binary data}</pre>
|
|
</div>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>Note that a Link header MAY be provided indicating the relationship between
|
|
the requested URI query and the original media fragment URI. This 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 ones created by the query.</p>
|
|
|
|
<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>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-server-mapped-proxy"><b>5.2.2.3 Proxy cacheable
|
|
server mapped byte ranges</b></a>.</p>
|
|
|
|
<p>Note that a server that does not 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>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a id="media-fragment-semantics" name="media-fragment-semantics"></a>6
|
|
Media Fragments Semantics</h2>
|
|
|
|
<p>Errors can occur at several levels:</p>
|
|
<ul>
|
|
<li>the complete URI (e.g. spatial dimension on a audio resource)</li>
|
|
<li>the combination of name-value strings (e.g. name and time dimension
|
|
combined)</li>
|
|
<li>the name-value string (e.g. invalid percent-encoding)</li>
|
|
<li>the name dimension (e.g. undefined dimension)</li>
|
|
<li>the value (e.g. invalid NPT syntax)</li>
|
|
</ul>
|
|
|
|
<p>We will look at errors in the different dimensions and their values in the
|
|
subsequent sub-sections and we will start with errors on the more general
|
|
levels. </p>
|
|
|
|
<div class="div2">
|
|
<h3><a id="error-general" name="error-general"></a>6.1 Errors on the General
|
|
URI level</h3>
|
|
|
|
<div class="div3">
|
|
<h4><a id="error-general-non-existent"
|
|
name="error-general-non-existent"></a>6.1.1 Non-existent dimension:</h4>
|
|
|
|
<p>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>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="error-general-underspec" name="error-general-underspec"></a>6.1.2
|
|
Under-specified Dimension</h4>
|
|
|
|
<p>The result of doing spatial clipping on a media resource that has multiple
|
|
video tracks is that the spatial clipping is applied to all tracks. </p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="error-temporal" name="error-temporal"></a>6.2 Errors on the temporal
|
|
dimensions</h3>
|
|
|
|
<p>Assuming a single temporal dimension is present, we now analyse what
|
|
fragment values may be specified here and how they should be handled. </p>
|
|
|
|
<p>For this, we make the following definitions: </p>
|
|
<ul>
|
|
<li>s: the start point of the media and s >= 0</li>
|
|
<li>e: the end point of the media (i.e. duration = e - s ) and s < e</li>
|
|
<li>a: a positive integer, a >= 0</li>
|
|
<li>b: a positive integer, b >= 0</li>
|
|
</ul>
|
|
|
|
<div class="div3">
|
|
<h4><a id="error-temporal-valid" name="error-temporal-valid"></a>6.2.1 Valid
|
|
requests</h4>
|
|
|
|
<p>For t=a,b with a <= b</p>
|
|
<ul>
|
|
<li>t=, results in the HTTP status code 206: deliver from s to e</li>
|
|
<li>t=a, with s <= a, a < e results in the HTTP status code 206:
|
|
deliver from a to e</li>
|
|
<li>t=a, or t=a with a < s results in the HTTP status code 206: deliver
|
|
from s to e</li>
|
|
<li>t=,b with s < b, b <= e results in the HTTP status code 206:
|
|
deliver from s to b</li>
|
|
<li>t=,b with e < b results in the HTTP status code 206: deliver from s to
|
|
e</li>
|
|
<li>t=a,b with s = a, b = e restulst in the HTTP status code 206: deliver
|
|
from s to e</li>
|
|
<li>t=a,b with s <= a, a < b, a < e and b <= e results in the
|
|
HTTP status code 206: deliver from a to b (the normal case)</li>
|
|
<li>t=a,b with s <= a, a < b, a < e and e < b results in the HTTP
|
|
status code 206: deliver from a to e</li>
|
|
<li>t=a,b with a < s, a < b, s < b and b <= e results in the HTTP
|
|
status code 206: deliver from s to b</li>
|
|
<li>t=a,b with a < s, a < b and e < b results in the HTTP status
|
|
code 206: deliver from s to e</li>
|
|
<li>%74=10,20 resolve percent encoding to t=10,20</li>
|
|
<li>t=%31%30 resolve percent encoding to t=10</li>
|
|
<li>t=10%2C20 resolve percent encoding to t=10,20</li>
|
|
<li>t=%6ept:10 resolve percent encoding to t=npt:10</li>
|
|
<li>t=npt%3a10 resolve percent encoding to t=npt:10</li>
|
|
</ul>
|
|
|
|
<table border="1" summary="Editorial note: Raphael">
|
|
<tbody>
|
|
<tr>
|
|
<td width="50%" valign="top" align="left"><b>Editorial note:
|
|
Raphael</b></td>
|
|
<td width="50%" valign="top" align="right"> </td>
|
|
</tr>
|
|
<tr>
|
|
<td valign="top" align="left" colspan="2"><p>The following paragraph is
|
|
controversial since it could lead to non-interoperable
|
|
implementations.</p>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<table border="1" summary="Editorial note: Silvia">
|
|
<tbody>
|
|
<tr>
|
|
<td width="50%" valign="top" align="left"><b>Editorial note:
|
|
Silvia</b></td>
|
|
<td width="50%" valign="top" align="right"> </td>
|
|
</tr>
|
|
<tr>
|
|
<td valign="top" align="left" colspan="2"><p>If the UA needs to retrieve
|
|
a large part of the resource or even the full resource, it will
|
|
probably decide to make multiple range requests rather than a single
|
|
one. If the resource is, however, small, it may decide to just retrieve
|
|
the full resource without a range request. The UA should make this
|
|
choice given context information, e.g. if it knows that it will be a
|
|
lot of data, it will retrieve it in smaller chunks. If it chooses to
|
|
request the full resource in one go and not make use of a Range
|
|
request, the result will be a 200 rather than a 206. </p>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="error-temporal-empty" name="error-temporal-empty"></a>6.2.2
|
|
Empty</h4>
|
|
|
|
<p>The resolved time segment is empty.</p>
|
|
<ul>
|
|
<li>t=a,a results in a HTTP Range request with 'include-setup' as specified
|
|
in section <a href="#processing-protocol-server-mapped-setup"><b>5.2.2.2
|
|
Server mapped byte ranges with corresponding binary data and codec setup
|
|
data</b></a> unless the UA is already set up for this resource in which
|
|
case it will not undertake an unnecessary retrieval request. Results in 206
|
|
for the setup data.</li>
|
|
</ul>
|
|
|
|
<p>Effect: retrieve whatever the browser needs to set up playback, but
|
|
otherwise nothing</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="error-temporal-non-existent"
|
|
name="error-temporal-non-existent"></a>6.2.3 Non-existent</h4>
|
|
|
|
<p>The value resolves to a non-existent fragment. </p>
|
|
|
|
<p>If the UA is already set up for decoding the resource and it can identify
|
|
that the fragment is non-existent (i.e. knows about start and end times), it
|
|
will avoid undertaking an unnecessary retrieval action. Otherwise it will
|
|
undertake the RANGE retrieval request with the 'include-setup' as specified in
|
|
section <a href="#processing-protocol-server-mapped-setup"><b>5.2.2.2 Server
|
|
mapped byte ranges with corresponding binary data and codec setup data</b></a>
|
|
and will receive a 206 with just the setup data. If the UA is set up for
|
|
decoding, but cannot identify that the fragment is non-existent and does the
|
|
retrieval action without the 'include-setup', it will result in a 416. </p>
|
|
<ul>
|
|
<li>t=a,b with s < a, a < b, a >= e and b > e retrieves nothing
|
|
since interval beyond end of the resource</li>
|
|
<li>t=a,b with a < s, a < b, b <= s and b < e retrieves nothing
|
|
since interval ahead of start of the resource</li>
|
|
<li>t=a, with a >= e retrieves nothing since interval beyond end of the
|
|
resource</li>
|
|
<li>t=,a with a <= s retrieves nothing since interval ahead of start of
|
|
the resource</li>
|
|
</ul>
|
|
|
|
<p>Effect: retrieve whatever the browser needs to set up playback, but
|
|
otherwise nothing</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="error-temporal-validity" name="error-temporal-validity"></a>6.2.4
|
|
Validity error</h4>
|
|
|
|
<p>The value cannot be parsed for the dimension.</p>
|
|
|
|
<p>If the UA is already set up for decoding the resource, it will identify that
|
|
the fragment is invalid and avoid undertaking an unnecessary retrieval action.
|
|
Otherwise it will undertake the RANGE retrieval request with the
|
|
'include-setup' as specified in section <a
|
|
href="#processing-protocol-server-mapped-setup"><b>5.2.2.2 Server mapped byte
|
|
ranges with corresponding binary data and codec setup data</b></a> and will
|
|
receive a 206 with just the setup data. </p>
|
|
|
|
<p>Examples:</p>
|
|
<ul>
|
|
<li>t=a,b with a > b retrieves nothing since inverted interval</li>
|
|
<li>t=asdf</li>
|
|
<li>t=5,ekj</li>
|
|
<li>t=agk,9</li>
|
|
<li>t='0'</li>
|
|
<li>t=10-20</li>
|
|
<li>t=10:20</li>
|
|
<li>t=10,20,40</li>
|
|
<li>t%3D10 where %3D is equivalent to =; percent encoding does not
|
|
resolve</li>
|
|
</ul>
|
|
|
|
<p>Effect: retrieve whatever the browser needs to set up playback, but
|
|
otherwise nothing</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="error-temporal-smpte-mismatch"
|
|
name="error-temporal-smpte-mismatch"></a>6.2.5 SMPTE time code mismatch</h4>
|
|
|
|
<p>When there is a mismatch between the SMPTE time code used by the UA and the
|
|
encoding settings of the requested media resource (e.g., use of smpte-25 time
|
|
code when the media resource is encoded at 30fps), the server MUST ignore the
|
|
RANGE header and returns the whole resource (i.e., a 200). </p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="error-spatial" name="error-spatial"></a>6.3 Errors on the spatial
|
|
dimensions</h3>
|
|
|
|
<p>Assuming a single spatial dimension is present, we now analyse what content
|
|
can appear here and how it should be handled. </p>
|
|
|
|
<table border="1" summary="Editorial note: Silvia">
|
|
<tbody>
|
|
<tr>
|
|
<td width="50%" valign="top" align="left"><b>Editorial note:
|
|
Silvia</b></td>
|
|
<td width="50%" valign="top" align="right"> </td>
|
|
</tr>
|
|
<tr>
|
|
<td valign="top" align="left" colspan="2"><p>This list still has to be
|
|
provided.</p>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="error-track" name="error-track"></a>6.4 Errors on the track
|
|
dimensions</h3>
|
|
|
|
<p>Assuming a single track dimension is present, we now analyse what content
|
|
can appear here and how it should be handled. </p>
|
|
|
|
<table border="1" summary="Editorial note: Silvia">
|
|
<tbody>
|
|
<tr>
|
|
<td width="50%" valign="top" align="left"><b>Editorial note:
|
|
Silvia</b></td>
|
|
<td width="50%" valign="top" align="right"> </td>
|
|
</tr>
|
|
<tr>
|
|
<td valign="top" align="left" colspan="2"><p>This list still has to be
|
|
provided.</p>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="error-named" name="error-named"></a>6.5 Errors on the named
|
|
dimensions</h3>
|
|
|
|
<p>Assuming a single named dimension is present, we now analyse what content
|
|
can appear here and how it should be handled. </p>
|
|
|
|
<table border="1" summary="Editorial note: Silvia">
|
|
<tbody>
|
|
<tr>
|
|
<td width="50%" valign="top" align="left"><b>Editorial note:
|
|
Silvia</b></td>
|
|
<td width="50%" valign="top" align="right"> </td>
|
|
</tr>
|
|
<tr>
|
|
<td valign="top" align="left" colspan="2"><p>This list still has to be
|
|
provided.</p>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a id="implementor-notes" name="implementor-notes"></a>7 Notes to
|
|
Implementors (non-normative)</h2>
|
|
|
|
<p>This section contains notes to implementors. Some of the information here is
|
|
already stated formally elsewhere in the document, and the reference here is
|
|
mainly a heads-up. Other items are really outside the scope of this
|
|
specification, but the notes here reflect what the authors think would be good
|
|
practice. </p>
|
|
|
|
<p>The sub-sections are not mutually exclusive. Hence, an implementer of a web
|
|
browser as a media fragment client should read the sections <a
|
|
href="#media-fragment-browser"><b>7.1 Browsers Rendering Media
|
|
Fragments</b></a>, <a href="#media-fragment-display"><b>7.2 Clients Displaying
|
|
Media Fragments</b></a> and <a href="#media-fragment-clients"><b>7.3 All Media
|
|
Fragment Clients</b></a>. </p>
|
|
|
|
<div class="div2">
|
|
<h3><a id="media-fragment-browser" name="media-fragment-browser"></a>7.1
|
|
Browsers Rendering Media Fragments</h3>
|
|
|
|
<p>The pixel coordinates defined in the section <a
|
|
href="#naming-space"><b>4.2.2 Spatial Dimension</b></a> are intended to be
|
|
identical to the <a
|
|
href="http://dev.w3.org/html5/spec/video.html#concept-video-intrinsic-width">intrinsic
|
|
width and height defined in HTML5</a>. </p>
|
|
|
|
<p>For spatial URI fragments, the next section describes two distinct use
|
|
cases, highlighting and cropping. HTML rendering clients, however, are expected
|
|
to implement cropping as the default rendering mechanism. </p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="media-fragment-display" name="media-fragment-display"></a>7.2
|
|
Clients Displaying Media Fragments</h3>
|
|
|
|
<p>When dealing with media fragments, there is a question whether to display
|
|
the media fragment in context or without context. In general, it is recommended
|
|
to display a URI fragment in context since it is part of a larger resource. On
|
|
the other hand, a URI query results in a new resource, so it is recommended to
|
|
display it as a complete resource without context. The next paragraphs discuss
|
|
for each axis the context of a media fragment and provides suggestions
|
|
regarding the visualization of the URI fragment within its context. </p>
|
|
|
|
<p>For a temporal URI fragment, it is recommended to start playback at a time
|
|
offset that equals to the start of the fragment and pause at the end of the
|
|
fragment. When the "play" button is hit again, the resource will continue
|
|
loading and play back beyond the end of the fragment. When seeking to specific
|
|
offsets, the resource will load and play back from those seek points. It is
|
|
also recommended to introduce a "reload" button to replay just the URI
|
|
fragment. In this way, a URI fragment basically stands for "focusing
|
|
attention". Additionally, temporal URI fragments could be highlighted on the
|
|
transport bar. </p>
|
|
|
|
<p>For a spatial URI fragment, we foresee two distinct use cases: highlighting
|
|
the spatial region in-context and cropping to the region. In the first case,
|
|
the spatial region could be indicated by means of a bounding box or the
|
|
background (i.e., all the pixels that are not contained within the region)
|
|
could be blurred or darkened. In the second case, the region alone would be
|
|
presented as a cropped area. How a document author specifies which use case is
|
|
intended is outside the scope of this specification, we suggest implementors of
|
|
the specification provide a means for this, for example through attributes or
|
|
stylesheet elements. </p>
|
|
|
|
<p>Finally, for track URI fragments, it is recommended to play only the tracks
|
|
identified by the track URI fragment. If no tracks are specified, the default
|
|
tracks should be played. Different tracks could be selected using drop-down
|
|
boxes or buttons; the selected tracks are then highlighted during playback. The
|
|
way the UA retrieves information regarding the available tracks of a particular
|
|
resource is out of scope for this specification. </p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="media-fragment-clients" name="media-fragment-clients"></a>7.3 All
|
|
Media Fragment Clients</h3>
|
|
|
|
<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>Media Fragment Grammar:</em> Note that the grammar for Media Fragment
|
|
URI only specifies the grammar for features standardised by this specification.
|
|
If a string does not parse correctly it does not necessarily mean the URI is
|
|
wrong, it only means it is not a Media Fragment according to this
|
|
specification. It may be correct for some extended form, or for a completely
|
|
different fragment specification method. For this reason, error recovery on
|
|
syntax errors in media fragment specifiers is unwise. </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>
|
|
|
|
<p><em>Content-Range-Mapping:</em> The Content-Range-Mapping header returned
|
|
sometimes refers to a completely different range than the one that was
|
|
specified as the <em>Range:</em> in the request. This can happen if a
|
|
byte-based range is requested from a cache server that is not Media Fragment
|
|
aware, and that server had previously cached the data as a result of a time
|
|
range request. Technically, the information in the Content-Range-Mapping header
|
|
is still correct, but it is completely unrelated to the request issued. </p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="media-fragment-servers" name="media-fragment-servers"></a>7.4 Media
|
|
Fragment Servers</h3>
|
|
|
|
<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>SMPTE Timecodes:</em> Standardisation of SMPTE timecodes in this
|
|
document is primarily intended to allow frame-accurate references to sections
|
|
of video files, they can be seen as a form of content-based addressing. </p>
|
|
|
|
<p><em>Reasonable Clipping:</em> Temporal clipping needs to be as close as
|
|
reasonably possible to what the media fragment specified, and not omit any
|
|
requested data. "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.
|
|
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>Reasonable byte ranges:</em> If a single temporal range request would
|
|
result in a disproportionally large number of byte ranges it may be better if
|
|
the server returns a redirect to the query form of the media fragment. This
|
|
situation could happen, for example, if the underlying media file is organized
|
|
in a strange way. </p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="media-fragment-webapps" name="media-fragment-webapps"></a>7.5 Media
|
|
Fragment Web Applications</h3>
|
|
|
|
<p>Media Fragment URIs are only defined on media resources. However, many Web
|
|
developers that create Web pages with video or audio want to provide their
|
|
users the ability to jump directly to media fragments - in particular to time
|
|
offsets in a video - through providing a URI scheme for the Web page. </p>
|
|
|
|
<p>The way in which to realize this without requiring an extra server
|
|
interaction is by using a URI fragment scheme on the Web page which is parsed
|
|
by JavaScript and communicates the media fragment to the audio or video
|
|
resource loader. In HTML5 it would need to change the @src attribute of the
|
|
appropriate <audio> or <video> element with the appropriate URI
|
|
fragment and then call the load() function to make the element (re)load the
|
|
resource with that URI. </p>
|
|
|
|
<p>A URI scheme for such a Web page may involve ampersand-separated name-value
|
|
pairs as defined in this specification, e.g.
|
|
http://example.com/videopage.html#t=60,100 . </p>
|
|
|
|
<p>However, the Web developer has to create a scheme that works with the
|
|
remainder of the Web page fragment addressing functionality. If, for example,
|
|
the Web page makes use of the ID attributes of the elements on the page for
|
|
scrolling down on the page, adding media fragment URI addressing to the Web
|
|
page addressing will fail. For example, if
|
|
http://example.com/videopage.html#first works and scrolls to an offset on that
|
|
Web page, http://example.com/videopage.html#first&t=60,100 will not do the
|
|
same scrolling. The Web developer will then need to parse the fragment
|
|
parameter and implement the scrolling functionality in JavaScript manually
|
|
using the scrollTo() or scrollTop() functions. </p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a id="conclusions" name="conclusions"></a>8 Conclusions</h2>
|
|
|
|
<div class="div2">
|
|
<h3><a id="qualification-resources" name="qualification-resources"></a>8.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 id="references-normative" name="references-normative"></a>A
|
|
References</h2>
|
|
<dl>
|
|
<dt class="label"><a name="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"></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="sdp"></a>[RFC 2327] </dt>
|
|
<dd><cite>Session Description Protocol (SDP)</cite>. IETF RFC 2327, April
|
|
1998. Available at <a
|
|
href="http://www.ietf.org/rfc/rfc2327.txt">http://www.ietf.org/rfc/rfc2327.txt</a>.
|
|
</dd>
|
|
<dt class="label"><a name="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="rfc3339"></a>[RFC 3339] </dt>
|
|
<dd>G. Klyne and C. Newman. <cite>Date and Time on the Internet:
|
|
Timestamps</cite>. IETF RFC 3339, July 2002. Available at <a
|
|
href="http://www.ietf.org/rfc/rfc3339.txt">http://www.ietf.org/rfc/rfc3339.txt</a>.
|
|
</dd>
|
|
<dt class="label"><a name="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"></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="rfc5234"></a>[RFC 5234] </dt>
|
|
<dd>D. Crocker, Ed. <a
|
|
href="http://tools.ietf.org/html/rfc5234"><cite>Augmented BNF for Syntax
|
|
Specifications: ABNF</cite></a>. IETF RFC 5234, January 2008. Available
|
|
at <a
|
|
href="http://tools.ietf.org/html/rfc5234">http://tools.ietf.org/html/rfc5234</a>.
|
|
</dd>
|
|
<dt class="label"><a name="rfc4288"></a>[RFC 4288] </dt>
|
|
<dd>N. Freed and J. Klensin <a
|
|
href="http://www.ietf.org/rfc/rfc4288.txt"><cite>Media Type
|
|
Specifications and Registration Procedures</cite></a>. IETF RFC 4288,
|
|
December 2005. Available at <a
|
|
href="http://www.ietf.org/rfc/rfc4288.txt">http://www.ietf.org/rfc/rfc4288.txt</a>.
|
|
</dd>
|
|
<dt class="label"><a name="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"></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"></a>[HTML 5] </dt>
|
|
<dd>Ian Hickson, Google (ed).<a
|
|
href="http://www.w3.org/TR/2009/WD-html5-20090825/"><cite>HTML5</cite></a>.
|
|
W3C Working Draft, 25th August 2009. Available at <a
|
|
href="http://www.w3.org/TR/2009/WD-html5-20090825/">http://www.w3.org/TR/2009/WD-html5-20090825/</a>.
|
|
</dd>
|
|
<dt class="label"><a name="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"></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"></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"></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"></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"></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"></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"></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"></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"></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="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"></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>
|
|
<dt class="label"><a name="utf-8"></a>[UTF-8] </dt>
|
|
<dd><cite>UTF-8, a transformation format of ISO 10646</cite>. <a
|
|
href="http://tools.ietf.org/html/rfc3629">http://tools.ietf.org/html/rfc3629</a>
|
|
</dd>
|
|
<dt class="label"><a name="ecma-262"></a>[ECMA-262 5th edition] </dt>
|
|
<dd><cite>ECMA-262 5th edition</cite>: <a
|
|
href="http://www.ecma-international.org/publications/standards/Ecma-262.htm">http://www.ecma-international.org/publications/standards/Ecma-262.htm</a>
|
|
</dd>
|
|
<dt class="label"><a name="mediaAnnotations"></a>[Media Annotations] </dt>
|
|
<dd><cite>API for Media Resource 1.0</cite>: <a
|
|
href="http://www.w3.org/TR/mediaont-api-1.0/">http://www.w3.org/TR/mediaont-api-1.0/</a>
|
|
</dd>
|
|
<dt class="label"><a name="webLinking"></a>[Web Linking] </dt>
|
|
<dd><cite>Web Linking</cite>: <a
|
|
href="http://tools.ietf.org/html/draft-nottingham-http-link-header-10">http://tools.ietf.org/html/draft-nottingham-http-link-header-10</a>
|
|
</dd>
|
|
</dl>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a id="collected-syntax-uri" name="collected-syntax-uri"></a>B Collected
|
|
ABNF Syntax for URI (Non-Normative)</h2>
|
|
|
|
<div class="exampleInner">
|
|
<pre>unichar = <any Unicode code point>
|
|
unistring = *unichar
|
|
|
|
; defined in <cite><a href="#rfc5234">RFC 5234</a></cite>
|
|
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
|
|
DIGIT = %x30-39 ; 0-9
|
|
HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
|
|
|
|
; defined in <cite><a href="#rfc3986">RFC 3986</a></cite>
|
|
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
|
|
pct-encoded = "%" HEXDIG HEXDIG
|
|
sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="
|
|
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
|
|
fragment = *( pchar / "/" / "?" )
|
|
|
|
; defined in <cite><a href="#rtsp">RFC 2326</a></cite>
|
|
npt-sec = 1*DIGIT [ "." *DIGIT ] ; definitions taken
|
|
npt-hhmmss = npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT] ; from <cite><a href="#rtsp">RFC 2326</a></cite>
|
|
npt-hh = 1*DIGIT ; any positive number
|
|
npt-mm = 2DIGIT ; 0-59
|
|
npt-ss = 2DIGIT ; 0-59
|
|
|
|
; defined in <cite><a href="#rfc3339">RFC 3339</a></cite>
|
|
date-fullyear = 4DIGIT
|
|
date-month = 2DIGIT ; 01-12
|
|
date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on
|
|
; month/year
|
|
time-hour = 2DIGIT ; 00-23
|
|
time-minute = 2DIGIT ; 00-59
|
|
time-second = 2DIGIT ; 00-58, 00-59, 00-60 based on leap second
|
|
; rules
|
|
time-secfrac = "." 1*DIGIT
|
|
time-numoffset = ("+" / "-") time-hour ":" time-minute
|
|
time-offset = "Z" / time-numoffset
|
|
|
|
partial-time = time-hour ":" time-minute ":" time-second
|
|
[time-secfrac]
|
|
full-date = date-fullyear "-" date-month "-" date-mday
|
|
full-time = partial-time time-offset
|
|
|
|
date-time = full-date "T" full-time
|
|
|
|
; Mediafragment definitions
|
|
segment = mediasegment / *( pchar / "/" / "?" ) ; augmented fragment
|
|
; definition taken from
|
|
; <cite><a href="#rfc3986">RFC 3986</a></cite>
|
|
|
|
;
|
|
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Common Prefixes ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
|
|
;
|
|
|
|
deftimeformat = %x6E.70.74 ; "npt"
|
|
pfxdeftimeformat = %x74.3A.6E.70.74 ; "t: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"
|
|
pfxsmpteformat = %x74.3A.73.6D.70.74.65 ; "t:smpte"
|
|
/ %x74.3A.73.6D.70.74.65.2D.32.35 ; "t:smpte-25"
|
|
/ %x74.3A.73.6D.70.74.65.2D.33.30 ; "t:smpte-30"
|
|
/ %x74.3A.73.6D.70.74.65.2D.33.30.2D.64.72.6F.70 ; "t:smpte-30-drop"
|
|
clockformat = %x63.6C.6F.63.6B ; "clock"
|
|
pfxclockformat = %x74.3A.63.6C.6F.63.6B ; "clock"
|
|
|
|
;
|
|
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Media Segment ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
|
|
;
|
|
mediasegment = namesegment / axissegment
|
|
axissegment = ( <a href="#timesegment">timesegment</a> / <a href="#spacesegment">spacesegment</a> / <a href="#tracksegment">tracksegment</a> )
|
|
*( "&" ( <a href="#timesegment">timesegment</a> / <a href="#spacesegment">spacesegment</a> / <a href="#tracksegment">tracksegment</a> )
|
|
;
|
|
; note that this does not capture the restriction of only one timesegment or spacesegment
|
|
; in the axisfragment definition, unless we list explicitely all the cases,
|
|
;
|
|
timesegment = timeprefix "=" timeparam
|
|
timeprefix = %x74 ; "t"
|
|
timeparam = <a href="#npttimedef">npttimedef</a> / <a href="#smptetimedef">smptetimedef</a> / <a href="#clocktimedef">clocktimedef</a>
|
|
npttimedef = [ deftimeformat ":"] ( npttime [ "," npttime ] ) / ( "," npttime )
|
|
|
|
npttime = npt-sec / npt-hhmmss
|
|
|
|
smptetimedef = smpteformat ":"( frametime [ "," frametime ] ) / ( "," frametime )
|
|
frametime = 1*DIGIT ":" 2DIGIT ":" 2DIGIT [ ":" 2DIGIT [ "." 2DIGIT ] ]
|
|
|
|
clocktimedef = clockformat ":"( clocktime [ "," clocktime ] ) / ( "," clocktime )
|
|
clocktime = (datetime / walltime / date)
|
|
datetime = date-time ; inclusion of <cite><a href="#rfc3339">RFC 3339</a></cite>
|
|
|
|
spacesegment = 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"
|
|
|
|
tracksegment = trackprefix "=" trackparam
|
|
trackprefix = %x74.72.61.63.6B ; "track"
|
|
trackparam = unistring
|
|
|
|
namesegment = nameprefix "=" nameparam
|
|
nameprefix = %x69.64 ; "id"
|
|
nameparam = unistring
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a id="collected-syntax-http" name="collected-syntax-http"></a>C Collected
|
|
ABNF Syntax for HTTP Headers (Non-Normative)</h2>
|
|
|
|
<div class="exampleInner">
|
|
<pre>; defined in <cite><a href="#rfc2616">RFC 2616</a></cite>
|
|
CHAR = [any US-ASCII character (octets 0 - 127)]
|
|
token = 1*[any CHAR except CTLs or separators]`
|
|
first-byte-pos = 1*DIGIT
|
|
last-byte-pos = 1*DIGIT
|
|
bytes-unit = "bytes"
|
|
range-unit = bytes-unit | other-range-unit
|
|
byte-range-resp-spec = (first-byte-pos "-" last-byte-pos)
|
|
Range = "Range" ":" ranges-specifier
|
|
Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges
|
|
|
|
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; HTTP Request Headers ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
|
|
;;
|
|
ranges-specifier = byte-ranges-specifier | fragment-specifier
|
|
;
|
|
; note that ranges-specifier is extended from <cite><a href="#rfc2616">RFC 2616</a></cite>
|
|
; to cover alternate fragment range specifiers
|
|
;
|
|
fragment-specifier = "include-setup" | fragment-range *( "," fragment-range )
|
|
[ ";" "include-setup" ]
|
|
fragment-range = time-ranges-specifier | track-ranges-specifier | name-ranges-specifier
|
|
;
|
|
; note that this doesn't capture the restriction to one fragment dimension occurring
|
|
; maximally once only in the fragment-specifier definition.
|
|
;
|
|
time-ranges-specifier = timeprefix ":" time-ranges-options
|
|
time-ranges-options = npttimeoption / smptetimeoption / clocktimeoption
|
|
npttimeoption = deftimeformat "=" npt-sec "-" [ npt-sec ]
|
|
smptetimeoption = smpteformat "=" frametime "-" [ frametime ]
|
|
clocktimeoption = clockformat "=" datetime "-" [ datetime ]
|
|
|
|
track-ranges-specifier = trackprefix "=" trackparam *( ";" trackparam )
|
|
|
|
name-ranges-specifier = nameprefix "=" nameparam
|
|
|
|
;;
|
|
Accept-Range-Redirect = "Accept-Range-Redirect" ":" bytes-unit
|
|
;
|
|
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; HTTP Response Headers ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
|
|
;
|
|
Content-Range-Mapping = "Content-Range-Mapping" ":" '{'
|
|
( content-range-mapping-spec [ ";" def-include-setup ] ) / def-include-setup
|
|
'}' '=' '{'
|
|
byte-content-range-mapping-spec '}'
|
|
|
|
def-include-setup = %x69.6E.63.6C.75.64.65.2D.73.65.74.75.70 ; "include-setup"
|
|
|
|
byte-range-mapping-spec = bytes-unit SP
|
|
byte-range-resp-spec *( "," byte-range-resp-spec ) "/"
|
|
( instance-length / "*" )
|
|
|
|
content-range-mapping-spec = time-mapping-spec | track-mapping-spec | name-mapping-spec
|
|
time-mapping-spec = timeprefix ":" time-mapping-options
|
|
time-mapping-options = npt-mapping-option / smpte-mapping-option / clock-mapping-option
|
|
npt-mapping-option = deftimeformat SP npt-sec "-" npt-sec "/"
|
|
[ npt-sec ] "-" [ npt-sec ]
|
|
smpte-mapping-option = smpteformat SP frametime "-" frametime "/"
|
|
[ frametime ] "-" [ frametime ]
|
|
clock-mapping-option = clockformat SP datetime "-" datetime "/"
|
|
[ datetime ] "-" [ datetime ]
|
|
|
|
track-mapping-spec = trackprefix SP trackparam *( ";" trackparam )
|
|
|
|
name-mapping-spec = nameprefix SP nameparam
|
|
|
|
;;
|
|
acceptable-ranges = 1#range-unit *( "," 1#range-unit )| "none"
|
|
;
|
|
; note this does not represent the restriction that range-units can only appear once at most;
|
|
; this has also been adapted from <cite><a href="#rfc2616">RFC 2616</a></cite>
|
|
; to allow multiple range units.
|
|
;
|
|
other-range-unit = token | timeprefix | trackprefix | nameprefix
|
|
|
|
;;
|
|
Range-Redirect = "Range-Redirect" ":" byte-range-resp-spec *( "," byte-range-resp-spec )
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a id="rtsp-media-fragment-processing"
|
|
name="rtsp-media-fragment-processing"></a>D Processing media fragment URIs in
|
|
RTSP (Non-Normative)</h2>
|
|
|
|
<p>This appendix explains how the media fragment specification is mapped to an
|
|
RTSP protocol activity. We assume here that you have a general understanding of
|
|
the RTSP protocol mechanism as defined in <cite><a href="#rtsp">RFC
|
|
2326</a></cite>. The general sequence of messages sent between an RTSP UA and
|
|
server can be summarized as follows: </p>
|
|
<ul>
|
|
<li>from a DESCRIBE activity, in which the UA requests from the server what
|
|
resources it has available,</li>
|
|
<li>through a SETUP activity, which sets up the communication between the UA
|
|
and the server, including the requested tracks,</li>
|
|
<li>to a PLAY activity, where time ranges are requested by the UA from the
|
|
server for playback.</li>
|
|
<li>A PAUSE is always possible in the middle of a RTSP communication, and</li>
|
|
<li>a TEARDOWN closes the communication.</li>
|
|
</ul>
|
|
|
|
<p>Note that the RTSP protocol is intentionally similar in syntax and operation
|
|
to HTTP. </p>
|
|
|
|
<div class="div2">
|
|
<h3><a id="mapping-mf-to-rtsp-methods"
|
|
name="mapping-mf-to-rtsp-methods"></a>D.1 How to map Media Fragment URIs to
|
|
RTSP protocol methods</h3>
|
|
|
|
<div class="div3">
|
|
<h4><a id="rtsp-mf-dimensions" name="rtsp-mf-dimensions"></a>D.1.1 Dealing with
|
|
the media fragment URI dimensions in RTSP</h4>
|
|
|
|
<p>We illustrated for each of the four media fragment dimensions how they can
|
|
be mapped onto RTSP commands. The following examples are used to illustrated
|
|
each of the dimensions: (1) temporal: #t=10,20 (2) tracks:
|
|
#track=audio&track=video (3) spatial: #xywh=160,120,320,24 (4) id:
|
|
#id=Airline%20Edit </p>
|
|
|
|
<div class="div4">
|
|
<h5><a id="rtsp-temporal" name="rtsp-temporal"></a>D.1.1.1 Temporal Media
|
|
Fragment URIs</h5>
|
|
|
|
<p>In RTSP, temporal fragment URIs are provided through the PLAY method. A URI
|
|
such as</p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>rtsp://example.com/media#t=10,20</pre>
|
|
</div>
|
|
|
|
<p>will be executed as a series of the following methods (all shortened for
|
|
readability - full examples can be found in ). </p>
|
|
<ul>
|
|
<li>UA->S: DESCRIBE rtsp://example.com/media</li>
|
|
<li>S->UA: RTSP/1.0 200 OK (with an SDP description)</li>
|
|
<li>UA->S: SETUP rtsp://example.com/media/video</li>
|
|
<li>S->UA: RTSP/1.0 200 OK</li>
|
|
<li>UA->S: SETUP rtsp://example.com/media/audio</li>
|
|
<li>S->UA: RTSP/1.0 200 OK</li>
|
|
</ul>
|
|
|
|
<p>The actual temporal selection is provided in the PLAY method: </p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>C->S: PLAY rtsp://example.com/media
|
|
Range: npt=10-20</pre>
|
|
</div>
|
|
|
|
<p>The server tells the UA which temporal range is returned: </p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>S->C: RTSP/1.0 200 OK
|
|
Range: npt=9.5-20.1</pre>
|
|
</div>
|
|
|
|
<p>We can explain this mapping for all of the media fragment defined time
|
|
schemes. Also, several temporal media fragment URI requests can be sent as
|
|
pipelined commands without having to re-send the DESCRIBE and SETUP commands.
|
|
</p>
|
|
</div>
|
|
|
|
<div class="div4">
|
|
<h5><a id="rtsp-track" name="rtsp-track"></a>D.1.1.2 Track Media Fragment
|
|
URIs</h5>
|
|
|
|
<p>In RTSP, track fragment URIs are provided through the SETUP method. A URI
|
|
such as</p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>rtsp://example.com/media#track=audio&track=video</pre>
|
|
</div>
|
|
|
|
<p>will be executed as a series of the following methods (all shortened for
|
|
readability). </p>
|
|
<ul>
|
|
<li>UA->S: DESCRIBE rtsp://example.com/media</li>
|
|
<li>S->UA: RTSP/1.0 200 OK (with an SDP description)</li>
|
|
<li>UA->S: SETUP rtsp://example.com/media/video</li>
|
|
<li>S->UA: RTSP/1.0 200 OK</li>
|
|
<li>UA->S: SETUP rtsp://example.com/media/audio</li>
|
|
<li>S->UA: RTSP/1.0 200 OK</li>
|
|
</ul>
|
|
|
|
<p>The discovery of available tracks is provided through the SDP reply to
|
|
DESCRIBE, but it could be done through alternative methods, too. Several
|
|
consecutive track media fragment URI requests can only be sent with new SETUP
|
|
commands and cannot be pipelined. </p>
|
|
</div>
|
|
|
|
<div class="div4">
|
|
<h5><a id="rtsp-spatial" name="rtsp-spatial"></a>D.1.1.3 Spatial Media Fragment
|
|
URIs</h5>
|
|
|
|
<p>In RTSP, spatial fragment URIs are not specifically provided for. Just like
|
|
in HTTP, spatial fragments are interpreted at the UA and thus not communicated
|
|
to the server. A URI such as</p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>rtsp://example.com/media#xywh=160,120,320,24</pre>
|
|
</div>
|
|
|
|
<p>will be executed as the url rtsp://example.com/media. </p>
|
|
</div>
|
|
|
|
<div class="div4">
|
|
<h5><a id="rtsp-named" name="rtsp-named"></a>D.1.1.4 Named Media Fragment
|
|
URIs</h5>
|
|
|
|
<p>We see no easy way to support this in RTSP as currently standardised.</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="rtsp-combined-mf-dimensions"
|
|
name="rtsp-combined-mf-dimensions"></a>D.1.2 Putting the media fragment URI
|
|
dimensions together in RTSP</h4>
|
|
|
|
<p>A URI such as</p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>rtsp://example.com/media#xywh=160,120,320,24&t=10,20&track=audio&track=video</pre>
|
|
</div>
|
|
|
|
<p>will be executed as a series of the following methods (all shortened for
|
|
readability). The data selection is provided both in the SETUP method and the
|
|
PLAY method:</p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>UA->S: DESCRIBE rtsp://example.com/media
|
|
S->UA: RTSP/1.0 200 OK (with an SDP description, see wiki)
|
|
UA->S: SETUP rtsp://example.com/media/video
|
|
S->UA: RTSP/1.0 200 OK
|
|
UA->S: SETUP rtsp://example.com/media/audio
|
|
S->UA: RTSP/1.0 200 OK
|
|
UA->S: PLAY rtsp://example.com/media
|
|
Range: npt=10-20
|
|
S->UA: RTSP/1.0 200 OK
|
|
Range: npt=9.5-20.1</pre>
|
|
</div>
|
|
|
|
<p>It is the UA's task to only display the rectangle xywh=160,120,320,2. It is
|
|
true that the resolution of the dimensions is done at different levels of the
|
|
protocol, but that does not create a problem.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="rtsp-caching" name="rtsp-caching"></a>D.1.3 Caching and RTSP for
|
|
media fragment URIs</h4>
|
|
|
|
<p>Media fragment URIs rely only on existing protocol negotiations in RTSP.
|
|
Therefore any RTSP caching scheme, assuming such a thing exists, will work fine
|
|
with media fragments.</p>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a id="acknowledgments" name="acknowledgments"></a>E 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), Philip
|
|
Jägenstedt (Opera Software), Jack Jansen (CWI), Yves Lafon (W3C), Wonsuk Lee
|
|
(Electronics and Telecommunications Research Institute), 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 (EURECOM), 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, Ryo Kawaguchi, Wim Van Lancker, Véronique
|
|
Malaisé, Henrik Nordstrom, Yannick Prié, Yves Raimond, Julian Reschke,
|
|
Geoffrey Sneddon, Felix Sasaki, Jakub Sendor, Philip Taylor, Christian
|
|
Timmerer, Jorrit Vermeiren, Jeroen Wijering and Munjo Yu. </p>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a id="change-log" name="change-log"></a>F Change Log (Non-Normative)</h2>
|
|
|
|
<p>@@This paragraph will be replaced by the change log. DO NOT TOUCH@@</p>
|
|
</div>
|
|
</div>
|
|
</body>
|
|
</html>
|