Re: ACTION-112 follow-up: Conrad's vs current's proposal for Media Fragment Processing

Dear Conrad,

Thanks a lot for the detailed answer. I hope you, Silvia, Yves and all 
other WG participants will be able to make the call tomorrow to continue 
this discussion since I'm feeling we are closed to be in a position for 
reaching a consensus.
Some comments:

> So the mechanism you are referring to is the use of HTTP/1.1
> byte-ranges, in order to take advantage of HTTP/1.1 byte-range
> caching.
> By "hack" you mean that you consider it a temporary workaround.

Yes. And 'workaround' is a much better term than 'hack' for what I 
wanted to express.

> Most caches can remember a particular byte range that was already
> seen, and serve it again, or serve out part of one previously seen
> byte range. That is already useful to us, as it allows media fragment
> data to be cached from the outset. By using existing byte-range
> caching mechanisms we are also using the same data that is retrieved
> by standard video players that use progressive download and byte-range
> requests for seeking. Normal video playback and scrubbing populates
> the same caches (keyed against the same URLs) as accessing our media
> fragment schemes, if they use byte-ranges for the main data transfer.
> 
> To be most useful to us, caches should also do byte-range recombining,
> which involves using multiple cached byte-ranges to serve a request
> that spans them. This is in development (eg. in squid) and will take a
> few more years to be fully available across the internet. One of the
> most useful reasons for deploying this caching feature is video.
> 
> I don't consider using byte-ranges for the main data transfer to be a "hack".

I agree. What I wanted to say is that HTTP/1.1 byte-range caching will 
still remain a great way for data transfer and that will be complemented 
by e.g. a HTTP/1.1 npt-range caching mechnism.

> The advantage of keeping things like the HTTP request representation
> of "track=audio" out of Range is that you can keep Range available for
> its current/intended purpose of transporting ranges of data.

But one could argue that a particular track is a set of continuous bytes 
from a media container format and therefore corresponds to ranges of 
data. Perhaps it is a far-stretch definition of 'ranges' I concede.

> The mechanism I proposed (a separate Fragment request/Content-Fragment
> response header pair) would work and is cacheable on the current web.
> 
> The mechanism in the current spec is not cacheable at all until the
> entire web changes to support an as-yet-undefined caching mechanism.

I disagree. The mechanism described in the current spec as the 4-ways 
handshake (aka 2 roundtrips) that also introduce 2 new headers 
(Range-Redirect and Accept-Range-Redirect) have exactly the same 
properties than your mechanism and can be cached since in the second 
roundtrip, the request for a track is converted into a byte-range request.

> Basically I'm viewing things like "track=audio" the same way that
> Language representations are handled. It works and it doesn't
> interfere with caching.

I like this argument.
Cheers.

   Raphaël

-- 
Raphaël Troncy
EURECOM, Multimedia Communications Department
2229, route des Crêtes, 06560 Sophia Antipolis, France.
e-mail: raphael.troncy@eurecom.fr & raphael.troncy@gmail.com
Tel: +33 (0)4 - 9300 8242
Fax: +33 (0)4 - 9000 8200
Web: http://www.eurecom.fr/~troncy/

Received on Tuesday, 8 December 2009 06:55:31 UTC