1 Introduction
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.
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.
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 Use cases and requirements for Media Fragments document that accompanies this specification document.
The media fragment URIs specified in this document have been implemented and demonstrated to work with media resources over the HTTP and
RTP/RTSP protocols. Existing media formats in their current representations and implementations provide varying degrees of support for
this specification. It is expected that over time, media formats, media players, Web Browsers, media and Web servers, as well as Web
proxies will be extended to adhere to the full specification. This specification will help make video a first-class citizen of the World
Wide Web.
3 URI fragment and URI query
To address a media fragment, one needs to find ways to convey the fragment information. This specification builds on URIs
RFC 3986. Every URI is defined as consisting of four parts, as follows:
<scheme name> : <hierarchical part> [ ? <query> ] [ # <fragment> ]
There are therefore two possibilities for representing the media fragment addressing in URIs: the
URI query part or the
URI fragment part.
3.1 When to choose URI fragments? When to choose URI queries?
For media fragment addressing, both approaches - URI query and URI fragment - are useful.
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.
There are different types of media fragment addressing in this specification. As noted in the Use cases and requirements for Media Fragments 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.
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.
| Editorial note: Raphael | |
| I wonder if we should not paste here the table in the Annexe B of the requirement document with the various container formats
and their "fit" value for the media fragment dimensions considered |
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.
3.2 Resolving URI fragments within the user agent
The most optimal means of using media fragments in an application is through the use of URI fragments which the application resolves
from the resource it already holds. This is desirable since it does not require further downloads and the user agent has the full
context of the primary resource at hand.
An example of a URI fragment used to address a media fragment is http://www.example.org/video.ogv#t=60,100. In this case,
the user agent knows that the primary resource is http://www.example.org/video.ogv and that it is only expected to display
the portion of the primary resource that relates to the fragment #t=60,100, i.e. seconds 60-100. Thus, the relationship
between the primary resource and the media fragment is maintained.
In traditional URI fragment retrieval, a user agent requests the complete primary resource from the server and then applies the
fragmentation locally. In the media fragment case, this would result in a retrieval action on the complete media resource, on which the
user agent would then locally perform its fragment extraction. Since media resources are typically very large, user agents do not
typically retrieve the complete media resource in one go, but rather request byte ranges as required. This is a more economical use of
retrieval bandwidth. A user agent that knows how to map media fragments to byte ranges will be able to satisfy a URI fragment request
such as the above example by itself. This is typically the case for user agents that know how to seek to media fragments over the network.
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.
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.
3.3 Resolving URI fragments with server help
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.
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.
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 http://www.example.org/video.ogv#t=60,100 and the
user agent sent a range request of t=60,100 to the server, the server may only be able to return the range
t=58,103 as the closest decodable range that encapsulates all the required data.
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.
3.4 Resolving URI fragments in a proxy cachable manner
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.
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.
| Editorial note: Raphael | |
| Should we not foresee future "smart" media caches that would be able to actually cache range request in other units than bytes?
|
3.5 Resolving URI queries
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.
| Editorial note: Raphael | |
|
Weak argument? I would rather argue that if we cannot maintain byte-identity, then the fragment part of a URI is simply not suitable per
TAG finding that we would need to request. The argument that the server has to do some complex processing seems to me weaker.
|
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.
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.
An example URI query that includes a media fragment specification is http://www.example.org/video.ogv?t=60,100. This results
in a video of duration 40s (assuming the original video was more than 100s long).
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.
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.
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.
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.
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.
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.
3.6 Combining URI fragments and URI queries
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 RFC 3986.
For example, http://www.example.org/video.ogv?t=60,100#t=20 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.
| Editorial note: Silvia | |
|
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.
|
4 Media Fragments Syntax
This section describes the external representation of a media fragment specifier, and how this should be interpreted. The first two subsections are a semi-informal introduction, with the formal grammar and detailed semantics being specified in the last two subsections.
4.1 General Structure
The fragment identifier consists of a list of name/value pairs, the
dimension specifiers, separated by the primary separator
&. Name and value are separated by an equal
sign (=). In case value is structured, colon
(:) and comma (,) are used as
secondary separators. No whitespace is allowed (except inside strings).
Some examples of URIs with a media fragment, to show the
general structure:
http://www.example.com/example.ogv#t=10s,20s
http://www.example.com/example.ogv#track='audio'
http://www.example.com/example.ogv#track='audio'&t=10s,20s
Media fragments support fragmenting the media along four dimensions:
- temporal
This dimension denotes a specific time range in the
original media, such as "starting at second 10, continuing
until second 20";
- spatial
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)";
- track
this dimension denotes one track (media type) in the
original media, such as "the english audio track";
- named
this dimension denotes a named section of the original
media, such as "chapter 2".
Note that the track dimension refers to one of a set of parallel media streams ("the english audio track for a video"), not to a, possibly self-contained, section of the source media ("Audio track 2 of a CD"). The self-contained section is handled by the name dimension.
The name dimension cannot be combined with other dimensions for this version of the media fragments specification. Projection along the other three dimensions is logically commutative, therefore they can be combined, and the outcome is independent of the order of the dimensions. Each dimension can be specified at most once. The name dimension cannot be combined with the other dimensions, because the semantics depend on the underlying source media format: some media formats support naming of temporal extents, others support naming of groups of tracks, etc. Error semantics are discussed in 5 Interpreting and Processing Media Fragments.
4.2 Fragment Dimensions
4.2.1 Temporal Dimension
Temporal clipping is denoted by the name t, 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.
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)
Temporal clipping can be specified either as Normal Play Time (npt) RFC 2326, as SMPTE timecodes, SMPTE, or as real-world clock time (clock) RFC 2326. Begin and end times are always specified in the same format. The format is specified by name, followed by a colon (:), with npt: being the default.
In this version of the media fragments specification there is no extensibility mechanism to add time format specifiers.
4.2.1.1 Normal Play Time (NPT)
Normal Play Time can either be specified as seconds, with an optional fractional part and an optional s to indicate seconds, or as colon-separated hours, minutes and seconds (again with an optional fraction). Minutes and seconds must be specified as exactly two digits, hours and fractional seconds can be any number of digits. The hours, minutes and seconds specification for NPT is a convenience only, it does not signal frame accuracy. The specification of the "npt:" identifier is optional since NPT is the default time scheme.
t=npt:10s,20 # => results in the time interval [10,20)
t=npt:120s, # => results in the time interval [120,end)
t=npt:,121.5s # => results in the time interval [0,121.5)
t=0:02:00,121.5 # => results in the time interval [120,121.5)
t=npt:120,0:02:01.5 # => also results in the time interval [120,121.5)
| Editorial note: Jack | |
|
Do we need a rationale, to explain that we picked this syntax for timecodes up from rtsp and smil?
|
4.2.1.2 SMPTE time codes
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 (.). 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:
smpte,smpte-25,smpte-30 and smpte-30-drop.
smpte is a synonym for smpte-30.
t=smpte-30:0:02:00,0:02:01:15 # => results in the time interval [120,121.5)
t=smpte-25:0:02:00:00,0:02:01:12.1 # => results in the time interval [120,121.5)
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.
4.2.1.3 Wall-clock time code
Wall-clock time codes are a way to address real-world clock time that is associated with a typically live video stream. These are the same time codes that are being used by RTSP RFC 2326, by SMIL SMIL, and by HTML5 HTML 5. The scheme uses ISO 8601 UTC timestamps (http://www.iso.org/iso/date_and_time_format). The format separates the date from the time with a "T" character and the string ends with "Z" in the SMIL 3.0 way, which includes time zone capabilities. The time scheme identifier is "clock".
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
4.2.2 Spatial Dimension
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.
Rectangle selection is denoted by the name xywh. The value is an optional format pixel: or percent: (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.
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%
4.2.3 Track Dimension
Track selection allows the extraction of a single track (audio, video, subtitles, etc) from a media container that supports multiple tracks. Track selection is denoted by the name track. The value is a string enclosed in single quotes. Percent-escaping can be used in the string to specify unsafe characters, see the grammer below for details. Interpretation of the string depends on the container format of the original media: some formats allow numbers only, some allow full names.
track='1' # => results in only extracting track 1
track='video' # => results in only extracting track 'video'
track='Wide%20Angle%20Video' # => results in only extracting track 'Wide Angle Video'
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.
| Editorial note: Jack | |
|
The issue of generic track names is still under discussion, ISSUE-4 in the tracker has the details.
|
4.2.4 Named Dimension
Name-based selection is denoted by the name id, with the value being a string enclosed in single quotes. Percent-escaping can be used in the string to include unsafe characters such as single quote, see the grammer below for details. Interpretation of the string depends on the underlying container format: some container formats support named chapters or numbered chapters (leading to temporal clipping), some may support naming of groups of tracks or other objects. As with track selection, determining which names are valid requires knowledge of the original media item.
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'
Note that, despite the use of the name id, there is no correspondence to XML id: the values are uninterpreted strings, from the point of view of media fragment handling.
4.3 ABNF Syntax
In this section we present the ABNF (ABNF) syntax for a media fragment specifier. The names for the non-terminals more-or-less follow the names used in the previous subsections, with one clear difference: the start symbol is called mediasegment, because we want to leave open the possibility of reuse in a URI query in addition to the current use in a URI fragment.
segment = mediasegment / *( pchar / "/" / "?" ) ; augmented fragment
; definition taken from
; rfc3986
;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Media Segment ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;
mediasegment = namesegment / axissegment
axissegment = ( timesegment / spacesegment / tracksegment )
*( "&" ( timesegment / spacesegment / tracksegment )
;
; note that this does not capture the restriction to one kind of fragment
; in the axisfragment definition, unless we list explicitely the 14 cases.
;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Time Segment ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;
timesegment = timeprefix "=" timeparam
timeprefix = %x74 ; "t"
timeparam = npttimedef / smptetimedef / clocktimedef
npttimedef = [ deftimeformat ":"] ( npttime [ "," npttime ] ) / ( "," npttime )
smptetimedef = smpteformat ":"( frametime [ "," frametime ] ) / ( "," frametime )
clocktimedef = clockformat ":"( clocktimetime [ "," clocktime ] ) / ( "," clocktime )
deftimeformat = %x6E.70.74 ; "npt"
smpteformat = %x73.6D.70.74.65 ; "smpte"
/ %x73.6D.70.74.65.2D.32.35 ; "smpte-25"
/ %x73.6D.70.74.65.2D.33.30 ; "smpte-30"
/ %x73.6D.70.74.65.2D.33.30.2D.64.72.6F.70 ; "smpte-30-drop"
clockformat = %x63.6C.6F.63.6B ; "clock"
timeunit = %x73 ; "s"
npttime = ( 1*DIGIT [ "." 1*DIGIT ] [timeunit] ) /
( 1*DIGIT ":" 2DIGIT ":" 2DIGIT [ "." 1*DIGIT] )
frametime = 1*DIGIT ":" 2DIGIT ":" 2DIGIT [ ":" 2DIGIT [ "." 2DIGIT ] ]
clocktime = (datetime / walltime / date)
datetime = date "T" walltime
date = years "-" months "-" days
walltime = (HHMM / HHMMSS) tzd
HHMM = hours24 ":" minutes
HHMMSS = hours24 ":" minutes ":" seconds ["." fraction]
years = 4DIGIT
months = 2DIGIT ; range from 01 to 12
days = 2DIGIT ; range from 01 to 31
hours24 = 2DIGIT ; range from 00 to 23
minutes = 2DIGIT ; range from 00 to 59
seconds = 2DIGIT ; range from 00 to 59
fraction = DIGIT+
tzd = "Z" / (("+" / "-") hours24 ":" minutes )
;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Space Segment ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;
spacesegment = xywhdef
xywhdef = xywhprefix "=" xywhparam
xywhprefix = %x78.79.77.68 ; "xywh"
xywhparam = [ xywhunit ":" ] 1*DIGIT "," 1*DIGIT "," 1*DIGIT "," 1*DIGIT
xywhunit = %x70.69.78.65.6C ; "pixel"
/ %x70.65.72.63.65.6E.74 ; "percent"
;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Track Segment ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;
tracksegment = trackprefix "=" trackparam
trackprefix = %x74.72.61.63.6B ; "track"
trackparam = utf8string
;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Name Segment ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;
namesegment = nameprefix "=" nameparam
nameprefix = %x69.64 ; "id"
nameparam = utf8string
;
;;;;;;;;;;;;;;;;;;;;;;;;;;;; Imported definitions ;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;
DIGIT = <DIGIT, defined in rfc4234#3.4>
pchar = <pchar, defined in rfc3986>
unreserved = <unreserved, defined in rfc3986>
pct-encoded = <pct-encoded, defined in rfc3986>
utf8string = "'" *( unreserved / pct-encoded ) "'" ; utf-8 character
; encoded URI-style 
