W3C home > Mailing lists > Public > public-media-fragment@w3.org > January 2009

ISSUE-1 (Raphael): Combining Media Fragment URI with other time-clipping methods

From: Media Fragments Working Group Issue Tracker <sysbot+tracker@w3.org>
Date: Wed, 21 Jan 2009 13:00:53 +0000 (GMT)
To: public-media-fragment@w3.org
Message-Id: <20090121130053.AADD96B63E@tibor.w3.org>

ISSUE-1 (Raphael): Combining Media Fragment URI with other time-clipping methods

http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/1

Raised by: Raphaƫl Troncy
On product: 

Related to ACTION-13 [1] closed by Jack, see the whole thread starting at [2], I raise this issue since everything is not crystal clear for me.

I assume that the media fragment is regarded as in-context, that is, http://www.example.com/video.mov#t=20,30 will play the fragment between the seconds 20 and 30 of this resource, but the user sees the whole timeline of the video and can click elsewhere on the slider, thus making a new request.

I understand that specifying a time-clipping method, for example in SMIL, is relative to the (timeline of the) resource. Therefore, what's happened if I have:
<video clipBegin="5s" clipEnd="15s" src="http://www.example.com/video.mov#t=20,30"/> ?

Scenario 1: the media fragment is completely ignored, the UA plays the video segment between the seconds 5 and 15

Scenario 2: the clipping method is done relatively to the media fragment, the UA plays the video segment between the seconds 25 (=20+5) and 35 (=20+15)

Scenario 3: the clipping method is done relatively to the media fragment but bound to the media fragment, the UA plays the video segment between the seconds 25 (=max[20,20+5]) and 30 (=min[30,20+15]).

In summary, how do we cover the cases where the media fragment is i) encompassing, ii) embedding, iii) disjoint and iv) partially overlapping the boundaries of the other time-clipping method?

[1] http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/13
[2] http://lists.w3.org/Archives/Public/public-media-fragment/2008Nov/0095.html
Received on Thursday, 29 January 2009 10:41:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 21 September 2011 12:13:32 GMT