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

Re: Squid experts

From: Jack Jansen <Jack.Jansen@cwi.nl>
Date: Mon, 3 Nov 2008 13:51:07 +0100
Cc: "Yves Lafon" <ylafon@w3.org>, "Media Fragment" <public-media-fragment@w3.org>
Message-Id: <97C90270-8954-4F40-B8F3-2E82097C9688@cwi.nl>
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>


On 3 nov 2008, at 12:04, Silvia Pfeiffer wrote:

>
> Hi Yves,
>
> On Mon, Nov 3, 2008 at 9:31 PM, Yves Lafon <ylafon@w3.org> wrote:
>> On Sat, 1 Nov 2008, Silvia Pfeiffer wrote:
>>> 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.
>
> The issue is that for any codec it will be a problem to identify where
> "second 5" ends and where "second 6" starts. Even a proxy that
> understands time and codecs cannot be certain that when it receives a
> packet that goes till second 5 and one that starts at second 6 it can
> just concatenate them to make a continuous stream. Such concatenation
> only works on the byte level. It therefore needs to be told not just
> the time range, but also the byte range that the data maps to.

And things get even uglier if we allow multiple time schemes: now the  
proxy would have to understand that "npt=2.5" is identical to  
"smpte=00:00:02:15", and that it is half-way between  
"smpte-25=00:00:02:12" and "smpte-25=00:00:02:13".

If we can have the proxies only know about byte range, and leave time  
to the entities that need to understand about it anyway (the client  
and the server) that would make life simpler.


--
Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman
Received on Monday, 3 November 2008 12:52:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 21 September 2011 12:13:31 GMT