Is the removal of H.264 from Chrome a step backward for openness?

In a lengthy article at Ars Technica, Peter Bright argues that removing support for a closed standard from Chrome is a step backward for openness.

I disagree strongly with this assertion, and will try to somewhat briefly explain why, and what's wrong with the arguments put forth in the article. …

1. "H.264 is an open standard"

Unfortunately, H.264 is patent-encumbered, and you need to pay money to use it. As per the W3C patent policy, this is incompatible with the definition of an open standard, particularly on the web. By the very definition of "open", H.264 cannot possibly be open, because it cannot be used unless you pay up.

2. "VP8 is not an open standard"

That is actually correct. VP8 is a technology with a specification, not a standard. However, Google has granted anyone the right to use it, and makes no claims about patents to restrict its royalty-free use. This means that VP8 is actually a good candidate for being turned into a proper open web standard.

3. "H.264 is free to use under certain circumstances"

Remember that H.264 still costs money. And even if products with a tiny user base may not have to pay right away, you still have to open your wallet at some point if you aim to do something on the web. The MPEG-LA has clevery provided the first shot for "free". Once you are hooked, they can start charging you.

It's called bait and switch.

4. "H.264 support isn't mandated in HTML5"

But it would become another closed de facto standard, just like IE6. And we all remember the damage that did to the web.

5. "Google bundles Flash, so it is being hypocritical"

This is comparing apples and oranges. Flash is a plugin, which Google chose to bundle because there is a lot of Flash content out there. On the other hand, H.264 would be part of the browser itself, and not a mere plugin.

One important thing to keep in mind is that Flash is already ubiquitous. If you want to do any kind of video on the web, you don't have a choice. Flash is needed (and that's assuming that you want to reach more than the comparatively tiny iOS user base). However, the "battle" over HTML5 video is still raging. There is no clear winner, but with Google dropping the closed H.264, it is much more likely that an open format will prevail in the end.

So when Google keeps bundling the Flash plugin, it makes perfect sense. Most video content on the web uses Flash, and that allows Google to continue to support just about all online video until native video support gains a proper foothold. There is no hypocrisy involved here, just pragmatism.

In the end, the question of Google's bundling of Flash is a red herring which takes away the focus from the real issue: Whether native video support in browsers is based on open or closed technologies.

Update: Some will raise iOS as a counter-argument, but it does not hold water. There's a reason why a lot of iDevice owners are resorting to pay for even poor quality video transcoding soluions on the iOS, and that is that they can't access most video sites. The reason iOS gets away with H.264 is basically that YouTube (Google's video service, and the biggest and most important video service on the web) supports it. The vast majority of video sites still require Flash. I understand that some major Apple fans are worried about Google's push for WebM, though. Losing YouTube support would be a major blow to Apple.

6. "H.264 is everywhere, and the web does not exist in a vacuum"

Just because a format is widespread offline does not mean that it is suitable for use on the web. Since the web requires open standards, H.264 is not suitable as the primary format for video on the web, by definition.

And the argument that H.264 is everywhere and everyone will have to handle it does not hold much water, in my opinion. Sites like YouTube will convert and compress videos anyway, so very few are publishing raw H.264 videos straight from your camera, and on to the web.

In other words: The processing will always be there, and instead of re-processing to a slightly more compressed H.264 file for online play, it can be converted to an open format.

7. "H.264 can be used in both Flash and through HTML5 video, ensuring a smooth transition"

As already explained, videos are typically re-encoded or processed in some way anyway. Indeed, most sites offer different bandwidth options and video sizes. They are already converting the video! They could simply convert it to an open format instead.

8. "Firefox users would be able to view H.264 content using Microsoft's plugin"

Notice the word "plugin". It means that we're basically removing HTML5 video, and returning to plugins. All the benefits of native video disappear just like that (and it's only available on Windows 7). On the other hand, I believe it's possible to fairly easily add support for WebM to both Safari and IE by adding it to the list of codecs supported by the system.

9. "The market share of browsers that support H.264 exceeds WebM capable browsers"

Google's online advertising monopoly is working on overdrive to ensure that won't happen. If I am not mistaken, the share of open standards based browsers is growing at the expense of Internet Explorer. Although browser market share is impossible to measure reliably, most of the data seems to confirm that.

10. "Google's decision gives users fewer choices"

Now we are starting get to the core of the issue. And sadly, it is H.264 which takes away choice. While WebM maintains the web as an open platform, H.264 is a closed standard owned by an industry cartel which would ruthlessly stamp out any attempts at getting alternatives up and running.

I also find it puzzling that Google is being accused of giving users fewer choices, while Microsoft and Apple aren't even mentioned. They refuse to support WebM, after all.

11. "VP8 is Google-controlled and proprietary"

I'm not sure if this is the actual claim, but it is my interpretation of it. And it is an incorrect claim. Read the WebM license page for more information. WebM is an open-source project sponsored by Google, and it is freely available because of the license.

The bottom line:

The article aims to show that Google's move is a step backwards for openness. In reality, the article brings up all sorts of things that are not really relevant to this question at all. This, I think, clouds the debate, because the question of openness is actually the most important one!

We can easily test what causes more openness in the context of the web:

  • H.264 is a patent-encumbered and therefore "closed" standard. It is incompatible with the W3C patent policy for an open web. Therefore, promoting H.264 as the primary format for HTML5 video is the opposite of promoting openness.
  • On the other hand, WebM is very much in the spirit of the W3C patent policy. Google grants anyone royalty-free access to the technology. Since WebM is open, it promotes an open web.

Conclusion: By rejecting that which closes the web, while at the same time promoting open technologies, Google is contributing to a more open web, contrary to the claims in the article.

Advertisements

120 thoughts on “Is the removal of H.264 from Chrome a step backward for openness?

  1. The H.264 patent pool is fat and greedy, but it has one of the best blueprints ever released by a committee. H.264 is like Tesla, carefully defining and documenting before trying to build. This makes designing compliant codecs from scratch….trivial.VP8 is more like an Edison design….keep building until it works, then copy exact. Draw a blueprint from the working model. Since VP8 was not blueprinted before they created it, the codec must first be researched to discover HOW it works. It also does not help that certain lift-ads and other traits were modified in haste, to avoid some of the H.264 patents.WebM is a minimal, somewhat tidy clone of Matroska. Biggest problem is that WebM does not support subtitles or embedded unicode webfonts.

  2. Originally posted by hellspork:

    Biggest problem is that WebM does not support subtitles or embedded unicode webfonts.

    That isn't needed. It should be handled outside the video container. Browsers should support it like they support CSS to style HTML.

  3. Originally posted by andygeerlings:

    O rly?? Please go ahead and show me that. And then especially the part excluding the "THIS implementation" limitation to that "released for free with an irrevocable license" you so happily ignored. And I'd just love to see the part where Google relinguishes all rights to their VP8 patents, their rights to solumnly change the VP8 spec and their rights to solumnly create successors to it. Please bring it on.Oh… wait…

    Why don't you read the license and FAQ for yourself?"Google hereby grants to you a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license"The only "exception" is if you sue someone over patents you believe WebM might be violating.Originally posted by andygeerlings:

    Since when did your definition of an Open Standard get picked above all other, and become the standard definition the whole web shoud heed?

    It isn't my definition. It's the definition of the likes of the W3C, the EU, and even Microsoft.Originally posted by andygeerlings:

    No. They are not. They may be part of the flock of sheep that actually believe Commercial Company Google is giving away their stuff for free and is going to benevolently want nothing in return for it.

    You are extremely confused, it seems. Google's reasons for doing this has no relevance to whether the action is good or bad.

    But to be honest I don't think that's the case actually. What I think is that they simply don't want H.264 to become the defacto standard, and grab any remotely viable alternative offered to try and stop that from happening.

    So? That doesn't change the fact that open web advocates have universally applauded Google's move, and this includes direct competitors. It doesn't matter what Google's intentions are. What matters is the actual result of what they are doing.Originally posted by andygeerlings:

    As stated before and also ignored by you: H.264 is NOT going to go away for a very long time.

    H264 only needs to go away from the web. The problem isn't that h264 exists. It's great for other uses. But it is incompatible with an open web. It can never turn into an open web standards (unless the MPEG-LA is dissolved and gives it away for free).Originally posted by andygeerlings:

    You may not like that it's not fully free, but accepting that: 1.) things you do not like are sometimes for the greater good, and 2.) that human-produced things that are for the greater good are usually not 100% free is part of growing up. Why is it is so difficult grasping this exceptionally simple concept?

    You are the one who doesn't get the concept. H264 is incompatible with an open web. Keeping it away from the web leads to a greater good: a continued open web.Originally posted by andygeerlings:

    And you think that's a good thing right? Why am I not surprised. Every idiot can create a fork at will, and that's just peachy right?

    So you finally admit that WebM is that open? But now it's too open!

    Only problem is that it's a disaster when you are trying to maintain a standard. When you are defining a standard you specifficly do NOT want that every idiot with an opinion can go ahead and create his own fork, because you can go sit and wait for compatibility issues.

    WebM is not a standard. It can easily be standardized, though. The W3C could either have the WebM project submit it for standardization, or simply create their own fork and standardize that. No problems whatsoever. But now your tune has changed from "WebM is closed" to "WebM being open is bad, m'kay"!Originally posted by andygeerlings:

    No, you keep dodging mine; you happily skipped just about anything that really matters

    Such as?Originally posted by andygeerlings:

    Besides that you keep hiding behind the opinions of your "Open Web Advocate"-prophets/priests, supporting your "Open Source"-religion and their "all standards should be 100% free, because only 100% free is good"-dogmas.

    The open web has got nothing to do with open source code. The open web is about open standards, and yes, open standards must be royalty-free. This is not a dogma, but a fundamental criterion for the existence of the open web.

    This is – besides the constant use of the straw-man – also a logical fallacy btw, called the Argument from Authority:

    No, not at all. When I pointed out that open web advocates have universally applauded the move, it was in response to your paranoid delusional fantasies about Google. I mean, you claim to know better than lawyers from Mozilla, Opera and other well known open web advocates!The point is that you are claiming that this is just an evil plot by Google to do something really nasty, and there's some trap somewhere. Open web advocates disagree. They don't care what Google's intentions are, but look at the actual results of what Google did. Your paranoid delusions are just FUD.Originally posted by andygeerlings:

    I don't share your beliefsystem nor your assumptions on OS/OSS

    I realize what this is all about now. You don't even know the difference between open source and open standards!That's pretty amusing.

  4. Originally posted by andygeerlings:

    In case you don't understand: I do not agree with your definition. And I'm not particularly alone in that.

    Looks like you're alone.Originally posted by webrider:

    Embedded audio is not needed.

    Already embedded, but you can apply to the Google.Originally posted by hellspork:

    The .ogg encoder is still too weak in most implementations, resulting in unacceptable audio quality in many cases….However they need solid and varied encoders

    That sounds like total nonsense. ogg has best sound at 128-256 bitrates and simply has no bad encoders. mp3 has many encoders (most of them are bad) and many quality controls ("q" parameter. Please note, ogg uses always best quality).

  5. Originally posted by Slamdex:

    Originally posted by hellspork:

    Biggest problem is that WebM does not support subtitles or embedded unicode webfonts.

    That isn't needed. It should be handled outside the video container. Browsers should support it like they support CSS to style HTML.

    This is already possible with VideoSub and the <track> tag. Browsers should indeed support it. It's also common to use a similar method in some video players for the desktop.
    Originally posted by webrider:

    Embedded audio is not needed. It should be handled outside the video container.

    Although it's easy to do already, you're not making any sense.

  6. Originally posted by webrider:

    oops, i forgot to include the [ sarcasm ] tag in prev. post, sry

    I'm sure most of us understood your sarcasm. But it was pointless as it's already common to have subtitles in a separate file, which is why you're not making any sense.What I did not notice is that I just took the bait. This has nothing to do with the openness of WebM and the openness of the web, which is what we're supposed to discuss in the comments of this blog post. Let's discuss the technical aspects of WebM vs. H.264 elsewhere.

  7. oops, i forgot to include the [ sarcasm ] tag in prev. post, sryOriginally posted by hellspork:

    PsyOpts […]WebM may be better than h.264 in the case of low-res/low-bandwidth video streams

    For sure H.264 can easily beat VP8 in this segment. But much more interesting that even Theora 1.2 (Ptalarbvorm) looks slightly better than VP8. Btw theora encoding is 4 or 5 times faster.

  8. Including subtitles with embedded fonts, ensures the original footage is not compromised. It also wraps all data into one container, which improves management and transport. The MKV container is already capable of such uniform presentation. The notion that WebM was copied from MKV but did not support subtitles, is an insult. Chapter support could also have been nice, but that is much less important.You may have noted that the WebM team's roadmap includes the "fansubbing" community of users (college students aiming to become media professionals). So perhaps there is hope for the container to offer text overlay features.Asires:

    The WebM version has an exceptionally poor .ogg recode. I have a standalone copy of Opera that is opted-in for html5, and the difference in quality is appalling. Ogg's potential is excellent, but there ARE bad encoders just like it's possible to make FLAC sound terrible.WebRider: Make no mistakes…x264 can readily compete against WebM on this front. But most h.264 encoders are terrible in this arena. Please recall that I am talking about VERY low bitrates. Theora looks better when using PsyOpts, worse without them. VP8's frame analysis logic is not efficient, so even a very fast PC will struggle to encode 1080p in realtime. x264 High Profile can drive 1080p at the magical 120-150fps required for stereoscopic 3D capture, it is nearly as fast as the lossier XviD.

  9. Originally posted by hellspork:

    Including subtitles with embedded fonts, ensures the original footage is not compromised. It also wraps all data into one container, which improves management and transport. The MKV container is already capable of such uniform presentation. The notion that WebM was copied from MKV but did not support subtitles, is an insult.

    I don't know why you think it's an insult. Subtitles are added outside the video, which makes sense. It's added through the web page. This is video on the web. The original footage isn't less or more compromised whether you include subs or not.

  10. Video on the web needs to be portable and approachable. Requiring additional scripting on the page and the download of two separate files adds complexity that would have been unnecessary with a SLIGHTLY more complex container.

  11. Apparently the mkv group is waiting for the subtitle format (vtt or whatever it's called now) to be finalized before updating the webm container to hold subtitles, but they fully intend for subtitles to be included in video files.

  12. Originally posted by hellspork:

    Video on the web needs to be portable and approachable. Requiring additional scripting on the page and the download of two separate files adds complexity that would have been unnecessary with a SLIGHTLY more complex container.

    Video is portable and approachable, especially with separate subtitles because they can be manipulated separately.Your "insult" comment was simply uncalled for. You may disagree with the way subtitles are supported, but that doesn't give you the right to post something like that.

  13. Yeah I just learned that while watching a video of Bruce Lawson giving a presentation and he mentioned it. It used to be called webSRT but now it's webVTT: http://www.whatwg.org/specs/web-apps/current-work/webvtt.htmlI don't know if fansubbers would ever go to webm though. They tend to prefer either quality or speed (and h.264 with the x264 encoder wins at both of those). Additionally they like to use styled subs with either .ssa or .ass subtitle formats that allow complex subtitle typesetting with animation, fonts, and a bunch of other crazy stuff. I suppose they could do some of it with CSS but I'm not sure and it's probably a lot more difficult than with software like aegisub.

  14. Now, Dillon's comment was most informative. This is the sort of information I'd been hunting for.Chris, a video container can pack many different subtitle kits with a minimal increase in file size. Additional subtitles can be muxed in, or will display if the file is added to the same directory as the video. Unfortunately, operating systems do not stack videos with subtitles in the same fashion as HTML resource files are associated with .html documents. Management is messy, and the folder quickly becomes clogged.I think fansubbers and other small nonprofit broadcaster will adopt webm when these technical challenges are met.

  15. Yes, that is a definite concern and I do not expect the working group to QC such extensive features. But simple things like embedded captions etc would be nice. And low-bitrate webm codings may plausibly be used in a "watch online" format.

  16. Isn't WebM a format for the web? Do fansubbers view videos on the web? I thought they downloaded the videos, in which case they will be using some other format than WebM anyway (seeing as WebM is for use on the web).

  17. It's partly a factor of advertising revenue. Many text/comic translators want the reader to use their online reader, because it generates ad-impressions for them. Subbers have approached the idea of watching online for similar reasons, but there are technical thresholds which must be met. If they could use WebM and the Video tag, it would be much easier to distribute.

  18. Originally posted by JamesHT:

    Currently this means I have to encode videos at least 2 different ways – h.264 and .ogv. I still have to wrap video in flash for other browsers, and lately I've been encoding in .flv and .webm as well.

    The need to transcode to .ogv will go away very soon. When Firefox 4.0 is out (scheduled for next month), all browsers that support open video formats will support WebM. And FLV – why? FLV has been deprecated for ages. Even Adobe recommends using MP4/H.264/AAC for Flash.

Comments are closed.