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

Re: Feedback from FOMS

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Mon, 25 Jan 2010 19:32:17 +1100
Message-ID: <2c0e02831001250032k131d89fdq36349d0927b62345@mail.gmail.com>
To: Jack Jansen <Jack.Jansen@cwi.nl>
Cc: Media Fragment <public-media-fragment@w3.org>
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.

>> 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

Received on Monday, 25 January 2010 08:33:09 UTC

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