- 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>
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?
Sure!
> 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.
~~Yves
Received on Monday, 3 November 2008 10:31:38 UTC