Re: fragment or sub-resources

Hi Silvia,

>     <querypresentation>
>     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.
> 
> 
> If we do not include information about which time range has actually 
> been extracted into the HTTP response, then - for those media container 
> formats that do not support non-zero start times - the user agent has no 
> means of identifying which time range it received as a reply to its 
> request and it cannot skip over, e.g. the first 1.5s.

Why would you like the user agent to skip this 1.5s?

One way to interpret a media fragment URI request using the query 
parameter is that the UA request a new resource, that is built/derived 
from an existing resource, which for example is the *closest match* to 
the range 20s-30s. The response is a playable resource, which might 
actually  correspond to the interval 18.5s-31s from the other resource, 
but why would you like to tell the UA to skip the first 1.5s? Getting 
these extra frames is part of the game for extracting a temporal 
sequence and recomposing a new playable resource.

Question for Conrad/You:
The annodex server currently handles URI request such as 
http://example.com/video.ogv?t=npt:12.3/21.16. Do you inform the UA 
which time ranges you actually serve to perform a seek?

> One way to deal with this is to actually include the Range reply header 
> into the response to the URI query, which is what I suggested.

Yes, in case we want the UA to perform a seek which I think should not 
be mandatory.

> Another way of dealing with this is to say "tough luck - you chose the 
> wrong container and cannot get accurate fragments".

We are talking about a few frames which will anyway be needed for the 
decoder to perform its task. From the user point of view, it is 
completely negligible. Which use case do you have in mind that would 
require 'accurate fragments', at the frame precision?

> I'd rather go with the first.

And mandate it? I would rather not ...

> The UA, e.g. in the case of a Web browser, has already set itself up for 
> decoding of the whole file. In the resource selection algorithm 
> specified in HTML5, this includes downloading of the header of the file 
> and setting up the decode pipeline. Thus, the UA doesn't actually need 
> those headers any more.

Yes, I think I start to realize that in the light of your blog post 
though I'm not sure I fully understand the mechanism :-( Technically, 
does it mean that a web browser which is HTML5 compliant knows how to 
setup this decode pipeline? Does it mean that the web browser has made 
before a request to the server in order to get the information about the 
media? Does that happen _before_ the media fragment URI request?
Is this mechanism valid only with HTML5 compliant UA? Do we want to not 
be bound to this dependency?

> I think this is a crucial understanding that I recently came to. While 
> developing the demonstrator, I thought about this and that the Web 
> browser is only retrieving byte ranges, but not headers. Then I thought 
> that it would be the same for fragments. After all, the resource itself 
> does not change, but only the part of it that is displayed. Therefore, 
> we really do not need to compose a valid resource, but only retrieve the 
> required bytes.

OK, but that would work only for HTMl5 compliant UA, right? Do we want 
to introduce this dependency?

> In the unlikely event that a UA doesn't have the decode pipeline set up 
> and hasn't retrieved the headers, it can easily just compose a brief 
> byte range request to retrieve the beginning of the file and its headers 
> (at least that works for Ogg).

I cannot judge the 'unlikely event' ... it might happen more often that 
what we think, look at all the people who runs a IE6 version :-(
The 'just compose a brief byte range request' would need to be 
documented in the specification in order to provide guidance to the 
developers.

> It doesn't have to be called a Content-Range header in the response. 
> Maybe we can find a different header name. It just has to have that same 
> information.

So you want to invent a new 'header' name with exactly the same purpose 
of the Content-Range? Hum, I'm not sure Yves will like that ;-)

> The point I was trying to make is that there are two use cases for 
> query: one where you really don't care what original resource the media 
> file relates to and one where you do and want to have the "Link" header.

Well, if the UA does not care, he can just ignore this header ... This 
is not because the information is present that the UA must use it. When 
a UA receives a response, there is already information that it does not 
necessarily care.

> I suppose we can mandate to always have the server create the "Link" 
> header. Then it is up to the UA to decide to use it or not.

Exactly.

> I just came 
> from the background that when we don't need a header, then we should not 
> add it, which is why I proposed that the UA could ask for it. But I 
> agree that it would not be necessary if we always add the link header.

Yes, but the cons of your approach is that now, the burden is on the UA 
who cares about the Link information to explicitly request it ... which 
I think adds some extra-complexity.
Thanks for this enlightning discussion :-)

   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 Tuesday, 8 September 2009 10:29:55 UTC