Re: updated server-parsed fragment wiki page

2009/9/23 Silvia Pfeiffer <silviapfeiffer1@gmail.com>:
> On Sat, Sep 19, 2009 at 4:58 PM, Conrad Parker <conrad@metadecks.org> wrote:
>> 2009/9/19 Silvia Pfeiffer <silviapfeiffer1@gmail.com>:
>>> On Fri, Sep 18, 2009 at 7:37 PM, Conrad Parker <conrad@metadecks.org> wrote:
>>>> Hi,
>>>>
>>>> yesterday we were discussing about which HTTP request header to use to
>>>> request a specific track etc. I think we agreed that Range should only
>>>> be used for continuous indexes (that can have a duration/length/size),
>>>> such as time or xywh.
>>>
>>> I don't think the outcome of the discussion was conclusive, but we did
>>> indeed mention this as another option.
>>>
>>>> I'm suggesting to use something like Fragment for things like track=,
>>>> id=. I've updated this wiki page to include a line about how Fragment
>>>> should interact with time Range requests, and a link to relevant
>>>> examples:
>>>>
>>>> http://www.w3.org/2008/WebVideo/Fragments/wiki/Server-parsed_Fragments
>>>
>>> After having read all that, I am wondering why we would need to invent
>>> a "Fragment" protocol parameter that does essentially the same as the
>>> "Range" protocol parameter? Is there a reason "Range" doesn't work for
>>> "track"? What is different between "Range:" and "Fragment:" other than
>>> leaving out the <total duration> part on the "Fragment:"?
>>>
>>> I sympathise with the idea, but I cannot justify it without having
>>> these questions answered.
>>
>> Ranges and tracks are orthogonal concepts. A track gives you some kind
>> of semantic view across the whole file. A range is a way of addressing
>> the whole file, or of addressing a track view.
>>
>> In terms of caching, you may be able to store and recombine ranges
>> from the same view. For this reason Fragment is declared in the Vary
>> header; this allows ranges of a track to be cached, even by an
>> intermediary that does not understand what the track is all about (ie.
>> just using generic Range mechanisms). This would not be possible if
>> both track and range were supplied in the same header.
>>
>> Specifically, it ensures that our track etc. selection schemes do not
>> interfere with existing HTTP/1.1 caches that do byte range handling.
>> The same may apply to future intermediaries that support time range
>> caching.
>
> So, if a current cache receives a range request that includes both,
> byte ranges and a track request, it will not be able to resolve that?

Right, so a current current proxy that sees:

    Content-Range: bytes 1234-5678/9999
    Content-Range: track audio/*

just going to forget about range recombining. Whereas one that sees:

    Content-Range: bytes 1234-5678/9999
    Fragment: track=audio
    Vary: Fragment

is going to be able to do correct byte-range caching for the track.

> What happens in the case of byte ranges and time ranges?

For time ranges there is no opportunity to try to make things work
with existing installations, so it is less of an issue which way it
is implemented.

Nevertheless, I think the expected behaviour is clearer if it is simply
spelled out:

    Content-Range: time:npt 00:10-00:20/00:30
    Fragment: track=audio
    Vary: Fragment

ie. the track handling is already taken care of by the Vary header.

This way the only additions we impose on a proxy are for time range
handling, where a proxy may be able to recombine or take subranges of
existing cached responses.

Conrad.

Received on Wednesday, 23 September 2009 10:09:43 UTC