Combining media fragments with other time-clipping methods

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