Linked by lemur2 on Wed 9th Mar 2011 00:18 UTC
Multimedia, AV The WebM project Blog has announced an update release of the VP8 Codec SDK codenamed the "Bali" release. The Bali release was focused on making the encoder faster while continuing to improve its video quality.
Permalink for comment 465424
To read all comments associated with this story, please click here.
RE: Shouldn't the heading be...
by atsureki on Wed 9th Mar 2011 11:49 UTC in reply to "Shouldn't the heading be..."
Member since:

"Google Releases New Version of VP8 Codec", seeing as though they're the only ones who can officially do anything with their "open" project...

I think the point being made here is that no one but Google (and ultimately the acquisition it came from) ever had any say in what VP8 or WebM was going to be. Whereas h.264 was a collaborative project among many companies, VP8 was created by a single company behind closed doors, acquired by Google, released as final, and then adopted in an official capacity on the world's largest video site, also owned by Google. Given the circumstances, anyone who doesn't insist on conflating openness with freeness would have to admit that h.264 was, and likely remains, more open.

Initial reports also held that VP8 documentation was very poor (code is not documentation), though that may have changed now. This was (is?) a real problem -- a well-documented spec allows clean implementations to be created. Well-documented, actually-open specs breed superb projects like x264 and LAME, while poorly-documented, purportedly-open specs breed placeholder projects like Gnash and Mono.

I must reiterate (ad nauseam) that cost is a separate dimension from openness. They are independent variables that usually, but don't always, correlate. The latter does not depend on the former. (This, of course, does not fit into the populist all-or-nothing, good-vs.-evil model, where "open" has no real definition and is used instead simply to mean "good".)

Given that the entire WebM product, top to bottom, is, in both patent and copyright, royalty free for all use cases, there's no practical disadvantage to there being only a single implementation, codebase-wise. But if Google's documentation is just code, then Google's code will be the only code (copyright-wise), and there's no practical advantage to being a supposedly open spec (patent-wise), except for that alluring $0 price tag, because it was (and may still be) impossible to create a copyright-clean reimplementation.

Reply Parent Score: -3