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

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

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Mon, 14 Dec 2009 14:15:08 +1100
Message-ID: <2c0e02830912131915u75c86570jd600bd00ea9818a8@mail.gmail.com>
To: Yves Lafon <ylafon@w3.org>
Cc: RaphaŽl Troncy <Raphael.Troncy@cwi.nl>, Media Fragment <public-media-fragment@w3.org>
Hi all,

I've gone through this thread and included what I learnt into the
current spec. Am about to send a final email with the changes I have
made, but want to reply to this thread now.

2009/12/3 Yves Lafon <ylafon@w3.org>:
> On Wed, 2 Dec 2009, RaphaŽl Troncy wrote:
>
>> 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
>
> First: s/X-//.

Dropped the "X-" from the currently new proposed headers.

> Also your reply is a 200 but what is sent back (the empty body Raphael
> refers to)? What would a UA or a cache do with that?
>
> It might be better to send back a 307, redirecting to itself, but I am
> wondering what a cache would do if there is already something cached (in
> bytes, as if it's cached in the time range, it can serve it directly).
>
> Another way would be to do conneg with a mime type
> application/time-range-resolver and send back the info in the body with a
> Vary: accept (but would it trash an already cached entry in the cache?)

I'm using 307 for now with a redirect to self. It's not a content
negotiation in itself that we're doing, so conneg didn't seem to apply
- (though it's an interesting idea to provide media fragment resolvers
that are not the server itself).




>> --> 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?
>
> Well, in that case the request is in bytes only. However we miss the
> information about the real time range it identifies, most probably not
> exactly the requested "time:npt=12-21", so we need to convey that
> information back in the first reply.

I've added an extra Content-Range header for that - need to discuss in
the next meeting if that is too much information overload on one
header.


Cheers,
Silvia.
Received on Monday, 14 December 2009 03:16:08 GMT

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