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 465493
To read all comments associated with this story, please click here.
lemur2
Member since:
2007-02-17

"WebM was opened by Google after Google's acquisition of On2, and from that point onwards the entire nature of VP8 was changed. No longer was it closed, proprietary, and developed by a single entity, from that point on it became open and community-developed.
Google never accepted community input on the binary spec for VP8 files, so while everyone is invited to contribute to the programs that create and decode it, it's a stretch to say that VP8 itself is community developed. "

Do you mean the container format for WebM? It is essentially matroska ... which indeed was community developed.

http://www.matroska.org/news/webm-matroska.html

As for the actual encoded bitstream format, that is necessarily set by the imperative to avoid patents held by other parties. There is no room for community input there, it is what it had to be.

While I think that was the most practical way to go about it, I don't suffer any illusions that VP8 is OSS, born and raised. The basic issue is that h.264 is and was always intended to be open, which is why the documentation is mature, while VP8 was intended to be commercial until it changed management, which is why the documentation isn't. It's not a terribly important point, but there it sits.


Meh. The specification documents exist, they are just not proven. Warning: PDF
http://www.webmproject.org/media/pdf/vp8-bitstream.pdf

The WebM project code is not really the documentation, the code is the "gold standard" test. In the event of a conflict between the specification document and the bitstream format produced by the code, at this time the code is the final arbiter, and the documentation will be corrected to reflect what the code produces. After a while, this will switch around the other way, and what the specification says will become the final arbiter. I'm not sure when this is expected to happen, but whenever it is the main point is that it is not really a huge issue at all that some parties are trying to make it out to be.

"No problem with this, and a specification is indeed being written and refined. However, you cannot expect a full-blown correct specification to spring up out of thin air, it has to be developed, and this takes time.
My concerns with source-as-doc were more or less allayed by a quick visit to Wikipedia, which states that Google's VP8 code is licensed under BSD, so copyrighted code snippets should be a non-issue. But if, for example, there were no complete documentation on the ext2 file system that did not contain GPLed code samples, I could not say that ext2 is an open spec, because a copyright-clean reimplementation would be impossible. So yes, if the current documentation is messy only in a presentational sense, that's understandable, but I had been concerned that it was messy in a legal sense. "

No, the project is fully open to community participation. Anything you might be hearing to the contrary is merely astroturfing by vested interests trying to rake up some mud somehow.

" On that topic, your examples of outside implementations were quite informative. It does sound as if VP8 should be able to grow very quickly (very much unlike Flash, as I was discussing with Thom above). [q]No argument here ... openness has nothing to do with cost. It is not because h264 costs something that it is not open, but rather it is that h264 is not open for anyone to implement that makes it not open.
It's not open for anyone to implement... free of cost. Either cost means it's not open, or it doesn't. I say it doesn't. You seem to have said both. "

No, to be truly "open" means that the author of an implementation must be able to pass the right to change/re-implement the work on to downstream recipients. This characteristic emphatically applies to both the BSD-style open licenses and the copyleft style open licenses. Even if one author purchases a license to implement H264 from MPEG LA, the author of a work CANNOT pass on that right to downstream recipients of his/her work.

Hence there can be no community participation in h264. Ergo, h264 is not open. One cannot correcly use open licenses such as BSD or GPL for one's implementation of it.

Reply Parent Score: 4