Strong opinions, weakly held

Tag: video

Another theory on Google’s dropping H.264

Horace Dediu has another theory on why Google is dropping support for the H.264 video codec:

I rather think that Google’s decision is a misguided emphasis on technical details in lieu of engaging in a deep strategic re-evaluation.

Don’t miss the interesting comparison to Apple’s decision to go with the PowerPC over Intel processors back in the day.

I’m sort of obsessed with this decision by Google not because of its effect on me personally, but because I’m curious as to how companies come to these kinds of decisions. It’s complex and fascinating.

One reason Google dropped H.264 support

Matt Drance offers one hypothesis for why Google is dropping H.264 support:

If H.264 becomes and remains the dominant codec, then Google needs to convince all of its partners to bundle H.264 decoder hardware in order to preserve a competitive video experience on Android. It cannot, however, guarantee them favorable licensing terms, because it is not a licensor in the H.264 patent pool. Android and Google could end up with a problem on their hands if OEMs hesitate or get hit with lawsuits.

Enter WebM/VP8. By overseeing both the technology and policy, Google has much more power to insulate its partners, and thus the entire Android platform, from disruptive patent or license disputes. If all goes well, it could go a step further and require Android OEMs to include VP8 decoder hardware from a (hand-picked, of course) list of vendors, guaranteeing a minimum standard of video playback on all Android devices. Google could even acquire one or more of these vendors for good measure.

Why dump H.264 entirely? Why not hedge your bets, especially if H.264 is working right now? Google says “our goal is to enable open innovation;” what it in fact means is “we prefer patents we own.”

Google’s decision to drop H.264 support in Chrome

Google’s decision to drop native support for the H.264 video codec in Chrome has generated a number of arguments on the Web. Google’s defenders argue that H.264 is not royalty-free and is thus inappropriate for use with HTML5, since the W3C refuses to mandate the use of royalty-encumbered technologies in its specifications. Google’s critics argue that this doing so is a cynical move aimed at bolstering its own codec, WebM, and undermining vendors like Apple and Microsoft who support H.264 and who don’t support WebM or Theora. It seems inarguable that this decision by Google insures that Flash players will continue to be the primary means of showing video on the Web.

The best overview of this issue that I’ve seen is Peter Bright’s piece at Ars Technica: Google’s dropping H.264 from Chrome a step backward for openness.

The state of the video tag

YouTube’s developer blog has a sort of state of the video tag post, explaining why the HTML5 approach works for experimental purposes but isn’t going to soon displace Flash as the default for their service. The problem of browser makers not agreeing on a single video standard to support is huge:

First and foremost, we need all browsers to support a standard video format. Users upload 24 hours of video every minute to YouTube, so it’s important to minimize the number of video formats we support. Especially when you consider that for each format, we also provide a variety of sizes (360p, 480p, 720p, 1080p). We have been encoding YouTube videos with the H.264 codec since early 2007, which we use for both Flash Player and mobile devices like the iPhone and Android phones. This let us quickly and easily launch HTML5 playback for most videos on browsers that support H.264, such as Chrome and Safari.

Just supporting one more format will roughly double the amount of storage they need for videos. (The exact amount will vary based on the effectiveness of the compression algorithm.)

Their full list of reasons why the video tag is not ready for prime time is worth reading, and it underscores a larger point with regard to standards as well. The bottom line is that it’s easier for Adobe to iterate on Flash than it is for browser makers to iterate on HTML. Adobe can add new features and push them out in an update that works in all of the popular browsers. And it seems like it’s easier to get people to update their Flash player than it is to get people to upgrade or switch from Internet Explorer. That’s what leaves us stuck on the least common denominator when it comes to implementing things with HTML. In other words, Flash isn’t going anywhere anytime soon.

My prediction is that the trend over the next few years will be Flash on the desktop and more robust HTML5 applications for mobile platforms, thanks to the lack of Flash on iOS and strong support for HTML5 on both iOS and Android.

© 2019 rc3.org

Theme by Anders NorenUp ↑