Ars Thinks Google Takes a Step Backwards For Openness 663
An anonymous reader writes "Over at Ars Technica, Peter (not so) Bright gives a long-winded four pages of FUD about how Chrome dropping support for H.264 is a slight against openness. 'The promise of HTML5's video tag was a simple one: to allow web pages to contain embedded video without the need for plugins. With the decision to remove support for the widespread H.264 codec from future versions of Chrome, Google has undermined this widely-anticipated feature. The company is claiming that it wants to support "open codecs" instead, and so from now on will support only two formats: its own WebM codec, and Theora. ... The reason Google has given for this change is that WebM (which pairs VP8 video with Vorbis audio) and Theora are "open codecs" and H.264 apparently isn't. ... H.264 is unambiguously open.'"
Re:Putting the snideness of the summary aside... (Score:4, Interesting)
Yeah, I agree. It's strange to support "freedom" by diminishing choices.
By being so quick to take sides in these arguments, I think some people miss that this just *is* a problem. Everyone wants to say, "why don't we just do this?" and seem oblivious to the problems that might be caused. h264 is open, but it also has patent issues, but on the other hand it's widely used and widely supported. Flash isn't going away until content owners settle on some kind of DRM for HTML5 streaming. WebM is new, isn't widely supported yet, and may (or may not) have some patent issues down the line.
And what's a bit silly is that everyone wants to talk about this like it's a technical issue-- an issue of which format is "better". It's really a confluence of technical, legal, economic, and social issues, and I don't think it'll be wrapped up without some drastic changes in how we deal with content.
Re:Putting the snideness of the summary aside... (Score:4, Interesting)
That's all fine and well for Google and their endless buckets of cash, but what about other companies, or importantly startups who want to get into the game.
H.264 is a standard; not a de-facto, or "industry" standard, but one adopted by an international standards body with wide representation. It publishes specs. If you build a part to do something with H.264 video, as long as it conforms to spec, it will work with others' products. You know, like the way any unlocked GSM phone works on any GSM network that operates on the same frequency band. It's ideal for startups, because you only need expertise in your own narrow product field, not in the entire much broader space. To build say an innovative silicon decoder you don't need to know how to build an encoder, because the elementary stream conforms to the standard. You don't need to know whether it came off a disc or ethernet. And while you occasionally run into interop issues this is positively nothing compared to the alternative of having inhouse expertise for *everything*. Not to mention the cost of dealing with some hacker who thinks they're doing something smart in the encoder, blowing up your taped-out decoder you've sent off to fab!
Compared to other costs, licensing fees are fairly trivial. $100k doesn't even buy a competent engineer for a year.
Re:Putting the snideness of the summary aside... (Score:5, Interesting)
H.264 is a standard; not a de-facto, or "industry" standard, but one adopted by an international standards body with wide representation. It publishes specs. If you build a part to do something with H.264 video, as long as it conforms to spec, it will work with others' products.
... ?? Your point is? I believe what you're referring to is a documented format. Any such documented audio/video encoding format that conforms to its specification can be read by any video decoder that conforms to the same respective spec.
In fact: Data from any type of encoder conforming to a spec can be read it's corresponding decoder! ( GnuZip reads WinZipped files... )
This means, Theora, VP8, MP4, MP3, and even Windows Media Audio (WMA) and Win Media Audio (WMV) have multiple implementations -- they are all "open standards" in that anyone can create a complying implementation via the format's documentation.
You know, like the way any unlocked GSM phone works on any GSM network that operates on the same frequency band. [H.264 is] ideal for startups, because you only need expertise in your own narrow product field, not in the entire much broader space.
The same can be said for VP8, Windows Media, MP3, Theora, Vorbis, and virtually every existing codec known to man.
The difference is that unlike H.264 "standards boards", VP8 and Theora do not pursue license fees, and claim no patents.
Startups would be more wise to go with a codec that is not patent encumbered, and costs $0.00 to license... Not H.264.
To build say an innovative silicon decoder you don't need to know how to build an encoder, [blah blah blah blah blah blah]
Documented file formats enable multiple or partial implementations of codecs... Self evident really, no need to iterate every type of implementation that can exist or re-repeat yourself, we get it.
And while you occasionally run into interop issues this is positively nothing compared to the alternative of having inhouse expertise for *everything*.
Yes, it's quite foolish to build an inhouse codec, but H.264 isn't the only codec out there.
Hell, you can create a wrapper that allows an interface to external codec libraries in order to support all of the codecs I've mentioned above... However, if you ship a product with a patented encumbered codec, you must pay the licensing fee to MS, MPEG-LA, or other such patent holders.
The license fee for VP8, and Vorbis is $0.00.
Compared to other costs, licensing fees are fairly trivial. $100k doesn't even buy a competent engineer for a year.
Yep, and for absolutely NO FEE you can just use Theora/Vorbis, or VP8. $100k is 10000000% more than $1, and infinity% more than $0.
Fact is, Chrome is a derivative of Chromium -- If Google goes with H.264 then Chormium would have to have H.264 support, or else Google has to maintain a separate video branch in Chrome.
Unfortunately, If I compile Chromium Source Code that has H.264 support I'm forbidden from distributing the binaries unless I pay the licensing fees.
From a web browser "start-up" perspective, it's best for Google NOT to burden the "start-up" with licensing fees or maintaining it's own incompatible video branch if the "start-up" were to fork Chromium.
Thus, Chromium currently has no H.264 support (in favor of VP8 and Theora/Vorbis), and Chrome is simply adopting the same behavior as upstream.
Additionally: I could have just s/ H.264 / WMV / in your post, and made the reductio ad absurdum argument for Microsoft's proprietary format -- but my heart wouldn't be in it.
Re:So, h264 is (Score:3, Interesting)
Also, the patents behind VP8 have been released, irrevocably, to the public.
He isnt being informative. He is being dishonest.
.. then at least one entity will have its license to use VP8 revoked.. and in the event that Google is found to be infringing, EVERYONE will have their license revoked.
The specific text of Googles license reads "Google hereby grants to you a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell..."
Emphasis mine.
The exception reads "If you or your agent or exclusive licensee institute or order or agree to the institution of patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that this implementation of VP8 or any code incorporated within this implementation of VP8 constitutes direct or contributory patent infringement, or inducement of patent infringement, then any patent rights granted to you under this License for this implementation of VP8 shall terminate as of the date such litigation is filed."
In other words, in the event of any patent litigation regarding VP8