Media Fragments URI 1.0

2.1 Terminology

The keywords MUST, MUST NOT, SHOULD and SHOULD NOT are to be interpreted as defined in RFC 2119.

According to RFC 3986, 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 RFC 3986 (section 4.1). For simplicity reasons, this document, however, only uses the term "media fragment URI" in place of "media fragment URI reference".

The following terms are used frequently in this document and need to be clearly understood:

• URI fragment = anything behind a "#" in a URI
• URI query = anything behind a "?" and before a "#" in a URI
• media fragment URI = a URI addressing subparts of a media resource - that could be through URI queries or URI fragments

2.2 Media Fragments Standardisation

The basis for the standardisation of media fragment URIs is the URI specification, RFC 3986. 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.

In this section, we look at implications of standardising the structure of media fragment URIs.

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

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.

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 - something generally unviable for such large resources.

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.

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.

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.

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 (=).

Here are some examples of URIs with name-value pairs, to demonstrate the general structure:

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
http://www.example.com/example.ogv#track=audio&t=10,20

4.2 URL Serialization

This ABNF syntax defines the structure of media fragment URI components.

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 or more tracks in the original media, such as "the english audio and the video track";

named

this dimension denotes a named section of the original media, such as "chapter 2".

Note that 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.

The temporal, spatial and track dimensions are logically independent and can be combined; the outcome is independent of the order of the dimensions.

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").

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 6 Media Fragments Semantics.

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.

A specification of the parsing algorithm to extract these from an actual URI can be found in D.1 Processing name-value components and D.2 Processing name-value lists. Note that the URI works on octet strings, but the parsed name-value pairs are unicode strings, since percent-encoding is resolved. The following definitions apply to these unicode strings.

4.3 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)

          timeprefix    = %x74                                      ; "t"
          timeparam     = npttimedef / smptetimedef / clocktimedef
          

npt-sec       = 1*DIGIT [ "." *DIGIT ]                     ; definitions taken
npt-hhmmss    = npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT] ; from RFC 2326
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-hhmmss

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)

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 ] ]

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)

datetime      = <date-time, defined in RFC 3339>

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 RFC 3986),
; it should be percent-encoded when used in a URI.

; defined in RFC 3339
;
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

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

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"

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%

trackprefix   = %x74.72.61.63.6B                          ; "track"
trackparams   = trackparam
trackparam    = utf8string

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'

nameprefix    = %x69.64                                   ; "id"
nameparam     = utf8string

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'

DIGIT         = <DIGIT, defined in RFC 4234>
pchar         = <pchar, defined in RFC 3986>
unreserved    = <unreserved, defined in RFC 3986>
pct-encoded   = <pct-encoded, defined in RFC 3986>
fragment      = <pct-encoded, defined in RFC 3986>
utf8string    = *( unreserved / pct-encoded  ":" / "@" )  ; utf-8 character
                                                          ; encoded using rfc3896 rules.

ALPHA         =  %x41-5A / %x61-7A   ; A-Z / a-z
DIGIT         =  %x30-39 ; 0-9
HEXDIG        =  DIGIT / "A" / "B" / "C" / "D" / "E" / "F"

unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~"
pct-encoded   = "%" HEXDIG HEXDIG
sub-delims    = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="
pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"
fragment      = *( pchar / "/" / "?" )

5.1 Protocol for URI fragment Resolution in HTTP

This section defines the protocol steps in HTTP RFC 2616 to resolve and deliver a media fragment specified as a URI fragment.

5.1.1 UA mapped byte ranges

Editorial note
This section is ready to implement.

As described in section 3.2 Resolving URI fragments within the user agent, 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.

In this case, the HTTP exchanges are exactly the same as for any other Web resource where byte ranges are requested RFC 2616.

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.

Here are the three principle cases a media fragment enabled UA and a media Server will encounter:

5.1.1.1 UA requests URI fragment for the first time

A user requests a media fragment URI:

• User → UA (1):

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

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:

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

  GET /video.ogv HTTP/1.1
  Host: www.example.com
  Accept: video/*
  Range: bytes=19147-22890

The server extracts the bytes corresponding to the requested range and replies in a 206 HTTP response:

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

  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}

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.

5.1.1.2 UA requests URI fragment it already has buffered

A user requests a media fragment URI:

• User → UA (1):

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

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:

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

  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

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

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

  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"

So, the UA serves the decoded resource to the User our of its existing buffer.

5.1.1.3 UA requests URI fragment of a changed resource

A user requests a media fragment URI and the UA sends the exact same GET request as described in the previous subsection.

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:

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

  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"

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.

5.1.2 Server mapped byte ranges

As described in section 3.3 Resolving URI fragments with server help, 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.

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.

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):

Range                  = "Range" ":" ranges-specifier
ranges-specifier       = byte-ranges-specifier | fragment-specifier
;
; note that ranges-specifier is extended from RFC 2616
; 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

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.

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.

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.

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:

• 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 3 URI fragment and URI query, spatial fragment extraction is in this case better represented by URI queries.

• When a User Agent receives an extracted spatial media fragment, it is not trivial to visualize the context of this fragment (see also section 7.1 Clients Displaying Media Fragments). 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.

Editorial note: Davy
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.

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:

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

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

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

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

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.

5.1.2.1 Server mapped byte ranges with corresponding binary data

• User → UA (1):

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

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 5.1.1.2 UA requests URI fragment it already has buffered and 5.1.1.3 UA requests URI fragment of a changed resource, 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:

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

  GET /video.ogv HTTP/1.1
  Host: www.example.com
  Accept: video/*
  Range: t:npt=10-20

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 RFC 2616. 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.

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 RFC 2616.

Here is the reply to the example above, assuming a single byte range is sufficient:

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

  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}

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.

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:

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

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

Note that a caching proxy that does not understand a Range header must not cache "206 Partial Content" responses as per HTTP RFC RFC 2616. Thus, the new Range requests won't be cached by legacy Web proxies.

5.1.2.2 Server mapped byte ranges with corresponding binary data and codec setup data

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:

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

  GET /video.ogv HTTP/1.1
  Host: www.example.com
  Accept: video/*
  Range: t:npt=10-20;include-setup

Analogous to section 5.1.2.1 Server mapped byte ranges with corresponding binary data, 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:

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

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

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.

5.1.2.3 Proxy cacheable server mapped byte ranges

As described in section 3.4 Resolving URI fragments in a proxy cacheable manner, 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.

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.

The ABNF for these additional two HTTP headers is given as follows:

Accept-Range-Redirect      = "Accept-Range-Redirect" ":" bytes-unit

Range-Redirect             = "Range-Redirect" ":" byte-range-resp-spec *( "," byte-range-resp-spec )

Let's play it through on an example. A user requests a media fragment URI:

• User → UA (1):

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

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 5.1.1.2 UA requests URI fragment it already has buffered and 5.1.1.3 UA requests URI fragment of a changed resource, 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:

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

  GET /video.ogv HTTP/1.1
  Host: www.example.com
  Accept: video/*
  Range: t:npt=10-20
  Accept-Range-Redirect: bytes

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.

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

  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

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.

The UA proceeds to put the actual fragment request through as a normal byte range request as in section 5.1.1.1 UA requests URI fragment for the first time:

• UA (5) → Proxy (6) → Origin Server (7):

  GET /video.ogv HTTP/1.1
  Host: www.example.com
  Accept: video/*
  Range: 19147-22880

The Origin Server puts the data together and sends it to the UA:

• Origin Server (7) → Proxy (8) → UA (9):

  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}

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.

5.2 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"
  Link: <http://www.example.com/video.ogv#t=10,20>; rel="alternate"
  
  {binary data}

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.

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.

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.1.2.3 Proxy cacheable server mapped byte ranges.

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.

6.1 Errors on the General URI level

6.2 Errors on the temporal dimensions

Assuming a single temporal dimension is present, we now analyse what fragment values may be specified here and how they should be handled.

For this, we make the following definitions:

• s: the start point of the media and s >= 0
• e: the end point of the media (i.e. duration = e - s ) and s < e
• a: a positive integer, a >= 0
• b: a positive integer, b >= 0

6.3 Errors on the spatial dimensions

Assuming a single spatial dimension is present, we now analyse what content can appear here and how it should be handled.

6.4 Errors on the track dimensions

Assuming a single track dimension is present, we now analyse what content can appear here and how it should be handled.

6.5 Errors on the named dimensions

Assuming a single named dimension is present, we now analyse what content can appear here and how it should be handled.

7.1 Clients Displaying Media Fragments

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.

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.

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.

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.

7.2 All Media Fragment Clients

Resolution Order: 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.

Media Fragment Grammar: 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.

External Clipping: 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: <smil:video clipBegin="5" clipEnd="15" src="http://www.example.com/example.mp4#t=100,200"/>. This should start playback of the original media resource at second 105, and stop at 115.

Content-Range-Mapping: The Content-Range-Mapping header returned sometimes refers to a completely different range than the one that was specified as the Range: 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.

7.3 Media Fragment Servers

Media type: 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.

Synchronisation: 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.

Embedded Timecodes: 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.

SMPTE Timecodes: 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.

Reasonable Clipping: 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 http://www.example.org/video.ogv#t=60,100, but the closest decodable range is t=58,102 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.

Reasonable byte ranges: 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.

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