Re: fragment or sub-resources

Dear Silvia, all,

Thanks for this pretty exhaustive email. I think I agree with most of 
its content :-)

> Let me start with some nitpicking.

+1 in general to stick with the standardized terminology :-)
[snip]

> <uritemplates>
> In the query case, if we recommend the use of URI templates to servers 
> that offer media fragment addressing with queries, then they could 
> extend the scheme to e.g. providing lower bandwidth versions, or lower 
> framerate versions or some other transcoded representation of the 
> original media resource.
> 
> How do you think a server could advertise its URI query capabilities for 
> media fragments? Would it be a specific http protocol exchange through 
> which a client can ask a server for its capabilities?
> 
> Is the template substitution process that would be necessary to be 
> undertaken by clients a overhead that is worth it?
> 
> Further: how would a client (Web browser) inform the user that a 
> particular server provides further addressing capabilities than other 
> Web servers and make these available to the user?

Thanks, these are the questions I actually meant to ask to Yves in my 
previous email but you have better formulated them :-)

> <querypresentation>
> I guess the only question that is still on my mind wrt media fragment 
> addressing using URI queries is the question of presentation.
> 
> In theory, a media fragment specified through a URI query is its own new 
> resource. Therefore, it would be presented as a complete resource and 
> not as a "secondary resource" as part of another primary resource. This, 
> in the case of temporal URI queries, leads to e.g. the presentation of 
> time offset 19 as the beginning of the resource.

In the case of query, I think we cannot talk anymore about a Range 
Request. This is a normal request, for a resource that is built from 
another resource. We can additionally inform the UA that this resource 
which is served is 'derived' (I'm not sure this is the correct term) 
from another resource and give the link to this other resource using the 
'Link:' header.

In my view, the UA can then present the file it has received as a plain 
new resource (i.e. present a time offset of 19s as the beginning of the 
resource) *and/or* optionally use the value of the Link header to make 
another (partial?) request to the server in order to, e.g., receive the 
duration of the full media from which the new resource currently 
presented has been derived and adapt its presentation. Does it make 
sense or do you think this 'extra' request in order to get the full 
duration of the 'parent' media could/should be further optimized?

> So, in summary (and some further understandings), I suggest the following:
> 
> * using the single-step partial get approach for fragment-based media 
> fragmet URIs WITHOUT the requirement to "add new container headers in 
> order to serve a playable resource".

That, I don't get. If the UA just receives the bytes corresponding to 
the portion of the media, how do you expect it can actually decodes it 
and plays it?

> * in the query case, there is no need to add a Range header for seconds, 
> but it would be nice nevertheless to receive the content-range header 
> with the actual delivered ranges as in the single-step partial get 
> approach. This time WITH the requirement to "add new content headers in 
> order to serve a playable resource".

If this is not a Range request, then there will be no Content-Range 
header in the response. For me, in the query case, this is not a Range 
request.

> * using the "Link:" header for query-based media fragment URIs to 
> optionally allow to specify the original dimensions of the video; this 
> needs to be accompanied by a UA request parameter to add the "Link:" header.

I'm not sure I understand what do you mean by "this needs to be 
accompanied by a UA request parameter to add the "Link:" header"? Why 
the server would not always answer a media fragment URI request in the 
case of the query with this link header information? Why would you like 
to mandate that the UA tells the server I want this Link information?

> * using the dual-step partial get approach is an optimisation to the 
> media fragment URIs where we want to enable existing Web proxies to 
> store the retrieved byte ranges. This applies actually to both, the 
> fragment-based and the query-based URIs.

+1.
Cheers.

   Raphaël

-- 
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.cwi.nl/~troncy/

Received on Monday, 7 September 2009 19:36:46 UTC