- From: Jack Jansen <Jack.Jansen@cwi.nl>
- Date: Mon, 25 Jan 2010 09:24:04 +0100
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Cc: Media Fragment <public-media-fragment@w3.org>
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... > > 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 )? -- 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 08:24:53 UTC