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

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

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

Two things, first we need in that case a CL like
Content-Location: http://www.w3.org/2008/WebVideo/Fragments/media/fragf2f.mp4?t=12-21

Also if you first do this request:
GET /2008/WebVideo/Fragments/media/fragf2f.mp4 HTTP/1.1
Host: www.w3.org
Accept: video/*

and get back
HTTP 200 OK
Content-Length: 121994833

A cache will... cache it. Then if there is a subsequent request like this:

GET /2008/WebVideo/Fragments/media/fragf2f.mp4 HTTP/1.1
Host: www.w3.org
Accept: video/*
Fragment: time:npt=12-21

The cache will serve the cached version, so the complete one, ignoring 
Fragment. So 1/ you need to send Vary:Fragment in all cases to avoid that
and also every time someone will request a different range, the cache 
entry will be trashed, so the chances that a cached fragment will be 
reused and served from the cache is pretty low.

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

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

         ~~Yves

Received on Wednesday, 2 December 2009 10:30:33 UTC