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

On Wed, 2 Dec 2009, Raphaël Troncy wrote:

> 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'?

We should reuse the exact same unit, in that case 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

Issue is that you get multiple value for the same URI (which is OK), but 
with no way to differentiate between them. There should be at least a 
Content-Location with the explicit URI of this fragment as a complete 
reource representation.

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

time ranges _are_ cacheable !

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

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

         ~~Yves

Received on Wednesday, 2 December 2009 09:45:59 UTC