[Bug 10723] <video> Support stopping at the time given by a media resource's fragment identifier

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10723

--- Comment #18 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> 2011-05-09 23:31:43 UTC ---
Some clarifications:

(In reply to comment #17)
> (In reply to comment #15)
> > 
> > 2.
> > Also this site:
> > http://metavid.org/w/index.php?title=Stream:senate_proceeding_02-04-11/0:00:25/0:01:45&tl=1
> 
> This again seems to just be one media file with jumping to different segments.
> You wouldn't want to replace the URL on the fly, that would trigger a file
> reload each time.

No it doesn't. Browsers have stopped reloading resources where just the
fragment is changed and not the actual resource URL. The way in which media
fragment URIs are specified plays with that fact, too. Unless the resource has
expired, it will only request the appropriate byte ranges for the time range
specified in the URL. 


> > 3.
> > Then of course there's the whole use case collection in the requirements doc,
> > e.g.
> > - pagination:
> > http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-reqs/#scenario2.1
> 
> That use case doesn't make any sense. Why would you require that someone do
> something at the end of the 20 minutes to see more?

Because the video is 7 hours long and has annotations that are displayed with
it. There is only a certain amount of content that you can place on a single
Web page before it gets too cluttered to be useful. Annotations for 20 min of
video (navigable timed transcript in particular) are roughly the limit. You can
see that at work on http://metavid.org/ - it already implements exactly that
use case. But it has to virtually chunk the media on the server to 20 min
chunks (using a Apache plugin), which makes it slow and not scalable.


> > - fragment mashup:
> > http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-reqs/#scenario3.3
> 
> If he uses SMIL, it works already, no need for a change to HTML.

Which browsers support SMIL out of the box? So, let's abstract away from SMIL,
which is overkill for this use case anyway (and I don't actually remember why a
technology was used in a use case description...). The point is that you can
easily imagine a playlist format that essentially consists of a sequence of
media fragment URIs with start and end time that the browser loads one after
the other - every time the end of a fragment is reached, the next resource
fragment is started playing.

===

It is always possible to reject any use cases for end points on media fragment
URIs in a video's @src attribute by saying that you can use JavaScript to catch
that position and do something (pause / load a different resource etc). Even
using MutableTimedText for controlling what to do at the end of a fragment
would require JavaScript. The issue, however, is that you are always working on
a fragment. If we do not support end times in media fragment URIs, we
implicitly specify that the end time is the end time of the media resource. We
cannot always expect a JavaScript solution to be around for doing media
fragments, e.g. outside browsers. Such applications can only use media fragment
URIs to restrict both the start and end time of a media resource. It makes
sense to align the behaviour now.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Monday, 9 May 2011 23:31:46 UTC