W3C home > Mailing lists > Public > public-html@w3.org > April 2009

Media elements may never load, may load the wrong source, etc

From: Philip Jägenstedt <philipj@opera.com>
Date: Thu, 09 Apr 2009 10:49:33 +0200
To: public-html@w3.org
Message-ID: <op.ur32svy5atwj1d@sisko.linkoping.osa>
Some feedback on the big batch of changes to media elements made in March.

1. may never load

Previously there were many conditions for when to implicitly invoke the  
load() method, e.g. when a media element was inserted into a document.  
This was all replaced by the resource selection algorithm, but as far as I  
can see that algorithm is only invoked by an explicit load() and in the  
Audio(src) constructor.

In other words, there's nothing to cause e.g. <video autobuffer autoplay>  
to either begin buffering or playing unless a script explicitly calls  
load() or play() on it.

For simplicity I would prefer that the resource selection algorithm be  
started for any media element, regardless of whether it has any  
src/source, is in a document or any other conditions. This makes all of  
the below equivalent:

<audio src="foo">

a=new Audio("foo");

a=new Audio();
a.src="foo";

a=document.createElement("audio");
a.src="foo";

This behavior isn't incredibly important in itself, but it removes the  
need for special cases in the Audio constructor or elsewhere. Ignoring  
whether or not the media element is in a document when invoking the  
resource selection/fetch algorithm makes sense for preloading, etc so I  
don't think we should reintroduce that.

2. may load the wrong source

Futher, I think it's necessary to add a clause after step 1.4 that the  
script which modified src/source must complete before the (now  
asynchronous) resource selection algorithm continues. Otherwise, a script  
like...

a.src="audio.ogg";
<!-- async algorithm could set NETWORK_LOADING and run step 3-4 -->
if (condition)
   a.src+="?t=0:00:10/0:00:20";
else
   a.src+="?t=0:00:20/0:00:30";

...might cause "audio.ogg" to be loaded even though it wasn't even a  
candidate. It's a race condition, but even for more trivial cases allowing  
the script to first finish modifying the DOM must give a more predictable  
behavior.

3. about MEDIA_ERR_NONE_SUPPORTED

Simon has suggested [1] and Ian confirmed [2] that

    <video>
     <source src=1>
     <source src=2>
     ...
     <source src=n>

Can generate n-1 error events with error code MEDIA_ERR_NONE_SUPPORTED on  
a slow network.

This seems like a very bad behavior as authors are likely to use this  
error to determine if they need to replace the element with fallback  
content. The slow network issue is likely to be overlooked and even if the  
author is aware of it it's not trivial to determine if you got the error  
because of the network or because there really was no supported source.

We first suggested firing one error event for each source that isn't  
supported, adding the URL of the unsupported resource to MediaError  
object. That might be overkill, but there must instead be a guarantee that  
the event only fire once and only if no more <source> tags are going to  
trickle in over the network. It's quite simple to just keep waiting if the  
<video> tag hasn't been closed yet, but I'm not sure how such a  
requirement can be stated in terms of DOM. Ideas?

[1] http://lists.w3.org/Archives/Public/public-html/2009Mar/0201.html
[2] http://lists.w3.org/Archives/Public/public-html/2009Mar/0629.html

-- 
Philip Jägenstedt
Opera Software
Received on Thursday, 9 April 2009 08:49:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:33 GMT