[whatwg] Start position of media resources

[Silvia Pfeiffer]

> On Wed, 8 Apr 2009, Silvia Pfeiffer wrote:
>>
>> Note that in the Media Fragment working group even the specification of
>> http://www.example.com/t.mov#time="10s-20s" may mean that only the
>> requested 10s clip is delivered, especially if all the involved
>> instances in the exchange understand media fragment URIs.
>
> That doesn't seem possible since fragments aren't sent to the server.

The current WD of the Media Fragments WG
http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-reqs/
specifies that a URL that looks like this
http://www.w3.org/2008/WebVideo/Fragments/media/fragf2f.mp4#t=12,21
is to be resolved on the server through the following basic process:

1. UA chops off the fragment and turns it into a HTTP GET request with
a newly introduced time range header
e.g.
GET /2008/WebVideo/Fragments/media/fragf2f.mp4 HTTP/1.1
Host: www.w3.org
Accept: video/*
Range: seconds=12-21

2. The server slices the multimedia resource by mapping the seconds to
bytes and extracting a playable resource (potentially fixing container
headers). The server will then reply with the closest inclusive range
in a 206 HTTP response:
e.g.
HTTP/1.1 206 Partial Content
Accept-Ranges: bytes, seconds
Content-Length: 3571437
Content-Type: video/mp4
Content-Range: seconds 11.85-21.16


So, while that the fragment part of the URI is indeed not transferred
in the URI, there is another mechanism to still deliver it.

This is basically the same as what we have done with temporal URIs for
Ogg but using the query URI mechanism. The problem with using a query,
however, is that the query creates a new resource, while the fragment
is partial content of a resource, which is really the way in which we
want to look at media fragments.


> On Thu, 9 Apr 2009, Jonas Sicking wrote:
>>
>> If we look at how fragment identifiers work in web pages today, a link
>> such as
>>
>> http://example.com/page.html#target
>>
>> this displays the 'target' part of the page, but lets the user scroll to
>> anywhere in the resource. This feels to me like it maps fairly well to
>>
>> http://example.com/video.ogg#t=5s
>>
>> displaying the selected frame, but displaying a timeline for the full
>> video and allowing the user to directly go to any position.
>
> Agreed. This is how the spec works now.


This is also how we did it with Ogg and temporal URIs, but this is not
the way in which the standard for media fragment URIs will work.


>> But I also agree that there is a use case for directing the user to a
>> specific range of the video, such as your 30 second clip out of 5 hour
>> video example. Maybe this could be done with syntax like
>>
>> http://example.com/video.ogg#r=3600s-3630s
>
> Currently the spec has no way to indicate a stop time from the fragment
> identifier or other out-of-band information, but I agree that we might
> need to add something like that (e.g. implying a default cue range with
> autopause-on-exit enabled) at some point.

The WD of the Media Fragment WG has a stop time in it. We might want
to add a stopTime DOM attribute.


Cheers,
Silvia.