- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Wed, 26 Nov 2008 20:16:10 +1100
- To: "Jack Jansen" <Jack.Jansen@cwi.nl>
- Cc: "Media Fragment" <public-media-fragment@w3.org>
On Wed, Nov 26, 2008 at 7:23 PM, Jack Jansen <Jack.Jansen@cwi.nl> wrote: > > 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. Yes, I agree. I think leaving it to the application is the only sensible thing to do. If the application knows what a fragment is, it can decide for itself if it wants to display context, e.g. in a timeline, or not. >From a xml tag POV, one has to assume that a offset is indeed calculated from the beginning of the resource link, which in the case of temporal fragments is the time offset, so double offsetting for SMIL makes sense, I think. Cheers, Silvia.
Received on Wednesday, 26 November 2008 09:16:49 UTC