[whatwg] Adding and removing media source elements

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 
>>> have
>>> 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 
users).

>
> Related, since load() is async it depends on timing whether or not
>
>    <video id=v></video>
>    <script>
>     v = document.getElementById('v');
>     v.src = 'test';
>    </script>
>
> 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 
implementations).

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

WBR, Alex
 
 
 --
 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
 
 Sponsor:
 Blu American Express: gratuita a vita! 
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8613&d=4-2

Received on Tuesday, 3 February 2009 15:59:12 UTC