W3C home > Mailing lists > Public > public-media-fragment@w3.org > January 2010

Re: Feedback from FOMS

From: Jack Jansen <Jack.Jansen@cwi.nl>
Date: Mon, 25 Jan 2010 19:50:46 +0100
Cc: Media Fragment <public-media-fragment@w3.org>
Message-Id: <66EC4140-66B1-41FD-893F-D2FBF5E86979@cwi.nl>
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>

On 25 jan 2010, at 09:32, Silvia Pfeiffer wrote:

> On Mon, Jan 25, 2010 at 7:24 PM, Jack Jansen <Jack.Jansen@cwi.nl> wrote:
>> On 25 jan 2010, at 05:04, Silvia Pfeiffer wrote:
>>> The current version 1 should be focused on only client-side temporal
>>> url addressing with URI fragments and should be published soon, since
>>> it's simple to implement.
>>> In version 1.1 we could further sort through other temporal
>>> fragmentation URI approaches.
>> While I agree with the idea that we should publish early, if possible, even if this means we've got to push some functionality off to a 1.1 document, I don't really see how doing only temporal fragments would save us much effort. As I see it, all the complexity we face is in reconstructing temporal streams, especially in the face of caching. All the other fragments (well, at least spatial and track fragments) require recoding, so they aren't cacheable anyway.
>> What might be a way to a quick 1.0 is to drop caching. But I'm not convinced that that is a good idea: it may lead to a situation where everyone implements 1.0, no-one implements the new caching support of 1.1, and we (the MF WG) get blamed for the performance issues for years to come...
> Hm? UA supported media URI fragments (#) are cachable, since they only
> use byte range requests. This works now for both, MPEG and Ogg. For
> URI fragments (#), this is optimal and the other functionalities were
> only invented to offer other solutions for such formats that cannot do
> the time->byte-range mapping directly from the file header (of which
> there are a few, but none is relevant to HTML5). So, I don't think we
> will get ourselves into too much trouble.

As usual, you are right:-)
>>> Further, the suggestion is to describe temporal URI fragments (#t=a,b)
>>> to simply mean "focus attention" and thus to also provide a recommend
>>> implementation. The implementation should be such that the full video
>>> timeline is displayed, but only the given fragment played back, then
>>> paused. A "reload" button will replay this fragment - pressing "play"
>>> will continue playback at the play position.
>> Isn't this exactly what we call in-context (versus out-of-context )?
> Indeed, but until now we haven't really decided what would be the
> recommended display for URI fragments (#) for display. The discussion
> with the browser vendors (Firefox and a little bit of Opera) seemed to
> indicate (and possibly confirm) that in-context for URI fragments (#)
> was the right thing to do and URI queries (?) relate better to
> out-of-context.

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
Received on Monday, 25 January 2010 18:51:28 UTC

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