Streams of Thought: WebM Strategies for the Hacking Crowd
Given the nature of code modification in the open source and free software movements, this type of software tends to stay in beta or in developer-preview status much longer than the typical proprietary software code.
Between code tweaks and full branches, modifications can muddy the code. The Google-sponsored WebM project is not much different from the typical open source project, with three exceptions: Google is throwing its financial muscle behind it, it has a long list of work items on the road map, and the company has tagged the current release as a developer preview, with a full release sometime in the future.
For the sake of space, I'll just note note that it's not every new video format that can emerge on equal marketing footing with established codecs used in the major encoding tools.
Speaking of encoding tools, the work list covers a number of critical to-do steps, including support for third-party encoding solutions-via the use of QuickTime and DirectShow plug-ins.
The plug-ins are required so that WebM can fit into established workflows. To do this, Google had to create a licensing scheme that allows them to be used in proprietary commercial software products, which we've covered in several articles on the StreamingMedia.com website.
Those who might choose to hack away at the code for these third-party plug-ins will be able to keep their own code, as the licence clearly states that any code modified or added to need not be returned to the open source community.
The company also has announced, via the On2 website, that Wildform is taking over the creation and sales of its former Flix Pro products, which will support VP8 video and Ogg Vorbis audio compression, saving files with the .webm extension.
Another thing to do is to create support for WebM on the Android mobile platform. Because there is no player plug-in support for WebM, the use of WebM on any device requires a browser that supports the format, including Google's Chrome. Android support for WebM is expected in Q4.
So it might be a bit harder to contribute, unless the hacking is done on an open source browser, such as those based on Apple's WebKit or Mozilla's open source code. After all, because WebM doesn't require a plug-in to play back in a browser, only modifications to the browser's core code will enable playback. At the time of this writing in late June, the browsers that supported WebM were Chrome, Mozilla Firefox, and Opera.
A final way to contribute would be in the area of code optimisation for compression and decompression. While these may be specialised areas, they are desperately needed, as Google acknowledges in the WebM FAQ.
So what happens in the meantime? For now, external libraries are needed to support H.264 and other formats that are the base-level codecs for browsers that don't natively support WebM.
We've covered code snippets on Streaming Media.com that failover from H.264 and legacy codecs back to the Adobe Flash plug-in, but Google rightly points out on the WebM FAQ that there are other prebuilt options, such as Kaltura's HTML5 Media Library, the Open Standard Media Player, Projekktor, and Modernizr, among others.
Kaltura deserves kudos for its approach to abstraction, combining WebM, H.264, and legacy codec support into webpage libraries. These types of tools will take some of the pain out of the transition period until HTML5 is firmly established.