W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > May 2011

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

From: <bugzilla@jessica.w3.org>
Date: Tue, 10 May 2011 10:31:13 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1QJkDh-0007AP-GG@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12643

Philip Jägenstedt <philipj@opera.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |philipj@opera.com

--- Comment #1 from Philip Jägenstedt <philipj@opera.com> 2011-05-10 10:31:12 UTC ---
"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.

For <video> elements in an HTML document, the utility of dynamically changing
the fragment is less obvious. 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(). Should that side-step the resource selection algorithm and
how?

IMO it might be easier to work with if there were IDL attributes startTime and
endTime, or if a fragment implicitly creates a cue range with pauseOnExit set
which could then be manipulated by scripts. But, without a clear understanding
of the use cases I'm just guessing...

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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:31:10 UTC