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 20:16:10 +1100
Message-ID: <2c0e02830811260116g51109564w352779d100fa2da1@mail.gmail.com>
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.

Received on Wednesday, 26 November 2008 09:16:49 UTC

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