W3C home > Mailing lists > Public > public-media-fragment@w3.org > November 2008

Re: Squid experts

From: Yves Lafon <ylafon@w3.org>
Date: Mon, 3 Nov 2008 05:31:27 -0500 (EST)
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
cc: Media Fragment <public-media-fragment@w3.org>
Message-ID: <Pine.LNX.4.64.0811030318490.9967@ubzre.j3.bet>

On Sat, 1 Nov 2008, Silvia Pfeiffer wrote:

> I had a discussion with a squid expert and wanted to share some of the
> points that were made.
> First, they asked why we didn't have a squid expert in the group,
> since this seems to be such a difficult topic to get right. If
> somebody in the squid community would be interested, would we want
> them to join?


> One technical point that was made is that doing time ranges in proxies
> may be really difficult since time is inherently continuous and so the
> continuation from e.g. second 5 to second 6 may not easily be storable
> in a 2-way handshake in the proxy.

Not for a general proxy, but it makes the case for proxies with a specific 
module to handle such beast. That said, we have different axes of 
selection, and it doesn't fit well the range model.
I was wondering if language selection could be done using Accept-Language, 
in the case you have different language tracks, but in that case you need 
to identify first class URIs for the different language-based variants.

We need to discuss that a bit deeper, do we really need to identify the 
video+fr soundtrack as a fragment?

> Instead there was a suggestion to create a codec-independent media
> resource description format that would be a companion format for media
> resources and could be downloaded by a Web client before asking for
> any media content. With that, the Web client would easily be able to
> construct byte range requests from time range requests and could thus
> fully control the download. This would also mean that Web proxies
> would not require any changes. It's an interesting idea and I would
> want to discuss this in particular with Davy. Can such a format
> represent all of the following structural elements of a media
> resource:
> * time fragments
> * spatial fragments
> * tracks
> * named fragments.

Well, you have byte ranges, but no headers, no metadata. And carrying 
part of the missing payload in headers is a big no.

> Anyway ... some more food for thought!
> Cheers,
> Silvia.

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

Received on Monday, 3 November 2008 10:31:38 UTC

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