Re: Squid experts

On 6 nov 2008, at 11:20, Yves Lafon 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).
>
> 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.
>
> 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.

Ok. You're making two extra assumptions (at least, they seem to be  
implied in this message):
1. The original media server will modify the time range parameter to  
match the actual data returned.
2. Time is a half-open interval, i.e. from 1s to 2s means [1s..2s).  
Or, in normal english, the frame for 1s is included, the frame for 2s  
is excluded.

I think this could work.

But we're still left with another issue: that of the initial data (the  
header). To be able to forestall the extra trip to the original media  
server, this data would have to be cached too. This requires that this  
data is completely independent of whatever time range is requested. Is  
this true, for the formats we know?



--
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 Thursday, 6 November 2008 11:16:28 UTC