[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 #22 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> 2011-05-10 10:14:41 UTC ---
(In reply to comment #21)
> (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().)

OK, well this is a problem with just start time offsets, too. I've registered a
new bug for this over in bug 12643.

-- 
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 10:14:43 UTC