W3C home > Mailing lists > Public > public-media-fragment@w3.org > April 2009

Re: Use cases and requirements for Media Fragments: Chapter 8

From: Conrad Parker <conrad@metadecks.org>
Date: Wed, 8 Apr 2009 01:53:06 +0900
Message-ID: <dba6c0830904070953pe2bea7cs18aca9f7b9b12b26@mail.gmail.com>
To: Yves Lafon <ylafon@w3.org>
Cc: RaphaŽl Troncy <Raphael.Troncy@cwi.nl>, Media Fragment <public-media-fragment@w3.org>
2009/4/8 Yves Lafon <ylafon@w3.org>:
> On Tue, 7 Apr 2009, RaphaŽl Troncy wrote:
>
>> Dear all,
>>
>> I have added the chapter 8 in the main document, see
>> http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-reqs/#retrieving-fragment
>>
>> In particular, †I have drawn two graphics that hopefully will clarify
>> everything. I'm more than happy to receive any feedback on this section. Any
>> taker?
>
> In the 4 way handshake, the first request is not using Range requests.
> (and if it did, the first response would have been 206).
>
> What could be done is...
>
> Using conneg (but it would be quite ugly).
>
> GET http://www.w3.org/2008/WebVideo/Fragments/media/fragf2f.mp4 HTTP/1.1
> Accept: application/range-conversion-uri;q=1, video/*;q=0.5
>
> ->
> 307 Temporary Redirect
> Location:
> http://www.w3.org/2008/WebVideo/resolver/range-converter?video=2342fedca
>
> (but even there we need an API to know how to call the resolver).
>
> or...
> HEAD /2008/WebVideo/Fragments/media/fragf2f.mp4 HTTP/1.1
> Host: www.w3.org
>
> HTTP/1.1 200 OK
> Link: <http://www.example.org/my-range-resolver>;
> rel="http://www.w3.org/2008/WebVideo/range-resolver"
> Content-Type: video/whatever
> Content-Length: 12039012930
>
> (meta information of the whole video, without retrieving it)
>
> But you still need to know how to call the resolver (that info might be
> retrieved from the rel URI from the Link header)
>
>
> In any cases, the examples are a bit wrong, as only the "path query" part of
> the URI is in the GET .. HTTP/1.1 line.

Hi,

I've been thinking about generalizing this mechanism a bit recently to
allow caching of non-header data. Here's some notes towards that:

http://blog.kfish.org/2009/04/proposal-for-generalizing-byte-range.html

As for terminology, I really don't think the term "handshake" is
appropriate; especially when all that's really happening is that the
data retrieval is getting split across multiple HTTP requests.
Handshake seems to imply that just negotiation is going on, and that
this is delaying the actual data retrieval -- which isn't the case
here.

cheers,

Conrad.
Received on Tuesday, 7 April 2009 16:53:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 21 September 2011 12:13:32 GMT