Re: Squid experts

On Thu, 6 Nov 2008, Jack Jansen wrote:

>> 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.

It MUST return the _actual_ range returned, be it 4.95833333 to 10. 
Otherwise it's like asking for byte range 12-42 and returning 10-50 
without even saying so. In the case of bytes it's easy to return the 
_exact_ range, in video, it is more difficult (or impossible, unless 
aligned to frames).

> 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?

Well, the server should reply with a playable video, including the video 
headers, when merging, I expect the cache to strip those headers before 
assembling. The trick of serving the header in a separate exchange looks 
more like a (needed) hack.

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

Received on Thursday, 6 November 2008 13:30:52 UTC