W3C home > Mailing lists > Public > public-media-fragment@w3.org > April 2009

Re: Discovery and fallback for media segment addressing over HTTP

From: Conrad Parker <conrad@metadecks.org>
Date: Wed, 8 Apr 2009 08:17:31 +0900
Message-ID: <dba6c0830904071617y6754362dk42a8aa150f8d4cf0@mail.gmail.com>
To: RaphaŽl Troncy <Raphael.Troncy@cwi.nl>
Cc: Media Fragment <public-media-fragment@w3.org>
2009/4/8 RaphaŽl Troncy <Raphael.Troncy@cwi.nl>:
> Dear Conrad,
>
>>> The main criticism you have for the fragment, is the lack of a fallback
>>> plan
>>> if the server does not handle the fragment request. In other words, the
>>> whole resource will be send over the networks. Yes, but I don't see that
>>> as
>>> a major drawback, and we can be confident that the situation will
>>> naturally
>>> improve as soon as more and more web servers will handle media fragments.
>>
>> Also the lack of fallback if clients don't support these steps. I
>> think there is a good use case for user agents not supporting extra
>> steps (eg. a mobile browser with no on-board cache) but there being an
>> intermediate proxy at the ISP which does that translation and caching.
>
> I would now revert back your argument :-)
> * With the current approach, the UA just needs to encode the fragment into a
> suitable range request in the HTTP method. Something that can be reasonably
> achieve by a add-on in a web browser for example, and can be reasonably
> expected to be the default in the future web browsers. Nothing more is
> needed, and in particular the ability for the UA to be able to do any sort
> of recomposition of bytes and extra header to finally get a playable
> resource. As Yves pointed out, the caching is not necessarily something
> useful to have.

There are three issues here:

1. Addressing syntax: query or fragment?
2. Negotiation mechanism: is a more cacheable method available?
3. Response mechanism: just one HTTP response, or multiple byte-range referrals?

You are referring to the addressing syntax, where a fragment is
interpreted and used to construct an initial HTTP request header.

The recomposition steps which I described in the other post (about
byte-range referral) are a way for the UA to handle the subsequent
response.

As for the motivation, I'll assert that caching is extremely important
for use cases like seeking in video resources.

> * With your proposed approach, the UA does much more processing so there is
> a risk to falls more often in the fallback plan.

The steps you compare are not attempting to do the same thing.

For example, if you wanted to both use #fragment syntax, and improve
cacheability, then you could transform the #fragment into an HTTP
request header, then do the negotiation and response handling that I'm
suggesting.

Conrad.
Received on Tuesday, 7 April 2009 23:18:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 21 September 2011 12:13:32 GMT