RE: Squid experts

Hi Jack, all,

 

From: public-media-fragment-request@w3.org
[mailto:public-media-fragment-request@w3.org] On Behalf Of Jack Jansen
Sent: Tuesday, November 04, 2008 11:34 AM
To: Davy Van Deursen
Cc: 'Media Fragment'
Subject: 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. 

 

What do you mean by 'a lot of extra implementation work'? Are you referring
to the different time schemes that should be supported [1] or also other
things? I agree that there will be extra implementation work in case of
these time ranges, but I wonder what is worse for the performance of a
cache: no support for coalescing fragments or no support for a list of media
formats?

 

[1]
http://lists.w3.org/Archives/Public/public-media-fragment/2008Nov/0014.html

 

Best regards,

 

Davy