Re: fragment or sub-resources

Hi Raphael, all,

2009/9/8 Raphaël Troncy <Raphael.Troncy@cwi.nl>

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

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.

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

I'd rather go with the first.


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

The extra partial request will tell the UA the duration of the original
file. What else can it tell?

It cannot tell what time the URI query response actually mapped to (e.g. for
a requested ?t=20-40 the response would contain data from t=18.5s) because
that is not information inside the original resource.

If instead we include the Range header into the reply, it can contain both
this information: the full duration of the original file and the actual
retrieved time range, so the user agent can do the right things with it.



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


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.

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.

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

The point about fragments are that they are part of a resource that is
already being handled. Therefore, I really don't see a need to recompose
another valid media resource out of which the UA will anyway throw away the
header.


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


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.



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



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.

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

In the case where we require the "Link" header as a resonse to a URI query
for media fragments, we can also call the retrieved resource a "derived
resource" or a "sub-resource", since we always have the relationship to the
original resource. This is something to be discussed, I guess.


Cheers,
Silvia.