Use cases and requirements for Media Fragments

3.1 Single Media Resource Definition

The following picture explains the generic composition of a media resource:

A media resource for the purposes of this Working Group is defined along a single timeline. It can consist of multiple tracks of data that are parallel along this timeline. These tracks can be audio, video, images, text or any other time-aligned data. The main interest of this group is in audio and video. A media resource also typically has some control information in data headers. These may be located at a particular position in the resource, e.g. the beginning or the end, or spread throughout the data tracks as headers for data packets. There is possibly also a general header for the complete media resource. The data tracks are typically encoded in an interleaved fashion, which allows for progressive decoding. All of this is provided in a single file.

3.2 Existing Standards

Media fragment URIs will work within the boundaries of existing standards as much as possible, in particular within the URI specification RFC 3986.

3.3 Unique Resource

Media fragments are a representation of the parent resource and should not create a new resource, in particular not a new resource of a different Internet media type (or MIME type). Note that there are use cases for creating a new resource, such as the extraction of a thumbnail from a video. These are currently outside the scope of this document.

3.4 Valid Resource

Resources delivered as a response to a media fragment URI request should be valid media resources by themselves and thus be playable by existing media players / image viewers.

3.5 Parent Resource

The entire resource should be accessible as the "context" of a fragment via a simple change of the URI. The media fragment URI - as a selective view of the resource - provides a mechanism to focus on a fragment whilst hinting at the wider media context in which the fragment is included.

3.6 Single Fragment

A media fragment URI should create only a single "mask" onto a media resource and not a collection of potentially overlapping fragments.

3.7 Relevant Protocols

The main protocols we are concerned with are HTTP and RTSP, since they are open protocols for media delivery.

3.8 No Recompression

Media fragments should preferably be delivered as byte-range subparts of the media resource such as to make the fragments an actual subresource of the media resource. The advantage of this is that such fragments are cachable as byte ranges in existing caching Web proxies. This implies that we should avoid to decode and recompress a media resource to create a fragment.

3.9 Minimize Impact on Existing Infrastructure

The necessary changes to all software in the media delivery chain should be kept to a minimum: User Agents, Proxies, Media Servers.

3.10 Focus for Changes

Focus for necessary changes should be as much as possible on the media servers because in any case they have to implement fragmentation support for the media formats as the most fundamental requirement for providing media fragment addressing.

3.11 Browser Impact

Changes to the user agent need to be a one-off and not require adaptation per media encapsulation/encoding format.

3.12 Fallback Action

If a User Agent connects with a media fragment URI to a media server that does not support media fragments, the media server should reply with the full resource. The User Agent will then have to take action to either cancel this connection (if e.g. the media resource is too long) or do a fragment offset locally.

A User Agent that does not understand media fragment URIs will simply hand on the URI (potentially with a stripped off fragment part) to the server and receive the full resource in lieu of the fragment. This may lead to unexpected behaviour with media fragment URIs in non-conformant User Agents, e.g. where a mash-up of media fragments is requested, but a sequence of the full files is played. This is acceptable during a transition phase.

4.1 Linking to and Display of Media Fragments

In this use case, a user is only interested in consuming a fragment of a media resource rather than the complete resource. A media fragment URI allows addressing this part of the resource directly and thus enables the User Agent to receive just the relevant fragment.

4.2 Browsing and Bookmarking Media Fragments

Media resources - audio, video and even images - are often very large resources that users want to explore progressively. Progressive exploration of text is well-known in the Web space under the term "pagination". Pagination in the text space is realized by creating a series of Web pages and enabling paging through them by scripts on a server, each page having their own URI. For large media resources, such pagination can be provided by media fragment URIs, which enable direct access to media fragments.

4.3 Recompositing Media Fragments

As we enable direct linking to media fragments in a URI, we can also enable simple recompositing of such media fragments. Note that because the media fragments in a composition may possibly originate from different codecs and very different files, we can not realistically expect smooth playback between the fragments.

4.4 Annotating Media Fragments

Media resources typically don't just consist of the binary data. There is often a lot of textual information available that relates to the media resource. Enabling the addressing of media fragments ultimately creates a means to attach annotations to media fragments.

4.5 Adapting Media Resources

When addressing a media resource as a user, one often has the desire not to retrieve the full resource, but only a subpart of interest. This may be a temporally or spatially consecutive subpart, but could also be e.g. a smaller bandwidth version of the same resource, a lower framerate video, a image with less colour depth or an audio file with a lower sampling rate. Media adaptation is the general term used for such server-side created versions of media resources.

5.1 Requirement r01: Temporal fragments

A temporal fragment of a media resource is a clipping along the time dimension from a start to an end time that are within the duration of the media resource.

Whether a media resource supports temporal fragment extraction is in the first place dependent on the coding format and more specifically how encoding parameters were set. For video coding formats, temporal fragments can be extracted if the video stream provides random access points (i.e., a point that is not dependent on previously encoded video data, typically corresponding to an intra-coded frame) on a regular basis. The same holds true for audio coding formats, i.e., the audio stream needs to be accessible at a point where the decoder can start decoding without the need of previous coded data.

5.2 Requirement r02: Spatial fragments

A spatial fragment of a media resource is a clipping of an image region. For media fragment addressing we only regard rectangular regions.

Support for extraction of spatial fragments from a media resource in the compressed domain depends on the coding format. The coding format must allow to encode spatial regions independently from each other in order to support the extraction of these regions in the compressed domain. Note that there are currently two variants: region extraction and interactive region extraction. In the first case, the regions (i.e., Regions Of Interest, ROI) are known at encoding time and coded independently from each other. In the second case, ROIs are not known at encoding time and can be chosen by a user agent. In this case, the media resource is divided in a number of tiles, each encoded independently from each other. Subsequently, the tiles covering the desired region are extracted from the media resource.

5.3 Requirement r03: Track fragments

A typical media resource consists of multiple tracks of data multiplexed together into the media resource. A media resource could for example consist of several audio, several video, and several textual annotation or metadata tracks. Their individual extraction / addressing is desirable in particular from a media adaptation point of view.

Whether the extraction of tracks from a media resource is supported or not depends on the container format of the media resource. Since a container format only defines a syntax and does not introduce any compression, it is always possible to describe the structures of a container format. Hence, if a container format allows the encapsulation of multiple tracks, then it is possible to describe the tracks in terms of byte ranges. Examples of such container formats are Ogg RFC 3533 and MP4. Note that it is possible that the tracks are multiplexed, implying that a description of one track consists of a list of byte ranges. Also note that the extraction of tracks (and fragments in general) from container formats often introduces the necessity of syntax element modifications in the headers.

5.4 Requirement r04: Named fragments

A named fragment of a media resource is a media fragment - either a track, a time section, or a spatial region - that has been given a name through some sort of annotation mechanism. Through this name, the media fragment can be addressed in a more human-readable form.

No coding format provides support for named fragments, since naming is not part of the encoding/decoding process. Hence, we have to consider container formats for this feature. In general, if a container format allows the insertion of metadata describing the named fragments, then the container format supports named fragments, if the fragment class is also supported. For example, you can include a CMML CMML or TimedText description in an MP4 or Ogg RFC 3533 container and interpret this description to extract temporal fragments based on a name given to them in the description.

5.5 Fitness Conditions on Media Containers/Resources

There is a large number of media codecs and encapsulation formats that we need to take into account as potential media resources on the Web. This section analyses the general conditions for media formats that make them fit for supporting the different types of fragment URIs.

Media resources should fulfill the following conditions to allow extraction of fragments:

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

• Fit: 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 on the byte level is possible.

• Conditionally fit: Media fragments can be extracted in the compressed domain, but syntax element modifications are required. These media fragments provide cacheable byte ranges for the data, but syntax element modifications are needed in headers applying to the whole media resource/fragment. In this case, these headers could be sent to the client in the first response of the server.

• Unfit: Media fragments cannot be extracted in the compressed domain as byte ranges. In this case, transcoding operations are necessary to extract media fragments. Since these media fragments do not create reproducible bytes, it is not possible to cache these media fragments. 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.

Those media types that are capable of doing what server-side media fragments require are of interest to us. For those that aren't, the fall-back case applies (i.e. full download and then offsetting). Appendix B Evaluation of fitness per media formats lists a large number of typical formats and determines which we see fit, conditionally fit, or currently unfit for supporting the different types of media fragment URIs.

6.1 General Structure

To name a media fragment, one needs to find ways to convey this information. Our solution builds on URIs as of RFC 3986 and hence there are two possibilities for representing the media fragment addressing: the URI query part or the URI fragment part.

As of this writing, the group has a preference to use the URI fragment part, because this maintains the relationship between the main resource and the media fragment. Using the query part would result in a new resource being created. Hence, hash (#) is used as the separator between the base URI and the media fragment.

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

Media fragments support fragmenting the media along the four dimensions listed in 5 Requirements for Media Fragment URIs:

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 6.4 Semantics.

6.2 Fragment Dimensions

t=10,20
t=,20
t=10,

t=10,20
t=npt:10,20

t=120,
t=,121.5
t=120s,121.5s
t=0:02:00,121.5
t=npt:120,0:02:01.5

t=smpte-30:0:02:00,0:02:01:15
t=smpte-25:0:02:00:00,0:02:01:12.1

xywh=160,120,320,240
xywh=pixel:160,120,320,240
xywh=percent:25,25,50,50

aspect=4:3
aspect=16:9

track='1'
track='video'
track='Wide%20Angle%20Video'

id='1'
id='chapter-1'
id='Airline%20Edit'

6.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 / othertimedef
npttimedef    = [ deftimeformat ":"] [ clocktime ] "," [ clocktime ]
othertimedef  = timeformat ":" [frametime] "," [frametime]
deftimeformat = %x6E.70.74                                ; "npt"
timeformat    = %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"
timeunit      = %x73                                      ; "s"
clocktime     = ( 1*DIGIT [ "." 1*DIGIT ] [timeunit] ) /
               ( 1*DIGIT ":" 2DIGIT ":" 2DIGIT [ "." 1*DIGIT] )
frametime     = 1*DIGIT ":" 2DIGIT ":" 2DIGIT [ ":" 2DIGIT [ "." 2DIGIT ] ]
;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Space Segment ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;
spacesegment  = xywhdef / aspectdef
xywhdef       = xywhprefix   "=" xywhparam
aspectdef     = aspectprefix "=" aspectparam
xywhprefix    = %x78.79.77.68                             ; "xywh"
aspectprefix  = %x61.73.70.65.63.74                       ; "aspect"
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"
aspectparam   = 1*DIGIT ":" 1*DIGIT
;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; 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

		

6.4 Semantics

The mimetype of the fragment should be the same as the mimetype of the source media. Among other things, this means that selection of a single video frame results in a movie, not in a still image.

Implementations are expected to first do track and time selection, on the container level, and then do spatial clipping on the codec level.

A media fragment URI may be used in a context that has its own clipping method, such as SMIL. This leads to a semantic issue of how the clipping methods combine: do they cascade, or does one override the other? Formally, this is up to the context embedding the media fragment URI, but in the absence of strong reasons to do otherwise we suggest cascading. So, the following should start playback of the original media at second 105, and stop at 115:

<smil:video clipBegin="5" clipEnd="15" src="http://www.example.com/example.mp4#t=100,200"/>

Attempting to do fragment selection on a dimension that does not exist in the source media, such as temporal clipping on a still image, should be considered a no-op.

The result of doing spatial clipping on a source media that has multiple video tracks is undefined if no track selection is also applied.

7.1 Single-step Partial GET

A user requests a media fragment URI, for example using a web browser:

• User → UA (1):

http://www.w3.org/2008/WebVideo/Fragments/media/fragf2f.mp4#t=12,21

UA chops off the fragment and turns it into a HTTP GET request with a time range header:

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

GET /2008/WebVideo/Fragments/media/fragf2f.mp4 HTTP/1.1
Host: www.w3.org
Accept: video/*
Range: seconds=12-21

The server has a module for slicing on demand multimedia resources, that is, establishing the relationship between seconds and bytes, extract the bytes corresponding to the requested fragment, and add the new container headers in order to serve a playable resource. The server will then reply with the closest inclusive range in a 206 HTTP response:

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

HTTP/1.1 206 Partial Content
Accept-Ranges: bytes, seconds
Content-Length: 3571437
Content-Type: video/mp4
Content-Range: seconds 11.85-21.16

The user agent will then have to skip 0.15s to start playing the multimedia fragment as 12s.

7.2 Dual-step Partial GET

A user requests a media fragment URI, for example using a web browser:

• User → UA (1):

http://www.w3.org/2008/WebVideo/Fragments/media/fragf2f.mp4#t=12,21

UA chops off fragment and turns it into a HTTP GET request with a time range header:

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

GET /2008/WebVideo/Fragments/media/fragf2f.mp4 HTTP/1.1
Host: www.w3.org
Accept: video/*
Range: seconds=12-21
X-Accept-Range-Refer: bytes

Origin Server converts time range to byte range and puts all header data, occurring at the beginning of the media resource, that cannot be cached but is required by the UA to receive a fully functional media resource into the HTTP response. It also replies with a X-Accept-TimeURI header that indicates to the client that it has processed the time request and converted to bytes (similarly this could be extended to X-Accept-SpaceURI, X-Accept-TrackURI and X-Accept-NameURI). The message body of this answer contains the control section of fragf2f.mp4#12,21 (if required).

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

HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Type: video/mp4
X-Accept-TimeURI: npt, smpte-25
X-Range-Refer: bytes 1113724-2082711
Vary: X-Accept-Range-Refer
Location: http://www.w3.org/2008/WebVideo/Fragments/media/fragf2f.mp4

The UA buffers the data it receives for hand-over to the media subsystem. It then proceeds to put the actual fragment request through:

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

GET http://www.w3.org/2008/WebVideo/Fragments/media/fragf2f.mp4 HTTP/1.1
Range: bytes 1113724-2082711

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

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

HTTP/1.1 206 Partial Content
Accept-Ranges: bytes
Content-Type: video/mp4
Content-Range: bytes 1113724-2082711

The UA hands over the header and video data to the media subsystem and therefore display it to the user (9).

7.3 Discussion

Pro:

1. Single-step partial GET needs only one roundtrip

2. Single-step partial GET allows to extract a spatial region from a Motion JPEG2000

3. Single-step partial GET usually achieves what we want without needing HTTP protocol extension for any resource with an intrinsic time → data map such as .mov, .mp4.

4. Dual-step partial GET allows current web proxies to cache media fragments

Cons

1. In both cases, we create a custom Range unit (e.g. 'seconds'). We would need to create custom range unit to convey the notion of seconds, pixels, tracks, etc.

2. Dual-step partial GET need two roundtrips

3. Dual-step partial GET does not allow to extract a spatial region from a Motion JPEG2000. Note though that all other media formats are characterized by a fixed non-cacheable header occurring at the beginning of the media stream and are thus compatible with the dual-step partial GET approach

4. Single-step partial GET requires specialized 'media'-caches to cache media fragments

Using HTTP byte ranges to request media fragments enables existing HTTP proxies and caches to inherently support the caching of media fragments. This approach is possible if a dual-step partial GET is applied. This method, however, does not deliver complete resources, but rather generates an infinite number of resources to create the control section of the transmitted fragments, and extra care is needed when fetching different part to avoid fetching data from changing resources. Those new resources containing the control section of the fragments to be retrieved form an other resource that needs to be known by all clients, which has a big implementation cost, but has no impact on Caches.

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 fulfill 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 cachable 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.

8.1 Existing URI fragment schemes

Some existing URI schemes define semantics for fragment identifiers. In this section, we list these URI schemes and provide examples of their fragment identifiers.

8.2 Existing applications using proprietary temporal media fragment URI schemes

In this section, we list a number of proprietary URI schemes which are able to identify media fragments. Note that all of these schemes only provide support for addressing temporal media fragments.

• Google Video (announcement)

  http://video.google.com/videoplay?docid=3047771997186190855&ei=MCH-SNfJD5HS2gKirMD2Dg&q=%22that%27s+a+tremendous+gift%22#50m16s

  Syntax: #50m16s
• YouTube (announcement)

  http://www.youtube.com/watch?v=1bibCui3lFM#t=1m45s

  Syntax: #t=1m45s
• Archive.org (uses the temporalURI specification temporal URI)

  http://www.archive.org/download/to-SF/toSF_512kb.mp4?t=74.5

  Syntax: ?t=74.5
• Videosurf (announcement)

  http://www.videosurf.com/video/michael-jordan-1989-playoffs-gm-5-vs-cavs-the-shot-904591?t=140&e=184

  Syntax: ?t=140&e=184 (with t=start, e=end)

8.3 Media fragment specification approaches

http://upload.wikimedia.org/wikipedia/commons/1/1b/Yalta_Conference.svg#svgView(14.64,15.73,146.98,147.48)

<a href="http://example.com/video.ogv#t=12.3/21.16" />
<a href="http://example.com/video.ogv?t=12.3/21.16" />

<a href="http://example.com/video.ogv?t=npt:12.3/21.16" />
<a href="http://example.com/video.ogv?t=smpte-25:00:12:33:06/00:21:16:00" />
<a href="http://example.com/audio.ogv?t=clock:20021107T173045.25Z" />

<ROE>
 <head>
  <link rel="alternate" type="text/html" href="http://example.com/complete_video.html" />
 </head>
 <body>
  <track id="v" provides="video">
   <seq>
    <mediaSource id="v0" src="http://example.com/video.ogv" content-type="video/ogg" />
    <mediaSource id="v1" src="http://example.com/theora.ogv?track=v1" content-type="video/theora" />
   </seq>
  </track>
  <track id="a" provides="audio">
   <mediaSource id="a1" src="http://example.com/theora.ogv?track=a1" content-type="audio/vorbis" />
  </track>
  <track id="c1" provides="caption">
   <mediaSource src="http://example.com/cmml1.cmml" content-type="text/cmml" />
  </track>
  <track id="c2" provides="ticker">
   <mediaSource src="http://example.com/cmml2.cmml" content-type="text/cmml" />
  </track>
 </body>
</ROE>
              

<video src="http://example.com/video.ogv?track=a/v/c1"/>

<clip id="tic1" start="npt:12.3" end="npt:21.16" title="Introduction">
 <a href="http://example.com/fish.ogv?t=5" >Watch another fish video.</a>
 <meta name="author" content="Frank"/>
 <img src="fish.png"/>
 <body>This is the introduction to the film Joe made about fish.</body>
</clip>
                

<a href="http://example.com/sample.cmml?t=npt:4" />

<a href="http://example.com/sample.cmml?id="tic1" />

<video xml:id="toc1" src="http://www.w3.org/2008/WebVideo/Fragments/media/fragf2f.mp4" clipBegin="12.3s" clipEnd="21.16s" />

<video xml:id="toc2" src="http://www.w3.org/2008/WebVideo/Fragments/media/fragf2f.mp4" clipBegin="npt=12.3s" clipEnd="npt=21.16s" />
<video xml:id="toc3" src="http://www.w3.org/2008/WebVideo/Fragments/media/fragf2f.mp4" clipBegin="smpte=00:00:12:09" clipEnd="smpte=00:00:21:05" />
                

<video xml:id="toc4" src="http://www.w3.org/2008/WebVideo/Fragments/media/fragf2f.mp4" clipBegin="12.3s" clipEnd="21.16s">
 <metadata>
  <rdf:.... xmlns:rdf="....">
   ....
  </rdf:...>
 </metadata>
</video>
                

<video xml:id="tic1" src="http://www.w3.org/2008/WebVideo/Fragments/media/fragf2f.mp4" >
 <area begin="12.3s" end="21.16s" href="http://www.example.com" />
</video>
                

<video xml:id="tic2" src="http://www.w3.org/2008/WebVideo/Fragments/media/fragf2f.mp4" >
 <area xml:id="tic2area" begin="12.3s" end="21.16s"/>
</video>
                

http://www.example.com/smilpresentation#tic2area

<video xml:id="soc1" src="http://www.w3.org/2008/WebVideo/Fragments/media/fragf2f.mp4" panZoom="25%, 25%, 50%, 50%"/>

<video xml:id="soc2" src="http://www.w3.org/2008/WebVideo/Fragments/media/fragf2f.mp4" panZoom="160, 120, 320, 240" />

<video xml:id="soc3" src="http://www.w3.org/2008/WebVideo/Fragments/media/fragf2f.mp4" panZoom="0, 0, 640, 480" />
 <animate begin="10s" dur="5s" fill="freeze" attributeName="panZoom" to="160, 120, 320, 240 />
</video>
                

<video xml:id="tic1" src="http://www.w3.org/2008/WebVideo/Fragments/media/fragf2f.mp4" >
 <area shape="rect" coords="50%, 0%, 100%, 50%" href="http://www.example.com" />
</video>
                

<video xml:id="st1" src="http://www.w3.org/2008/WebVideo/Fragments/media/fragf2f.mp4" >
 <param name="jacks-remove-track" value="audio" />
</video>
                

<video xml:id="nf1" src="http://www.w3.org/2008/WebVideo/Fragments/media/fragf2f.mp4" >
 <area begin="nf1.marker(jack-frag-begin)" end="nf1.marker(jack-frag-end)" href="http://www.example.com" />
</video>
                

<VideoSegment id=”video” >
  <MediaLocator>
    <MediaUri>http://www.w3.org/2008/WebVideo/Fragments/media/fragf2f.mp4</MediaUri>
  </MediaLocator>
  <TemporalDecomposition>
    <VideoSegment id=”shot1”>
      <TextAnnotation>
        <KeywordAnnotation>
          <Keyword>…</Keyword>
        </KeywordAnnotation>
      </TextAnnotation>
      <MediaTime>
        <MediaTimePoint>T00:00:06:2002F25000</MediaTimePoint>
        <MediaDuration>PT9S13389N25000F</MediaDuration>
      </MediaTime>
    </VideoSegment>
  </TemporalDecomposition>
</VideoSegment>

<VideoSegment>
  <SpatialDecomposition>
    <StillRegion id = “speaker”>
      <TextAnnotation>
        <FreeTextAnnotation> Journalist</FreeTextAnnotation>
      </TextAnnotation>
      <Mask xsi:type="SpatialMaskType">
        <SubRegion>
          <Poly>
            <Coords> 40 300, 40 210, ..., 320 300</Coords>
          </Poly>
        <SubRegion>
      </Mask>
    </StillRegion>
  </SpatialDecomposition>
</VideoSegment>

<VideoSegment>
  <SpatialTemporalDecomposition>
    <MovingRegion>
      <SpatioTemporalLocator>
        <MediaTime>
          <MediaTimePoint>T00:00:06:2002F25000</MediaTimePoint>
          <MediaDuration>PT9S13389N25000F</MediaDuration>
        </MediaTime>
      </SpatioTemporalLocator>
      <SpatioTemporalMask>
        <Mask xsi:type="SpatialMaskType">
          <SubRegion>
            <Poly>
              <Coords> 40 300, 105 210, ..., 320 240</Coords>
            </Poly>
          <SubRegion>
        </Mask>
      </SpatioTemporalMask>
    </MovingRegion>
  </ SpatialTemporalDecomposition >
</VideoSegment>

<Image id="image_yalta">           <!-- whole image -->
  <MediaLocator>
    <MediaUri>http://upload.wikimedia.org/wikipedia/commons/1/1b/Yalta_Conference.jpg</MediaUri>
  </MediaLocator>
  [...]
  <SpatialDecomposition>
    <StillRegion id="SR1">          <!-- still region -->
      <SpatialMask>
        <SubRegion>
          <Box>14.64 15.73 161.62 163.21</Box>
        <SubRegion>
      </SpatialMask>
    </StillRegion>
  </SpatialDecomposition>
</Image>

<Mpeg7>
  <Description xsi:type="ContentEntityType">
    <MultimediaContent xsi:type="MultimediaType">
      <Multimedia>
        <MediaSourceDecomposition gap="false" overlap="false">
          <Segment xsi:type="VideoSegmentType">
            <TextAnnotation>
              <FreeTextAnnotation>video</FreeTextAnnotation>
            </TextAnnotation>
            <MediaTime>
              <MediaTimePoint>T00:00:00</MediaTimePoint>
              <MediaDuration>PT0M15S</MediaDuration>
            </MediaTime>
          </Segment>
          <Segment xsi:type="AudioSegmentType">
            <TextAnnotation>
              <FreeTextAnnotation>audio</FreeTextAnnotation>
            </TextAnnotation>
          </Segment>
        </MediaSourceDecomposition>
      </Multimedia>
    </MultimediaContent>
  </Description>
</Mpeg7>
                

<StillRegion id="speaker">
  ...
</StillRegion>

http://www.example.com/mpeg7file.mp7#speaker

<foreignObject>
  <div xmlns="http://www.w3.org/1999/xhtml">
    <video src="myvideo.ogg"/>
  </div>
</foreignObject>

<svg xmlns="http://www.w3.org/2000/svg" version="1.2" xmlns:xlink="http://www.w3.org/1999/xlink" width="320" height="240" viewBox="0 0 320 240">
  <desc>SVG 1.2 video example</desc>
  <g>
    <video xlink:href="test.avi" volume=".8" type="video/x-msvideo" width="320" height="240" x="50" y="50" begin=”5s” dur=”20.0s” repeatCount="indefinite"/>
  </g>
</svg>

<svg xmlns:svg="http://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
  <g id="layer1">
    <"image" id="image_yalta" x="-0.34" y="0.20" width="400" height="167"
      xlink:href="http://upload.wikimedia.org/wikipedia/commons/1/1b/Yalta_Conference.jpg"/>
    <"rect" id="SR1" x="14.64" y="15.73" width="146.98" height="147.48"
      style="opacity:1;stroke:#ff0000;stroke-opacity:1"/>
  </g>
</svg>

<TVAMain>
  <ProgramDescription>
    <ProgramInformationTable>
    ...
    </ProgramInformationTable>
    <ProgramLocationTable>
    ...
    </ProgramLocationTable>
    <SegmentInformationTable>
      <SegmentList>
        <SegmentInformation segmentId="segment_2">
          ...
          <SegmentLocator>
            <MediaRelTimePoint>T00:00:06:2002F25000</MediaRelTimePoint>
            <MediaDuration>PT9S13389N25000F</MediaDuration>
          </SegmentLocator>
          ...
        </SegmentInformation>
      </SegmentList>
    </SegmentInformationTable>
  </ProgramDescription>
</TVAMain>

http://www.example.com/tv_anytime_description.tva#xpointer(//*[@segmentId="segment_2"])

<img src="image.gif" usemap="#my_map"/>
<map name="my_map">
  <a href="guide.html" shape="rect" coords="0,0,118,28">Access Guide</a> |
  <a href="shortcut.html" shape="rect" coords="118,0,184,28">Go</A> |
  <a href="search.html" shape="circle" coords="184,200,60">Search</A> |
  <a href="top10.html" shape="poly" coords="276,0,276,28,100,200,50,50,276,0">Top Ten</A>
</map>

<map name="my_map">
  <area href="guide.html" alt="Access Guide" shape="rect" coords="0,0,118,28">
  <area href="search.html" alt="Search" shape="rect" coords="184,0,276,28">
  <area href="shortcut.html" alt="Go" shape="circle"coords="184,200,60">
  <area href="top10.html" alt="Top Ten" shape="poly" coords="276,0,276,28,100,200,50,50,276,0">
</map>

<a href="http://www.example.com/images" >
  <img src="image.gif" ismap alt="target"/>
</a>