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

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

--- Comment #2 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> 2011-05-10 10:45:13 UTC ---
(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.

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.


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


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


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

-- 
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:45:15 UTC