Media Fragments URI 1.0

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.

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.

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.

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 cacheable 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.

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.

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.

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.1.3 Error Handling.

4.2 Fragment Dimensions

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)

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)

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)

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

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%

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'

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'

4.3 ABNF Syntax

The composition of a URI fragment or query string for a media resource relies on a series of field-value pairs to be added behind the URI fragment ('#') or query ('?') identifier. The field-value pairs are each separated by an equal sign. The series of pairs is separated by an ampersand, '&' or semicolon, ';'.

A general URI fragment or query string specified on a media resource may contain several field-value pairs. They are not restricted to the ones specified here, since applications may want to use additional other parameters to communicate further requests to custom servers. A conformant server or user agent will need to be able to parse a random URI query or fragment string for a media resource and identify the relevant parts. E.g. the relevant field-value pair out of a media fragment URI like this http://www.example.com/video.ogv#&&=&=tom;jerry=&t=34&t=meow:0# is t=34.

In this section we present the ABNF ([ABNF]) syntax for the field-value pairs that relate to a media fragment URI. The names for the non-terminals more-or-less follow the names used in the previous subsections, with one clear difference: the start symbol is called mediasegment, because we want to allow application of it to both URI fragment and URI query strings.

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

5.1 Overview

5.2 Protocol for URI fragment Resolution in HTTP

This section defines what protocol steps are necessary in HTTP [RFC 2616] to resolve and deliver a media fragment specified as a URI fragment.

5.3 Protocol for URI query Resolution in HTTP

This section describes the protocol steps used in HTTP [RFC 2616] to resolve and deliver a media fragment specified as a URI query.

A user requests a media fragment URI using a URI query:

• User → UA (1):

  http://www.example.com/video.ogv?t=10,20

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.

Assuming the resource has not been retrieved before, the following is sent to the server:

• UA (1) → Proxy (2) → Origin Server (3):

  GET /video.ogv?t=10,20 HTTP/1.1
  Host: www.example.com
  Accept: video/*

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.

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:

• Origin Server (3) → Proxy (4) → UA (5):

  HTTP/1.1 200 OK
  Content-Length: 3782
  Content-Type: video/ogg
  Etag: "b7a60-21f7111-46f3219476580"
  
  {binary data}

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.

It is possible to add an additional HTTP response header called "Link" that refers the new resource back to the original resource and enables the UA to retrieve further information about the original resource, such as its full length. In this case, the user agent is also enable to choose to display the dimensions of the primary resource or the one created by the query.

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 5.2.3 Proxy cacheable Server mapped byte ranges.

Not that a server that doesn't support media fragments through either URI fragment or query addressing, will return the full resource in either case. It is therefore not possible to first try URI fragment addressing, and when that fails to try URI query addressing.

6.1 Qualification of Media Resources

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:

• The media fragments can be extracted in the compressed domain;

• No syntax element modifications in the bitstream are needed to perform the extraction.

Not all media formats will be compliant with these two conditions. Hence, we distinguish the following categories:

1. 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.

2. 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.

3. 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.