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

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

--- Comment #3 from Philip Jägenstedt <philipj@opera.com> 2011-05-10 11:12:57 UTC ---
(In reply to comment #2)
> (In reply to comment #1)
> > "What's the use case?"
> > 
> > When navigating directly to a media resource, I can see the argument that
> > changing the fragment component can be used to trim down the fragment by
> > testing successively smaller ranges. Are there other cases? Is it critical in
> > this situation that the video is never reloaded or has its state reset? The
> > time to decode and seek to a certain point in a file is rather small even
> > without this optimization.
> 
> This refers to changes in the URL bar, right? I would e.g. use the seek bar to
> find a specific position (region), then change/add the fragment with that
> position (region), test it, and cut and paste it to send it to friends.

Yes, that's the use case I was guessing. Are there others?

> Any re-load of a media resource is annoying when it's not necessary. I've seen
> video loads that have taken several minutes on a poor connection, so I'd really
> like to avoid that.

As long as the browser doesn't aggressively evict media resources from the
cache, this would work. The only repeated work is decoding the metadata of the
resource. If this is really a problem, I think the best solution is to cache
this information as well, as this would be useful for pages that uses 10
instances of the same audio file for effects, etc.

> > 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?

> > 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.

> > 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.

-- 
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:13:00 UTC