[Bug 12643] <video> change of fragment in media fragment URI consequences

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

--- Comment #4 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> 2011-05-10 11:44:09 UTC ---
(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> 
> > > For <video> elements in an HTML document, the utility of dynamically changing
> > > the fragment is less obvious.
> > 
> > Yes, in <video> it is not so obvious, because you can obviously just change
> > currentTime to achieve the time offset effect. But if we support fragments in
> > @src, it's a technical problem to solve. Note that the same applies to a change
> > of track fragments on videos, which are important for multitrack media.
> 
> Good point, but in that case you really do want to reset the state and set up a
> new decoding pipeline, don't you? Or do you think that this should change the
> current track without even resetting currentTime?

I think for any change of fragment that doesn't indicate a time offset, we have
to reset to currentTime=0. Including v.src=v.src. I don't think we need to
re-load the resource even for a track change.


> > > Does it side-step the resource selection
> > > algorithm? Does it cause currentTime to change? More generally, it seems like a
> > > very cumbersome interface for whatever it is it should achieve. If you have
> > > <source> elements, you'd have to change the src attribute on all of them and
> > > then call load().
> > 
> > I think script would just set @src to @currentSrc replacing/adding the
> > fragment.
> 
> Yeah, that would work. Note however that it would create an invalid DOM, as
> <source> elements are only allowed as children of <video> elements without src
> attribute.

That's a more general problem of how to change the media resource on a media
element through script. This problem already exists even without fragments.


> > > Should that side-step the resource selection algorithm and
> > > how?
> > 
> > I think it should just do the part that it does when interpreting a fragment
> > and bypass any earlier steps in the resource selection algorithm.
> 
> My point here was that currently changing the src attribute on <source>
> elements has no effect, the only way currently is to call load() when you're
> done manipulating them. This *will* invoke the resource selection algorithm, so
> I can't see how to side-step it.

I meant what happens when a resource is loaded initially as part of the video
element setup. At some point the fragment URI part is being interpreted (in
fact: point 8 in
http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#getting-media-metadata).
We should just jump to that point when changing the fragment on the URI.

-- 
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 11:44:11 UTC