W3C home > Mailing lists > Public > public-media-fragment@w3.org > November 2008

Re: Combining media fragments with other time-clipping methods

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Wed, 26 Nov 2008 11:27:11 +1100
Message-ID: <2c0e02830811251627x5d1af576j1170cdda50553c30@mail.gmail.com>
To: "Jack Jansen" <Jack.Jansen@cwi.nl>
Cc: "Media Fragment" <public-media-fragment@w3.org>

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

The problem is that there will always be use-cases for both. I might
just be interested in this segment, so I'm happy for the browser to
display just this segment on the timeline (scrub-bar). However, if I
want to know which segment of a video file it is, it may also be nice
to display the full video's duration and jump to the offset. That is
indeed what YouTube does. And it allows access to the rest of the file
by simple clicking on the timeline.

This may be something worth discussing at the next F2F. We may need to
find a way to allow both display mechanisms. For the second one where
the full video's context is desired, I am not even sure how to
communicate the duration of the file.

Received on Wednesday, 26 November 2008 00:27:52 UTC

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