This post is by Shay David
Click here to view on the original site: Original Post
Editor’s note: This story is part of our Microsoft-sponsored series on cutting-edge innovation. Shay David is the vice president of business and community development at Kaltura, a company offering video tools for publishers.
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 wedge of open Web standards into the browser platform, today we see every browser vendor and every web-enabled device gravitating towards supporting a vendor-neutral platform for rich media web experiences.
Like many contentious agreements, the devil is in the details — and there are a lot of details. This article will highlight how the industry is transitioning away from targeting a single vendor (Adobe Flash) for rich media web experiences to instead targeting multiple rich media web browsers. In this environment, middle-layer solutions will bridge the small differences between implementations.
Businesses looking to take advantage of the promise of a single platform to deliver rich web experiences should also be looking towards middle layer solutions to help bridge the small gaps in rich media implementations.
The open Web has traditionally faced significant challenges when it comes to the handling of rich media, including video, audio and multi-media. Rich media on the web has been a battle ground 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. But it’s not supported by the iPhone or the iPad. [Editor’s note: In fact, Apple chief executive Steve Jobs published a long essay this week criticizing Flash.] The new specifications for rich-media handling that are part of HTML5, the latest version of the basic language of the Web, are a great leap forward in addressing these challenges. They specify a vendor neutral, device neutral way of including rich media in webpages, just like images are handled today.
Some background about HTML5 and the future of rich-media on the Web
HTML5 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 it 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 dependence on proprietary technologies. True to its mission, the group has been operating in a very open manner. While 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.
With all major browser vendors providing feedback or working implementations as the spec evolves, there is room for innovation while addressing a wide range of stakeholder concerns. This is no small task when vendors like Microsoft, Apple, Google, and Adobe compete for dominance in an area of rich-media, which they all perceive to be key for the future of the Web. With Microsoft’s announcement a few weeks ago that HTML5 will be supported in the next release of Internet Explorer, 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 be part of the specification. However when trying to get convince all the stakeholders, the standard was not able to specify a standard codec, leaving codec selection open to vendors. As a result, Apple’s Safari and Microsoft IE9 support the h.264 codec, Google Chrome supports h.264 & OGG, and Firefox exclusively supports OGG/Theora. 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 only decode normal http h.264 assets, and Microsoft is likely to support Silverlight Smoothstream as a delivery option.
In other words, although all the browser vendors are participating in the HTML5 standard around video, it does not nessesaraly 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 with 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 and device specific behavior. 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.
In this context, it is clear to see why the proprietary platforms like Adobe’s Flash will probably be around for quite some time.
We have been here before
HTML5video.org and Kaltura’s JS library
Kaltura has developed one such library to handle HTML5 video, and has created an industry resource to get developers involved. The library was developed in partnership with the Wikimedia Foundation to handle video on Wikipedia, where only patent unencumbered free formats are supported. Kaltura’s HTML5 media library uses a “fallback” method to automatically provide the viewer with the optimal viewing experience by detecting the browser and supported formats on the backend, and displaying the right content in the right format and right container while maintaining a single look & feel and feature set. For example, if you want to deliver an h.264 video to a Firefox client, the Kaltura library would automatically switch to a Flash player in a manner that is completely transparent to the developers’ custom interface components.
To learn more, to experience HTML5 video in action, to give feedback, to get involved and to become part of changing the way video is done on the Web, go to www.HTML5Video.org.
[Thanks to Michael Dale for help with an early draft of this post.]
The community responds
– Charles McCathieNevile, Chief Standards Officer, Opera
But video does need to be coded in different versions for the time being — while more or less automatable, that’s still a piece of work you have to get right before the scripts can do all their magic. And the libraries need to be built well and used properly.
While these libraries are an important part of the solution, and for many authors will be indispensable until we get agreement on a free standard for video format, we need to remember that reaching that particular nirvana actually has practical benefit for the world — less need for script libraries means less processing, less battery used, less bandwidth, fewer programming errors (one of the original problems that the libraries already help to minimize) and a Web that works better.
– Caleb Elston, Vice President of Products, Justin.tv
It’s exciting to see the enthusiasm and support that browser vendors and technology companies have thrown behind HTML 5 video, but there are still issues to be resolved before we make a big move to adopt it. Our goal is to make live video part of the everyday web experience, and that means being wherever users are and creating a great experience — HTML 5 isn’t the way to do that, at least not yet.
While HTML5 is technically exciting, we only care about what our users actually experience, and today we do not see much user benefit to HTML5 video in desktop browsers.
Companies: Adobe, Apple, Justin Tv, Kaltura, Opera