Re: Squid experts

On  5-Nov-2008, at 23:32 , Silvia Pfeiffer wrote:

> I am not sure how this works with RTSP. However, we cannot do
> transcoding on the fly for media resources on HTTP. Transcoded
> resources are not bit-wise identical to the original media resource
> and can therefore not be cached in Web proxies. Then the media
> resource becomes identical to an output of a script that is different
> each time and therefore not a cachable resource. So, I'd prefer it if
> we could accept those two conditions.

and

> Even if the cache understands codecs, how can it deal with several
> fragments that each have been recoded to meet the fragment needs? I
> cannot easily serve them by concatenation. It would need to do another
> recoding - and this time not from one file, but from multiple recoded
> fragments. Do you really think that is possible? And without loss of
> quality??

These are exactly my misgivings (but phrased better:-).

I've also thought a bit more about the general issue of using time  
ranges for caching, and specifically Yves' comment about keeping also  
time ranges in the cache would forestall the extra request/response to  
the original media server.

First of all, I'm not sure that it's true that this is the case. The  
first handshake would not only return the byte ranges for the  
fragment, but also the initial headers and other such data that is  
always needed. I'm not convinced that the cache server could provide  
this data. Or could it?

Second, (much weaker point): in case of continuous media, the one  
extra interaction with the original server isn't as bad as it is for  
static media. Because the files are much larger, the extra  
communication (in percentage of total communication) isn't as bad.


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