ACTION-112: Digest of Conrad's vs Current's proposal for Media Fragment processing

Dear all,

ACTION-112 is a long time overdue action on my side. This is my take on 
it, which hopefully will trigger some discussion on the mailing list.

Conrad, please shout if I misunderstood your proposal! Dear are some 
questions also in the email that we need to answer.

1) Case 1: Resolving URI fragments with server help
---------------------------------------------------

Context: see Section 3.3 [1].
We have a fully media fragment conformant user agent
User request: 
http://www.w3.org/2008/WebVideo/Fragments/media/fragf2f.mp4#t=12,21

* 1.1: Current proposal:
The following HTTP request will be generated.
  GET /2008/WebVideo/Fragments/media/fragf2f.mp4 HTTP/1.1
  Host: www.w3.org
  Accept: video/*
  Range: time:npt=12-21

The following HTTP response will be returned (206 code).
  HTTP/1.1 206 Partial Content
  Accept-Ranges: bytes, seconds
  Content-Length: 3571437
  Content-Type: video/mp4
  Content-Range: time:npt 11.85-21.16/36

--> We took a resolution regarding the syntax of the Range and 
Content-Range headers, see [5], but we haven't take any regarding the 
syntax of Accept-Ranges. Should we put here 'seconds'? Or rather 'time'? 
Or 'time:npt'?

* 1.2: Conrad's proposal:
Conrad plans two sub-cases:
   . 1.2.a: the UA is aware of time ranges and can do the conversion 
locally. This comes to the Case 1.1
   . 1.2.b: the UA does not support time ranges. The following request 
will be issued:
  GET /2008/WebVideo/Fragments/media/fragf2f.mp4 HTTP/1.1
  Host: www.w3.org
  Accept: video/*
  Fragment: time:npt=12-21

A server that supports server-parsed fragments responds with (200 code)
  HTTP 200 OK
  Content-Length: 3571437
  Content-Fragment: time:npt=12-21
  Vary: Fragment

* Summary:
  . 1.1: NO new headers are necessary / normal use of Range request with 
206 response code
  . 1.2.a: This is fully similar to 1.1
  . 1.2.b: The 'Fragment' and 'Content-Fragment' headers are introduced 
/ 200 response code
  . In all cases, the body of the response contains the binary data of 
the fragment

--> I have to admit I cannot understand anymore the reason for 
introducing the 'Fragment' and 'Content-Fragment' headers with which we 
cannot use anymore the 206 /416 codes. Conrad ?

2) Case 2: Resolving URI fragments in a proxy cachable manner
-------------------------------------------------------------

Context: see Section 3.4 [2].
We have a fully media fragment conformant user agent and wish to make 
sure fragments will be cached by the network
User request: 
http://www.w3.org/2008/WebVideo/Fragments/media/fragf2f.mp4#t=12,21

* 2.1: Current proposal:
The following HTTP request will be generated.
  GET /2008/WebVideo/Fragments/media/fragf2f.mp4 HTTP/1.1
  Host: www.w3.org
  Accept: video/*
  Range: time:npt=12-21
  X-Accept-Range-Redirect: bytes

--> We introduce the 'X-Accept-Range-Redirect' header

The following HTTP response is returned (200 code)
  HTTP/1.1 200 OK
  Accept-Ranges: bytes
  Content-Type: video/mp4
  X-Accept-TimeURI: npt, smpte-25
  X-Range-Redirect: bytes 1113724-2082711/4500000
  Vary: X-Accept-Range-Redirect
  Location: http://www.w3.org/2008/WebVideo/Fragments/media/fragf2f.mp4

--> We introduce the 'X-Range-Redirect' header to tell the UA to issue 
another request
--> I don't like the 'X-Accept-TimeURI' header that could be more generic
--> Do we have an empty body at this step?

Another HTTP request is issued
  GET /2008/WebVideo/Fragments/media/fragf2f.mp4 HTTP/1.1
  Host: www.w3.org
  Range: bytes 1113724-2082711

Triggering the following response (206 code)
  HTTP/1.1 206 Partial Content
  Accept-Ranges: bytes
  Content-Type: video/mp4
  Content-Range: bytes 1113724-2082711/4500000

--> I don't understand how the cache can now map the bytes range with 
the original request in seconds?

* 2.2: Conrad's proposal:

Conrad introduced the Range-refer proposal. See [3] for the explanation 
and [4] for an example.

The following HTTP request will be generated.
  GET /2008/WebVideo/Fragments/media/fragf2f.mp4 HTTP/1.1
  Host: www.w3.org
  Fragment: time:npt=12-21
  Accept-Range-Refer: npt

The server that supports 'Range-Refer: time' responds with (200 code):
  HTTP 200 OK
  Content-Length: 1000
  Content-Fragment: time:npt=12-21
  Vary: Fragment, Accept-Range-Refer
  Range-Refer: this npt 12-21, 
http://www.w3.org/2008/WebVideo/Fragments/media/fragf2f.mp4 time 12-21

--> Conrad, could you please write somewhere the syntax for 
'Range-Refer' since all words see important (e.g. 'this')

The UA then uses the body of this response to decode time 12-21, and 
issues an HTTP range request to http://www.w3.org for the referred 
range. Note that this is a normal HTTP/1.1 request using the time range 
units, and need not be to a server supporting Range-Refer:
  GET /2008/WebVideo/Fragments/media/fragf2f.mp4 HTTP/1.1
  Host: www.w3.org
  Range: time:npt=12-21

The server responds with:
  HTTP 206 Partial Content
  Content-Length: 3571437
  Vary: Fragment, Accept-Range-Refer
  Content-Range: time:npt 12-21/36

* Summary:
  . 2.1: 2 round-trips are necessary. Two new headers are introduced in 
the first round-trip ('X-Accept-Range-Redirect' and 'X-Range-Redirect'). 
The second round-trip is a normal bytes Range request with 206 response code
  . 2.2: 2 round-trips are also necessary. The 'Fragment' and 
'Content-Fragment' headers are introduced like for the case 1.2. Two 
more headers are introduced ('Accept-Range-Refer' and 'Range-Refer')
  . In all cases, the body of the 2nd response contains the binary data 
of the fragment

Best regards.

   Raphaël


[1] 
http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#URIfragment-server
[2] 
http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#URIfragment-proxies
[3] http://www.w3.org/2008/WebVideo/Fragments/wiki/HTTP_Range_Refer
[4] 
http://www.w3.org/2008/WebVideo/Fragments/wiki/HTTP_Examples#Fragment_URI_.2B_Range-Refer:_time
[5] 
http://www.w3.org/2008/WebVideo/Fragments/wiki/WG_Resolutions#Media_Fragment_Headers

-- 
Raphaël Troncy
EURECOM, Multimedia Communications Department
2229, route des Crêtes, 06560 Sophia Antipolis, France.
e-mail: raphael.troncy@eurecom.fr & raphael.troncy@gmail.com
Tel: +33 (0)4 - 9300 8242
Fax: +33 (0)4 - 9000 8200
Web: http://www.eurecom.fr/~troncy/

Received on Wednesday, 2 December 2009 09:06:15 UTC