Re: Use cases and requirements for Media Fragments: Chapter 8

2009/4/8 Raphaël Troncy <Raphael.Troncy@cwi.nl>:
> Dear Conrad,
>
>>> On the other hand, it seems to me that your proposal aims at solving the
>>> problem of answering a complex request with multiple by ranges, while I
>>> do
>>> not understand what the UA needs to do with the set of bytes it will
>>> receive
>>> to have a playable resource.
>>> Therefore, could you explain me what the 'Range-Referral' new header is
>>> meant to do?
>>
>> The user agent should concatenate the byte ranges to which it is
>> referred. The semantics are that the resulting stream is equivalent to
>> the stream that would otherwise be constructed for the segment
>> (bytewise-identical, at least for the implementation I have in mind).
>
> hum, so you assume that my fragment request will result into a number of
> multiple discontinuous sets of bytes in the original file? Why then would
> you like the client doing the concatenation and additional operation to get
> a playable resource? Why the server could not do that? It seems to me that
> you put the burden on the client.

The server is capable of doing that; if the client does not want to go
through a more complex retrieval then it just does a normal HTTP
request and the server gives it a single response body for the
requested segment.

The advantage of doing multiple byte-range requests against a
canonical URL is that more byte ranges of that file can be shared in
caches. Only the parts which are different are given in the body of
the first response (referred to as byte-ranges against "this").

>> Perhaps "byte-range referral" is an accurate description of what's going
>> on?
>
> I will make an informal poll on the call :-)

:-)

Conrad.

Received on Tuesday, 7 April 2009 21:58:15 UTC