W3C home > Mailing lists > Public > public-media-fragment@w3.org > November 2008

Re: Squid experts

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Thu, 6 Nov 2008 11:51:10 +1100
Message-ID: <2c0e02830811051651o340ee837hab9d8eebab519cae@mail.gmail.com>
To: "Jack Jansen" <Jack.Jansen@cwi.nl>
Cc: "Media Fragment" <public-media-fragment@w3.org>

On Thu, Nov 6, 2008 at 10:14 AM, Jack Jansen <Jack.Jansen@cwi.nl> wrote:
> 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.

And in fact if we provide some payload data in the first handshake, if
would not be a lost round.

Received on Thursday, 6 November 2008 00:51:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:41 UTC