- From: Jack Jansen <Jack.Jansen@cwi.nl>
- Date: Wed, 26 Nov 2008 09:23:55 +0100
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Cc: "Media Fragment" <public-media-fragment@w3.org>
On 26 nov 2008, at 01:27, Silvia Pfeiffer wrote: > > On Wed, Nov 26, 2008 at 9:37 AM, Jack Jansen <Jack.Jansen@cwi.nl> > wrote: >> I have pondered my action item about combining SMIL clipBegin and >> clipEnd >> with media fragments, and my conclusion is that the only reasonable >> course >> of action is that double clipping occurs. In other words, >> <video clipBegin="10s" src="http://www.example.com/ >> myvideo.ogg#t=20s"/> >> will start playing the video at 30 seconds into the source material. >> The other option is that the clipBegin of 10 seconds overrides the 20 >> seconds start time, but that has a serious disadvantage: any >> program that >> generates or manipulates SMIL documents will now have to understand >> both >> SMIL clipBegin/clipEnd and media fragment URLs. For example, if an >> XSLT >> processor was instructed to replace all occurrences of url A with >> url B it >> would have to check whether either URL has a media fragment >> included, and >> whether any of the occurrences of URL a was on a media tag that uses >> clipBegin/clipEnd, because in such cases special measures would be >> needed to >> make sure the replacement did indeed do what was expected. >> Double clipping will make life a lot easier, not only for the >> situation >> sketched above, but also for SMIL implementations that do not >> natively >> understand media fragments but in stead rely on an underlying media >> access >> library to provide the data (given a URL). >> The corollary is that I think this finding is universally true: it >> applies >> not only to SMIL but also to other languages, and even to APIs. If >> a media >> library (think: ffmpeg, quicktime, directshow, etc) at some point >> supports >> URLs with fragments in its "open()" call it should make sure its >> "seek()" >> method and related calls will interpret positions relatively to the >> fragment >> specified in the URL. Otherwise all applications that use the media >> library >> need to be made aware of the existence of media fragments in URLs. > > Hi Jack, all, > > This is indeed a very fundamental problem and has to do with exposing > the context of the resource or not. I am very torn on this issues. > > For example, when a browser plays back > http://www.example.com/myvideo.ogg#t=20s in a Web browser for a HTML5 > video element, would we want to see the timeline with an offset or > without? Agreed. The reason I arrived at the conclusion above is support for "fragment- naïve" applications: the only way to make applications that know nothing about media fragments behave sensibly is by providing them just by the section they asked for. So, timelines would start at zero (visually) for t=20s in the file. Applications that do know about fragments, on the other hand, can decide themselves whether they want to display in-context or out-of- context, depending on how the fragment is used. They understand about fragments, after all, so it's easy to strip off the fragment specifier and/or modify it. -- 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 Wednesday, 26 November 2008 08:24:36 UTC