W3C home > Mailing lists > Public > public-media-fragment@w3.org > September 2009

Re: updated server-parsed fragment wiki page

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Wed, 23 Sep 2009 19:46:12 +1000
Message-ID: <2c0e02830909230246hf2feb2fred91ecd557fe9ec2@mail.gmail.com>
To: Conrad Parker <conrad@metadecks.org>
Cc: Media Fragment <public-media-fragment@w3.org>
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?

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

Received on Wednesday, 23 September 2009 09:53:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:27:44 UTC