Monday 8 November 2010

Changes to HTML5 video/audio load() function in Firefox 4

I've updated the media load() implementation in Firefox 4 to match the current WHATWG media load algorithm specification. There are three main changes that web developers using media elements should be aware of.

Firstly, error reporting has slightly changed. When a media element fails to load from its <source> children, an "error" event is dispatched to every child element which failed to load. Previously in Firefox 3.x you'd receive only one "error" event dispatched to the media element once all of its child <source> elements had failed to load. Now you only receive "error" events in the child <source> elements, and not in the media element itself.

For example, suppose you have the following markup:

<source id="mp4_src"
        type='video/mp4; codecs="avc1.42E01E, mp4a.40.2"'>
<source id="3gp_src"
        type='video/3gpp; codecs="mp4v.20.8, samr"'>
<source id="ogg_src"
        type='video/ogg; codecs="theora, vorbis"'>

Firefox 4 does not support the playback of patent encumbered content, so you'll receive "error" events in the <source> elements with the MP4 and 3GP resources, before the Ogg resource is loaded. Note also that the <source> children are loaded in the order in which they appear in the markup, and if one <source> child successfully loads and is playable, the children after it won't be loaded.

To detect that all child <source> elements have failed to load, check the value of the networkState attribute of the media element; if its value is HTMLMediaElement.NETWORK_NO_SOURCE, you know all child <source> elements have failed to load.

If you add another child <source> element to a media element which is in networkState HTMLMediaElement.NETWORK_NO_SOURCE, it will attempt to load the resource specified by the newly added <source>.

Secondly, when the load begins has changed. When you set the src attribute of a media element, or add a <source> child element to a media element, a load will be scheduled to run asynchronously as soon as the current JavaScript context exits (basically the load starts the next time we return to the browser application's main event loop). So for example, suppose you have some timeout set such as:

  function() {
    var v = document.createElement("video");
    v.src = "video.ogg";
    // Do some other stuff...

When the function runs, the load for the video element won't begin until after the function returns, and control returns to the browser. This is important, because in Firefox 3.x, the load is started (and could even run to completion!) as soon as you set the media element's src attribute.

Lastly, the media element's events now no longer bubble. Previously they bubbled, and this was a bug in Firefox 3.x and in violation of the spec.


zcorpan said...

Thanks for these fixes. Firefox 4 should then be more interoperable with Opera.

networkState is NETWORK_NO_SOURCE when the resource selection algorithm awaits a stable state, or if the parser is waiting on the network for more sources to come in, so it's not completely true that it means all sources have failed. :-) A more useful way to check if all sources failed is to just listen for the error event on the last source element.

Unknown said...

gooood job


Anonymous said...

Great work came at a perfect time for me, html5 video playerwould be really cool if we could at least get an option to enable the HTML5 mode player in the next Subsonic release. Not only would it bypass the need for flash, but it also has some extra features (wav playback, etc).It seems the biggest issue would be with flv video, but by transcoding to mp4 instead of flv, that could be solved. Even without the video fix, making it optional would allow those of us the mainly use Subsonic for music to benefit from the new player.