Featured Links:
Akamai
The Original Internet Content Delivery Network for Steaming Services
Amazon EC2
Amazon's Elastic Compute Cloud Web Services
Level3
The CDN for Content Delivery Networks
Google vs H.264 Print E-mail
Written by John Doyle   
Monday, 07 February 2011 12:23

 

Whither Chrome

[updated: August 2012]

 

When Google announced in early 2011 that the Chrome browser would stop supporting the popular H.264 codec, it was a shock for many online video content creators and publishers. The reaction from the general community and digerati was overwhelmingly swift and brutal.

 

Google wants everyone to use its new WebM codec instead of H.264. The WebM team had been working hard to improve the quality and efficiency of this codec, and expand the features of its SDK. The Google WebM team had provided a project update at Streaming Media West 2010, and the good ship Chrome boldly set sail into shark-infested waters.

The Chrome browser had been steadily growing in popularity since its release in 2008.  It's lightening fast speed made the Chrome emerge as a legitimate contender.  When Google announced that Chrome would be dropping H.264, the browser was already installed on 15% of all desktops, making it number 3 after Internet Explorer and Firefox.  (As of the latest update of this article, the Chrome browser has since overtaken IE as the most ubiquitous desktop browser.)  Content producers who take cross-platform publishing seriously will definitely want to make sure that their videos play on Chrome.  But there's a significant problem.  Most content producers made the switch to H.264 due to it's highly efficient encoding algorithms and adoption by Apple.  Without support for the H.264 codec in Chrome, content producers and publishers will be forced to duplicate the encoding workflows for all their content.

 

 

How serious is this? For the average small to medium sized content producer, making an adjustment to their workflow might not seem out of the question, but for those who have amassed considerable collections of on demand content, it could be a very expensive and time consuming change.  If those content producers want to provide comparable streams in WebM, their encoding time and storage requirements will double, and for content producers using 3rd party OVPs, the cost and effort could get very uncomfortable.  In the tight squeeze of a troubled economy, this could be life-threatening.  Some content producers will have no choice but to risk the loss of precious eyeballs by dropping native video support for the Chrome browser.

But the story is a complicated one.  H.264 is protected by patents that are controlled by a licensing consortium.  Currently, no fees are being collected, but that is subject to change in the future.  This fear of license fees is the motivation behind Google's decision, and it's the motivation behind much animosity toward the H.264 standard.  Google has been applauded by the open source community for its bold move.  Bold is a good word to describe it; by dropping support for H.264, Google clearly drew a line in the sand.  Will the waves of change wash away that line, and sweep WebM and Chrome out to sea?  that hardly seems likely.  With the mighty force of Google behind it, WebM is not likely to disappear on the horizon.  On the other hand, H.264 shows no sign of being held back by the threat of future  licensing fears.  What is likely to continue is a deepening fracture in the world of video codecs.

But is this really a problem? Do we really have to choose between H.264 and WebM?  The choice between competing internet standards is often likened to the previous century's war between Beta and VHS video formats.  But a closer look shows that the comparison is not accurate.  The playback devices for VHS and Beta video tapes in the 1970's were dedicated appliances.  There was no option for a single appliance that could play both VHS and Beta; consumer had to choose one or the other.  As a result, JVC's VHS format won and Sony's Beta quickly faded away in homes.   But a similar outcome is not likely to repeat in a battle between WebM and H.264.  The same desktop is able to play both formats.  So why all the fuss?  What's wrong with a bi-furcated codec landscape?  Granted it is not ideal for content producers who want to continue reaching as wide an audience as possible.  After all, there will be many users who will refuse to run multiple browsers for one reason or another.  Content producers who do not transcode to WebM will miss out on a lot of eyeballs.  But for those whose distribution model is not advertising, is that really so bad?  Can't we all just live and let stream?

 
Copyright © 2017 consultify.com. All Rights Reserved.