[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 #21 from Philip Jägenstedt <philipj@opera.com> 2011-05-10 08:58:52 UTC ---
(In reply to comment #20)
> (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.

That might be the intention, but if we want changes of src that only change the
fragment component to be handled differently, it has to be in the HTML spec. If
not, it will be treated as any other change of the src attribute and cause all
state to be reset and fetching/decoding to start over. (Currently even setting
v.src=v.src isn't handled, it would be similar to calling load().)

-- 
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:58:54 UTC