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

Dear Yves,

> In the 4 way handshake, the first request is not using Range requests.
> (and if it did, the first response would have been 206).

Thanks, this is the feedback I was expected :-)
So it means, 
http://www.w3.org/2008/WebVideo/Fragments/wiki/HTTP_implementation is 
wrong ! I would first correct this page before moving the content into 
the WD.

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

Agree, the conneg will be quite ugly in this case.

> 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)

I would prefer this solution. From 
http://www.w3.org/2008/WebVideo/Fragments/wiki/HTTP_implementation#4-way_handshake_or_2_roundtrips, 
I think I have assumed the range resolution (conversion between seconds 
and bytes) happening transparently on server side). It seems to me that 
what you're suggesting is that the range resolver is a service to be 
called, and that we will have a 3-ways handshake. Am I wrong?

The complete scenario would be:

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 STILL a 
time range header:

* UA → Proxy (2) → Origin Server (3):
GET http://www.w3.org/2008/WebVideo/Fragments/media/fragf2f.mp4 HTTP/1.1
Host: www.w3.org
Accept: video/*
Range: seconds=12-21

Origin Server sends the meta information of the whole video, without 
retrieving it. It sends information of how to call the resolver using 
the Link header.

* Origin Server → Proxy (4) → UA (5):
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/mp4
Content-Length: 3571437

The UA calls the range resolver that will convert the time range into 
byte range and put 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.

??? How that happen ???

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

So I miss how the UA calls the range resolver, and how did he get the 
answer. Could you please complete, either by answering or directly by 
modifying the wiki page?
Cheers.

   Raphaël

-- 
Raphaël Troncy
CWI (Centre for Mathematics and Computer Science),
Science Park 123, 1098 XG Amsterdam, The Netherlands
e-mail: raphael.troncy@cwi.nl & raphael.troncy@gmail.com
Tel: +31 (0)20 - 592 4093
Fax: +31 (0)20 - 592 4312
Web: http://www.cwi.nl/~troncy/

Received on Tuesday, 7 April 2009 19:26:51 UTC