Re: Media Fragment Question

Hi Chris,

Let me try to give you some answers.

On Wed, Jun 30, 2010 at 11:39 PM, Chris Double
<chris.double@double.co.nz> wrote:
> When a user requests a user agent to make a request with a URL
> containing a media fragment, how should the user agent decide when if
> it needs to send Range headers? For example, the media fragment spec
> shows the request for URL http://www.example.com/video.ogv#t=10,20:
>
> GET /video.ogv HTTP/1.1
> Host: www.example.com
> Accept: video/*
> Range: t:npt=10-20
>
> Is it expected that for every URL request with a fragment that matches
> the syntax of media fragments that the user agent will attempt to send
> the Range header? It can't know in advance if a request is for a media
> file. Or does it first make a request, identify it as a media file,
> then does another request with a Range?

In current implementations of the video/audio element, you also do
range requests to download the headers for setup. Once this is done,
you know whether the resource is a media resource and can use these
range requests. This has been the main target of the specification.

Note that you are not receiving a valid media resource when you use
fragments, but only byte ranges of the media resource (potentially
with an extra byte range for the headers). So, you cannot expect to
save a valid media resource from the fragments - so it should probably
be ignored anywhere outside an audio or video element.


> A user agent that does not support a particular media type (eg. a
> browser that doesn't support .ogv) obviously can't play a file. But if
> the page presents a link of the form:
>
> <a href ='http://example.com/video.ogv#t=10,20>right click me and save</a>
>
> Is it expected that the user agent, which supports media fragments,
> would send the range requests to ensure only the correct time range is
> saved even if the user agent itself can't play the file? If so, that
> seems to indicate that the Range request needs to be sent on every
> single request made by the user agent which doesn't sound like a good
> idea.

Such a request won't result in a valid media resource and even if
saved won't be playable. There are two things that a browser can do:
* one is to ignore the fragment and download the full resource
* second is to turn the fragment into a query, e.g.
http://example.com/video.ogv?t=10,20 and hope that there is a server
behind it that can interpret that query, encode the file on the server
into a proper new resource and return it.

I am not sure if the second option is one that makes sense to browsers
and as long as there aren't many servers that actually support the
"transcoding", it won't be of much use anyway and return the full
resource anyway. So, maybe you want to do the first option unless the
resource is clearly in a audio or video element, or maybe it is
directly addressed and you can try the header retrieval first to
confirm it's a media resource and set up decoding.

> A couple of minor nits:
>
> 1) "unnecssary" is incorrect spelling in one place.

Thanks.

> 2) "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." Should that be "typically
> implemented in Web servers"?

Good catch.

> 3) "Wall-clock time codes are a way to address real-world clock time
> that is associated typically with a live video stream. These are the
> same time codes that are being used by ... and by HTML5 HTML 5." Were
> are wall clock time codes with dates used in HTML 5 media?
> 'currentTime' is seconds for example.

I think this refers to
http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#global-dates-and-times


> 4) "This section defines the different exchange scenarios for the
> different situations explained in section 3 URI fragment and URI query
> over the HTT¨protocol. " That should be "HTTP protocol" I think.

Again, good catch - it's easily missed when proofreading!

Cheers,
Silvia.

Received on Wednesday, 30 June 2010 23:02:57 UTC