Re: Squid experts

On  3-Nov-2008, at 15:00 , Davy Van Deursen wrote:

>> Davy,
>> I would think that any format that can be streamed over RTSP must  
>> meet
>> these 2 requirements: otherwise the RTSP server would have to do
>> recoding on the fly when the user agent does a seek.
>
> I do not agree that these two points are requirements to stream media
> fragments over RTSP in general. On server side, syntax element  
> modifications
> can be performed on the fly. Also, if a server has some transcoders  
> at its
> disposal, on the fly transcoding of the media fragments is also  
> possible, or
> not? As long as you stay on the server side, all possible operations  
> can be
> performed to obtain the requested fragments. However, when proxies  
> need to
> be taken into account (and we do not want to modify them), you  
> should be
> able to express these server-side adaptation operations in terms of  
> byte
> ranges. In order to express an adaptation operation in terms of byte  
> ranges,
> the two above described requirements are necessary.

Ok. I have never come across an RTSP server yet that did this, but  
obviously there's nothing in RTSP that forestalls this. And as we're  
in your field of expertise here I gladly concur:-)
>
>
>>
>> If we limit support for temporal fragments to media that meet
>> requirements (1) and (2), and if RTSP has the same requirements, it
>> seems that it isn't really limiting our support. Moreover, if the
>> server does support fragments on media items that need to be recoded
>> it is in the position to forestall caching by sending out rttp reply
>> headers to that effect, or not?
>
> Do you mean that in the case of recoding, we do not cache the  
> fragment at
> all? Of course, if we do not make any changes on the caches, then we  
> are
> stuck to these byte ranges and is indeed the caching of a recoded  
> fragment
> impossible. However, it would be nice if the cache really  
> understands the
> concept of a fragment and does not (only) rely on byte ranges to  
> cache the
> fragment. But that, I think, will not be an easy task :-).

Here I'm not sure. I think we could do the caching in only one of two  
ways:

1. Cache byte ranges. This means that overlapping fragments or  
adjacent fragments will get merged. This works well for formats that  
match the two constraints (compressed extraction and no modification).  
It would break for formats where modification is required, unless we  
can turn caching off.

2. Cache time ranges. This would also allow caching of exact matches  
for formats that need to be modified during serving. However, we would  
lose the ability to coalesce fragments, unless the cache understands  
the underlying media format.

It seems to me that (2) not only is a lot of extra implementation work  
for the cache, but there's also the risk that we lose a lot caching  
performance because not everything cacheable under (1) is cacheable  
under (2), unless each cache server understands every media format.


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