Google’s decision to drop the H.264 video codec from Chrome could affect wider video standards
Google said it would not support H.264 as a baseline video codec standard for HTML video because it refuses to accept the licensing requirements imposed by H.264 proprietor MPEG LA.
Google on 11 January dropped a bombshell on the video content industry when it said it would no longer support H.264 in future versions of its Chrome web browser, opting instead to push its own open source WebM codec and the Ogg Theora codec.
Claim of openness
This blog post from Google Chrome Product Manager Mike Jazayeri elicited concern from publishers and developers concerned they would have to maintain multiple copies of their content if Google canned support for the industry standard H.264 format.
Seeking to clarify Google’s rationale for discontinuing support for the H.264 codec, Jazayeri said on 14 January the announcement was solely related to the HTML
However, Google will continue to support the Adobe Flash and Microsoft Silverlight plug-ins that facilitate H.264 videos in web applications.
Google’s move appeared to make Google the tiebreaker in a classic technology format standoff. To that point, browser makers Google, Microsoft and Apple were on board for H.264, while Mozilla and Opera supported WebM and Theora codecs.
The result is that all publishers and developers using the
Moreover, Google does not want to pay H.264 royalties to intellectual property company MPEG LA.
“To use and distribute H.264, browser and OS vendors, hardware manufacturers, and publishers who charge for content must pay significant royalties – with no guarantee the fees won’t increase in the future,” Jazayeri explained.
“To companies like Google, the licence fees may not be material, but to the next great video startup and those in emerging markets these fees stifle innovation.”
Jazayeri also claimed that Google, which owns the massive video-sharing website YouTube, is sympathetic to the concerns over publishers having multiple versions of video content to run in different formats. However, he said most publishers already produce several video versions optimised for different devices and platforms.
“Our choice was to make a decision today and invest in open technology to move the platform forward, or to accept the status quo of a fragmented platform where the pace of innovation may be clouded by the interests of those collecting royalties,” he concluded.
From those sitting on the sidelines of this grudge match, there is no right or wrong. There are those who support H.264, such as Microsoft and Apple, whose patents are protected by the MPEG LA, versus WebM and Theora, which are open source and supported by Google, Mozilla and Opera.
A step backward?
The best point, counterpoint argument about this issue is between Ars Technica’s Peter Bright, who argued that removing support for H.264 in Chrome is a step backward for openness, and Opera’s Haarvard, who supported Google’s move.
Then there are the third-party observers. Jason Perlow, an IBM infrastructure architect, wrote on ZDNet that despite the discussion about platform and format wars, the issue actually comes down to money.
He said Google will save the hundreds of millions of dollars it costs to support YouTube with servers and storage by supporting a single format instead of multiple formats.
IDC analyst Al Hilwa said that while Google’s argument that H.264 licences are expensive for content owners and developers carries weight, he wondered how long it would be before Google backtracks on its disposal of H.264 support in Chrome.
“With Chrome barely reaching 10 percent adoption it is hard to believe that Google believes it has the dominance to do this or that it would be helping its browser share,” Hilwa wrote.
“What is more is that its open source WebM video container technology and the VP8 codec is still being developed and refined and can hardly be called industrial strength, never mind even narrowly adopted yet.”
Ultimately, he argued that Google will HTML5 with this move “because it may never have a standard codec”.