Many projects here at MetaBroadcast involve working with video embedded in web pages. This has got a lot easier over the years but it makes me sad that it is still not as easy as it should be. Much of this has to do with being caught in the flux of updating standards and software and the gradual decline of solutions such as Adobe Flash. However I think it is important to keep pushing for standards and not just accept the current situation.
html5 video limitations
The HTML5 <video> and <audio> tags are the great hope of the web. As Mozilla put it, they make multimedia into first class citizens. They, in theory, make including audio and video in you web page as easy as including an image. In 2013 that is really how it should be however as the these tags are relatively new anybody using them and attempting to make a site that will work across different browsers will encounter significant issues.
Two main problems are often encountered when using the <video> tag. Firstly, it is not supported on every common browser in use today, an issue that is particularly prevalent in corporate environments. Secondly, the codecs supported by each browser vary, meaning that video has to multiply encoded in different formats to work across different browsers.
some sort of plugin to the rescue?
In the past (and presently in many cases) video and audio were embedded in a page using a variety of often Adobe Flash based plugins. Today we sometimes have to resort to plugins to ensure cross browser compatibility. A solution we have been using is MediaElement.js. In a practical sense this is a great solution. It uses the browser's embedded video playing capabilities through the <video> tag where available and substitutes in a Flash or Silverlight players when not. It also supplies an API which is almost the same as the HTML5 video API. It requires a little bit of extra Javascript to use and does a pretty good job of making video work in a variety of desktop and mobile browsers.
While solutions like MediaElement.js help us for now it is important I think that we do not settle for them in the long term and support using native HTML5 elements in the way intended by standards. Plugins like this introduce some complexity of their own. For example they are not as easy to style as a <video> elements. They increase the size of page downloads. The complexity of including a video is increased possibly meaning more bugs and development time as well as making life difficult for newcomers (an important consideration if initiatives to increase the number of people coding are to be successful). Also, not all devices support Flash or Silverlight, so the fallback players might not be a failsafe solution.
time to be optimistic?
It is easy to give up and just accept these workarounds (such as MediaElement.js) as an inevitable part of web development, but we should not. Instead it is important I think to keep pushing for HTML5 video whenever possible and to keep up to date with developments to enable its use on as wide a range of platforms as possible.
There are many reasons to be optimistic. The HTML5 <video> tag is already widely supported across desktop an mobile browsers. There are some issues around the H.264 codec and royalties in relation to the Mozilla Firefox browser, but solutions are starting to appear.
Even Microsoft's Internet Explorer isn't necessarily holding up the pace of change. The video tag has been supported since IE9. IE10 is available for Windows 7 which means that most versions of Windows will have access to a version of IE that supports the tag. The notable exception is of course Windows XP, but official support for that ends next year. This is great news for corporate environments that want to use Microsoft products, but still be able to use modern web technology.
With all of this in mind I think it is important to support and champion the video and audio capabilities in HTML5 and only use workaround solutions where strictly necessary. It feels as though this technology is nearly ready for the mainstream and supporting it will help it to cross the finish line.