Re: Media Fragment Question

On Thu, 1 Jul 2010, Chris Double 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?

Well, the UA have hints, like being the address given in a <video> tag, 
but sending such Range r

> 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 use of media fragment would be particulary bad, but in any case, an 
UA should not allow to save a 206 resonse on the disk as if it was the 
complete resource.

> A couple of minor nits:
>
> 1) "unnecssary" is incorrect spelling in one place.
> 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"?

No, it is not a browser-implementation behaviour, see:
<<
    If a range unit is not understood in a request, a server MUST ignore
    the whole Range header (Section 5.4).  If a range unit is not
    understood in a response, an intermediary SHOULD pass the response to
    the client; a client MUST fail.
>>


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

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

Received on Tuesday, 28 September 2010 21:06:24 UTC