Slashdot Mirror
Ars Thinks Google Takes a Step Backwards For Openness
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.'"
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.