Re: Squid experts

On Thu, Nov 6, 2008 at 9:20 PM, Yves Lafon <ylafon@w3.org> wrote:
> On Thu, 6 Nov 2008, Silvia Pfeiffer wrote:
>
>> So where 5s ends is a question about making intervals inclusive or
>> exclusive. Let's go with your understanding. The problem still exists.
>> Let me try and explain. Also note that we are talking about Web
>> proxies that do not have the full media resource at hand, while a Web
>> server that has the full media resource at hand has no such issues.
>>
>> So let's assume two temporal fragment URIS. One asks for seconds 1-6
>> and the next one asks for 6-12. The Web proxy is only give a
>> colleciton of bytes and told which time segment these map to. It does
>> not know which byte offset in the original file the map to. Now, we
>> cannot be sure that the end of 1-6 is exactly before the beginning of
>> 6-12. There may well be an overlap of bytes in between ending 1-6 and
>> beginning 6-12, because we deal with the compressed domain and
>> continuous time. In fact, I would be surprised if there is not an
>> overlap in bytes by at least one codec packet. This tells us that only
>> the bytes are uniquely identified, while time is not uniquely
>> identifyable. This means we have to store not just time in the Web
>> proxy, but also the mapping to bytes. With the 2-way handshake, I do
>> not think this is possible (but please correct me if I'm wrong).
>
> 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?

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.


> Of course a blind proxy won't be able to do anything with it, but that's not
> the point. It should know that it's a video, how to navigate from frame to
> frame, align and merge, then recreate a container around the compressed
> content (as well as being able to act as a first class server when a client
> request a time range between the cached time range). No byte offset involved
> there.

I think the aligning bit is asking a bit much, in particular if we
expect the proxies to do this for any type of media format. However,
this is where I think we should write it down in detail and ask the
squid guys. :-)


> Now if you want to have, on top of time ranges, the possibility of using
> byte ranges as well, then ok, you need to pass the information along, but it
> means you are starting to mix apples and oranges.

No, I don't think so. Bytes are always authoritative. Time or spatial
region is just an "annotation", a "label" on a byte or byte range. In
fact, when you read the SMPTE time specification (and
http://en.wikipedia.org/wiki/SMPTE_time_code is making a pretty good
point of it) it actually mentions that Time Codes are just labels and
may not be 100% accurate (well, in the analog days for different
reasons to the digital days). I think you can only calculate with the
apples (bytes) and not with the oranges (time). However, if we always
provide the bytes with the time regions, we should be safe.

I hope I'm being clearer now.

Cheers,
Silvia.

Received on Thursday, 6 November 2008 11:36:59 UTC