[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 #20 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> 2011-05-10 08:51:02 UTC ---
(In reply to comment #19)
> (In reply to comment #18)
> > 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. 
> 
> Which browsers? Is the special-casing when the src attribute is set, or is it
> part of the resource selection algorithm (which is run asynchronously as a
> result of setting src)?

I was talking generally - when you change the fragment on a Web page in the URL
bar, the Web page is not reloaded any more, but only the fragment offset is
changed.

As for video, there is no implementation yet, so of course I'm not referring to
implemented cases there. But the way in which media fragment URIs are specified
implies that if the browser has setup information about the resource (i.e.
metadata loaded), then it will use that for further fragment retrieval actions.
So, basically it works like setting the currentTime to a different location on
the same resource. I think that would be outside the resource selection
algorithm, which would not be re-run for a change of fragment unless the
resource has expired in the meantime.

-- 
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 Tuesday, 10 May 2011 08:51:04 UTC