[whatwg] Adding and removing media source elements
Calogero Alex Baldacchino
alex.baldacchino at email.it
Tue Feb 3 15:59:12 PST 2009
Philip Jägenstedt ha scritto:
> On Tue, 03 Feb 2009 05:44:07 +0100, Ian Hickson <ian at hixie.ch> wrote:
>> On Tue, 3 Feb 2009, Chris Pearce wrote:
>>> (2) Why don't we invoke load() whenever a media element's src attribute
>>> or <source> children are changed, regardless of networkState? That way
>>> changes to the media's src/source other than the first change would
>>> the same effect as first change, i.e. they'd have an immediate effect,
>>> causing load() to be invoked.
>> Doing this would cause the first file to be downloaded multiple times
>> in a
>> row, leading to excessive network usage.
> Surely this can't be the only reason? User agents are free to
> speculatively keep the current source loading when src/source changes
> and to stop loading it only if the "current media resource" does
> change. That, and caching, should be enough.
> I have always imagined that the reason for the conditioned load() is
> to not interrupt playback by fiddling with the DOM or doing something
> like *v.src=v.src* (although I'm quite sure that doesn't count as
> changing the attribute). However, now I can't convince myself that
> this makes any sense, since surely if you change src/source you
> actually do want to change the effective source (and load() is
> scheduled to run after the current script, so there's no risk of it
> being run too early).
Doing the same with a script element can cause the script to be
re-fetched and re-executed on some browsers, so I think there is a
concrete chance to find the same behaviour for videos, and the spec have
to say when the load is allowed (or, at least, when it should not
happen). I'm not sure that every changes to the effective source should
take place, for instance, changing it (through the dom) after playback
has already started might not be very usable and should be avoided,
therefore, any such attempt should be ignored/aborted (eventually with
an exception) after playback start and until its end or an explicit stop
(by the user or by a script, so to encourage programmers to check the
state of the playback before taking any action).
Also, scheduling the load "after the current script" could not solve the
whole problem: any changes to the video may happen through an event
handler, therefore by different scripts, thus I think that it could be
helpful to allow a script to freeze (or revert) ongoing operations (as
well as the video interface) but playback (if yet started), so to (try
and) ensure (somehow) that any dynamic changes can be performed without
bothering the user, or are disallowed otherwise.
(what for? I'm considering the (maybe edge) case of a dynamic update of
a video source, for instance when a different/better source (higher
quality or with a more appropriate translation) is available, or for any
other reason (e.g. the complete list of available sources might be
streamed as a sequence of remote events for an immediate update and a
deferred/repeated playback), but if the current source is being played
it might not make sense to stop it and change it with a different one,
eventually restarting from the beginning, because it may be annoying for
> Related, since load() is async it depends on timing whether or not
> <video id=v></video>
> v = document.getElementById('v');
> v.src = 'test';
> causes the source 'test' to be loaded, as the network state may not be
> NETWORK_EMPTY when the src attribute is set. The same goes for adding
> source child elements of course. Yes, this is the same issue as
> http://lists.w3.org/Archives/Public/public-html/2009Jan/0103.html and
> would be resolved by calling load() unconditionally.
Or checking the network state to choose if it's the case to call load()
explicitely; however, due to its asynchronous nature, that might cause a
double invocation (depending on implementations), or similar problems.
Perhaps, the load() method should leave the network state unchanged
(NETWORK_EMPTY in this case) or revert it to a previous value whenever
the method fails to choose a candidate (e.g. because there is no
valid/new source, a yet chosen source is being played and cannot be
changed before it's stopped, and so on), and successive changes could be
scheduled for an evaluation as soon as possible (e.g. as soon as the
network state returns to be NETWORK_EMPTY, or becomes NETWORK_LOADED
and/or the playback ended or has been stopped - if appropriate in this
case), possibly being collapsed into a single task.
This way, a load evaluation preceeding the script execution, in your
example, would fail and revert the network state to be empty, triggering
a new invocation after the script has been executed; an evaluation
following the script would work as expected; an evaluation invoked while
the script is executing would cause the new v.src value to be scheduled
for a later check, (the overall mechanism would result in an
unconditioned scheduling of conditioned load() invocations, collapsed
into one single entry until a call to .load() is made, which I think
should be more performant than calling load() unconditionally - but I'm
not sure, it may depend on both the scheduler and the load method
Source elements might require a different treatment from the "src"
attribute. For instance, adding such an element while a list of
candidates is being generated or before entering the Candidate Loop
could cause the list to be re-checked, otherwise a delayed load is
scheduled (but this could add unneeded complexity, thus just scheduling
the change for a later evaluation could be enough).
Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
Blu American Express: gratuita a vita!
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8613&d=4-2
More information about the whatwg