Re: Identifying vs Describing media URI fragments

On Wed, 24 Sep 2008, Silvia Pfeiffer wrote:

>> I think Raphael's point is: should the fragment be self-descriptive enough a
>>  "kiss-scene" are equivalent. In both case, the machine
>>  will not understand what this fragment is about ]] ).
>
>
> If we only identify that it is a fragment of a *video*, but not what
> its semantics are, that comes through the media type of the resource,
> right?

You have to know it beforehand, if you want to use HTTP range request 
using units other than bytes. It really depends on how you plan to 
interact with the server.

>> This is especially critical when you want the machine to retrieve only the
>> fragment and not the whole resource; as opposed to giving a first class
>> identification to fragments (ie: giving them the resource status).
>
> Do you mean that we need to have semantics to identify what segment of
> a video we need to retrieve?

Well, only if you access those fragments using difference resource 
identifiers, fragments are just part of the same resource.

>
> The way I envisage the fragment extraction to work is as follows:
> * a URI references, say 5.3sec - 20.4sec of videoA
> * the server maps 5.3sec-20.4sec to a byte range on videoA on the server
> * the server composes a valid video file (potentially with new headers
> etc) from the videoA fragment
> * the server sends that videoA fragment back to the client and
> notifies it that it is providing a fragment and not the full video
>
> If I have misunderstood you, please explain further.
>
>> In the case of fragments, being able to merge the 0-10s fragment to the 10s-
>> (end) fragment in a local cache is something desirable, but it is difficult
>> to achieve this if fragments are plain resources (unless you have extra
>> informations available somewhere about relations between a potentially
>> infinite set of resources), but I'm digressing...
>
> Caches are a different matter to servers. While servers know for a
> given media type how to map time to byte ranges, a cache may not have
> such information and should only deal with byte ranges. This is
> particularly true for Web proxies.
>
> In that case, we need a special protocol to deal with this situation.
> We had a plan with Ogg resources and temporal hyperlinks, which I can
> explain. It would work within the existing Web proxy specifications,
> but required some extra HTTP message headers
> (http://annodex.net/TR/draft-pfeiffer-temporal-fragments-03.html#anchor8).
> Let's discuss that at some other time. :-)
>
> Cheers,
> Silvia.
>

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

Received on Wednesday, 24 September 2008 11:45:22 UTC