After last week's announcement that the Chrome team was dropping support for H264, Mike Jazayeri has posted a more detailed explanation of the rationale behind the decision.
The initial announcement generated highly polarised discussion, and the explanatory note achieved much the same. In it, Mike argued that it was necessary to make a stance for the future of the video tag by having an "open" codec in order to view videos in the browser. This stance is seen as positive by those who develop open-source software including the other browser teams behind Opera and Firefox, who only support webm.
Producers of content are not as happy with the decision, however. Outside of the desktop browser, H264 is widely used for video content. Since it is used in Blu-Ray, many devices have hardware accelerated decoding and even Intel's latest chips have processor-built functions to permit the CPU to assist where necessary. Not only that, but the smartphone market is saturated with devices that can decode H264; none have hardware assisted webm decoding.
Critics argue that Safari's browser share is a rounding error in the scope of computer browsers (currently, around 5%); but the real explosion in technology is happening in the mobile space, not the traditional desktop. Especially for handheld products, battery life is of key importance so video without hardware acceleration is likely to be a non-starter. For example, in Apple's most recent earnings report, iPads outnumbered Macs 2-1; iPhones/iPods outnumbered them 4-1. For each Safari browser on the desktop, there's six on mobile devices. Putting them into perspective, the 2010 global computer market is estimated at 350m in 2010; compare that with Blu-Ray devices (25m) and iPhone/iPod/iPad devices (100m). 25% of these devices have H264 support built in; and a majority of the 350m computers will be Windows with software or hardware H264 support.
The irony is that the Chrome team are arguing for "open", and since "open" is good, everyone must like it. However, critics point our that not only do Windows and OSX natively support H264 decoding as part of the OS, but Flash also decodes video with H264. Flash is famously not open, yet is still firmly supported by Chrome, as are other patented technologies such as MP3, AAC and even the humble GIF; yet these too are still supported.
Supporters argue that the switch will force content producers to encode video in webm as well as H264, though the comments suggest this is unlikely to happen. Regardless of Chrome's position, Firefox and Opera only support webm currently, and instead of dual encoding, content producers create a Flash player that's capable of decoding the same H264 stream that other browsers can handle natively. Since the technology is already in place, all that will happen is browser detection, which is used currently for other browsers, will be extended to Chrome as well.
Lastly, webm is seen as open and H264 is seen as closed. In fact, only two companies have ever developed webm - On2 and Google - and much of that was behind closed doors. Instead, the webm codec and specification was presented as a fait accompli, with the spec often delegating to the reference implementation in case of inconsistencies. H264, on the other hand, was developed by a consortium of companies who had a vested interest in getting a stable specification in order to implement in hardware. Although covered by patents, the H264 specification was arguably developed in a more open model than webm was.
Recently, the Free Software Foundation has come out in support of Google's webm proposal, arguing that only a non-patent encumbered video codec can be truly free; (although this view requires that the webm codec be not infringing unknowingly on existing patents).
Some reaction to Google's move has suggested that it represents a step back for standards on the Web, because H.264 is supported by more hardware and software. Those comments represent a fundamental misunderstanding of the vision of the Web as free and unencumbered. We can only be free if we reject data formats that are restricted by patents.
In summary, the decision to drop H264 from Chrome is unlikely to make any practical difference to content production of videos either for the web or for hardware devices. Content producers will continue to deliver H264 video and deliver natively or via Flash wrappers for those browsers that don't support it, as they already do today. Further, although Chrome is pandering towards open-source by claiming to be open, the reality is there are several other closed and patent encumbered parts of Chrome which are not being removed. Whether Chrome supports H264 in HTML5 becomes irrelevant, since all browsers support H264, either natively, or with a Flash wrapper.