There is good news: the “open Web”, a vision for the future of the Internet that is participatory, collaborative and free from vendor lock-in is finally coming to fruition. Following Mozilla Firefox's successful introduction of open Web standards into their browser platform and the rapid adoption of Android on mobile phone, today we see many browser vendors and Web-enabled device manufacturers gravitating toward supporting vendor-neutral platforms for rich-media Web experiences. Only a few years ago, it seemed unlikely that tech giants (such as Google, Apple and Microsoft) and nonprofits (such as Mozilla) could agree on something so contentious as future standards for the Web. But because of the fragmented market across devices and the increasingly fragmented browser market on desktop computers, browser vendors and device makers are forced to move forward together or fall behind. There is bad news too. The vision of "write once publish anywhere" is far from reality. Like many contentious agreements, the devil is in the details, and there are a lot of details. The open future of media on the Web is far from guaranteed. In this article, I highlight how the industry is transitioning away from targeting a single vendor for rich-media Web experiences to targeting multiple rich-media Web browsers instead. In this environment, middle-layer solutions will bridge the small differences between implementations. The open Web traditionally has faced significant challenges when it comes to handling rich media such as video and audio. Rich media on the Web has been a battleground for proprietary solutions for years. Adobe Flash has won the current battle and is now the de facto standard for rich media on the desktop Web. However, Flash, is proprietary and is not supported by many devices, such as the iPhone and iPad. The new specifications for rich-media handling that are part of the W3C’s HTML5 standard, namely the <VIDEO> and <AUDIO> tags, are a great leap forward in addressing these challenges. They specify a vendor-neutral, device-neutral way of including rich media in Web pages, just like images are handled today. However, HTML5 requires a transition period. Until we have wide industry adoption and universal agreement on all the details of the specification, systems will be required to support existing proprietary media playback systems in cases where HTML5 is not supported. In the next few years, we're likely will see open-source JavaScript middle layers providing innovative and unified development platforms drawing from both Flash and HTML5 for building robust solutions for rich-media Web experiences. This robustness will include handling everything from analytics to playlists. During this transition period, developers can use JavaScript middle layers to bridge the current gaps between Flash and HTML5. This will provide a unified user experience, regardless of the browser and the underlying technologies that are used.

Some HTML5 Background and the Future of Rich Media on the Web

HTML5 is the proposed next standard for HTML, the basic format for the Web. It aims to reduce the need for proprietary plugin-based rich Internet applications. The promise of HTML5 is that developers can write rich-media applications once and run them on any browser, on any device, from PCs through tablets and smartphones to set-top boxes and IP-enabled televisions. The HTML5 working group, WHATWG, is trusted with the mission of upgrading the Web to support rich Web experiences without depending on proprietary technologies. True to its mission, the group has been operating in a very open manner. Although key working-group members are employed by major vendors, the standard creation process is open and encourages large-scale participation from Web developers and browser engineers. This is no small task when vendors like Microsoft, Apple, Google and Adobe compete for dominance in the area of rich media, which they all perceive to be key for the Web's future. With Microsoft’s announcement that HTML5 will be supported in the next release of IE, the standard got a big boost. But while the standard sets a high bar for interoperability, debates about the underlying technologies put the whole endeavor in jeopardy. The most heated debate revolves around the codec-agnostic nature of the HTML5 <VIDEO> tag. Many open Web advocates promoted the idea of having a baseline royalty-free codec supported by all the browsers as part of the specification. However, when trying to get "buy-in" from all the stakeholders, the standard was not able to specify a standard codec, leaving codec selection open to vendors. The result of this "flexibility" is that today Apple’s Safari and Microsoft IE9 support H.264. Google's Chrome supports the open-source and royalty-free VP8 codec as well as H.264 and OGG. Firefox supports VP8 and OGG/Theora. Google also recently announced that its open WebM project would also use VP8. The situation is further complicated by multiple delivery options. For example, an Apple platform will support Apple http adaptive streaming, while the Google Chrome browser can decode only normal http H.264 assets. And, Microsoft is likely to support Silverlight Smoothstream as a delivery option. This highlights that although all the browser vendors are participating in the HTML5 standard around video, it does not necessarily mean the same video with the same Web page will work on all browsers. For example, imagine a visitor who comes to your site with IE6 and Flash or iPad and Safari. Delivering a high-quality Web video experience becomes almost impossible once again, despite the standard, as the codec and delivery options require, once again, browser-specific, device-specific behavior and back-end support. Moreover, as we have seen with other standards, there are likely to be many idiosyncrasies among other HTML5 feature implementations or simply incomplete support among browsers. This will make it even more difficult to take advantage of the new features without leaving a sizable percentage of Web visitors literally in the dark.

We Have Been Here Before

If you rewind the Web a few years back, you may remember the nightmarish undertaking it was to develop any rich Web experience that supported all the Web browsers of the day. This was true not only because the browsers were immature, but also because they lacked quality JavaScript libraries that could handle browser detection and act appropriately. In early 2006, jQuery hit the scene and changed the way Web applications were developed and deployed. jQuery enabled Web developers to share workarounds and chain together shortcuts of common tasks. This enabled developers to build innovative rich Web experiences quickly, without having to worry about the increasingly complicated set of underling Web platforms. Today, it’s hard to imagine building a Web application without using a JavaScript framework. jQuery alone is used by nearly 30% of the top 10,000 Web sites. In much the same way, we anticipate JavaScript libraries to emerge as bridges between the underlying complexities of delivering a robust HTML5 feature set. Web developers will not have to worry about technicalities, such as how their video will be played back or how their cross-domain request will work. Rather, they simply will issue the high-level call, and the underlying JavaScript library automatically will map to HTML5 or Flash accordingly, allowing developers to focus on the innovative aspects of their application, not its "plumbing".

Html5video.org and Kaltura’s JS Library

Kaltura, the world's first open-source video platform, has developed one such library available at www.html5video.org and has created an industry resource to involve developers. The library was developed in partnership with the Wikimedia Foundation to handle video on Wikipedia, where only patent unencumbered free formats are permitted. Kaltura’s HTML5 media library uses a "fallback" method to provide viewers with the optimal viewing experience by detecting the browser and supported formats on the back end automatically. It can then display the right content in the right format and in the right container, while maintaining a single look and feel and feature set. For example, if you want to deliver an H.264 video to a Firefox client, the Kaltura library would switch to a Flash player automatically in a manner that is completely transparent to the developers’ custom interface components and to the viewer. To learn more, experience HTML5 video in action, give feedback, get involved or help change the way video is done on the Web, go to Html5video.org.