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

Re: Squid experts

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Fri, 7 Nov 2008 09:30:36 +1100
Message-ID: <2c0e02830811061430x1ed78eafs42dda7b6e21246b3@mail.gmail.com>
To: "Yves Lafon" <ylafon@w3.org>
Cc: "Media Fragment" <public-media-fragment@w3.org>

On Fri, Nov 7, 2008 at 12:44 AM, Yves Lafon <ylafon@w3.org> wrote:
> On Thu, 6 Nov 2008, Silvia Pfeiffer wrote:
>> On Thu, Nov 6, 2008 at 9:20 PM, Yves Lafon <ylafon@w3.org> wrote:
>>> On Thu, 6 Nov 2008, Silvia Pfeiffer wrote:
>>> That is the thing I don't understand, why is it mandatory to have the
>>> mapping to bytes? You request fragment 1-6s, you get a fully playable
>>> video
>>> with this time range (and it may be 0.5s 6.5s). Now you get fragment 6 to
>>> 10s, you get once again a fully playable video with this new time range
>>> (once again it may even overlap to 5.5 -> 10.5s).
>> OK, so are you saying that because it overlaps, we can identify the
>> bytes that are identical and thus align the ranges? Isn't that asking
>> a bit much of the proxy? What if it gets it wrong and identifies the
>> overlap at the wrong byte?
> Well, if it is a proxy/cache specialized in video content, it's definitely
> not asking for too much; and if the proxy can't do the merge, it's quite
> likely that a client won't be able to do it as well.

The client doesn't have to - it just decodes a perfectly valid media resource.

>> What I'm trying to say is that time is not sufficient. You need to
>> identify the exact byte number of the original media resource to say
>> with absolute authority where you are up to.
> byte number? frame number? decimal seconds?

Byte number will work. Frame number is track-specific, so will only
work if we know which track it refers to.
Decimal seconds are inherently inaccurate for being an approximation
to the real time (and most of the time are rounded).
Even in your example to Jack "It MUST return the _actual_ range
returned, be it 4.95833333 to 10." - 4.95833333 is probably an
approximation for an infinite number of decimals. Time is just simply
always inaccurate.

Received on Thursday, 6 November 2008 22:31:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:41 UTC