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.
Thread beginning with comment 465378
To read all comments associated with this story, please click here.
Shouldn't the heading be...
by mrhasbean on Wed 9th Mar 2011 02:59 UTC
mrhasbean
Member since:
2006-04-03

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

Reply Score: -4

RE: Shouldn't the heading be...
by lemur2 on Wed 9th Mar 2011 03:17 in reply to "Shouldn't the heading be..."
lemur2 Member since:
2007-02-17

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


The WebM project provides "reference" code, here is their license page:
http://www.webmproject.org/license/

Individual Contributor License Agreement ("Agreement"), v1.1
http://code.google.com/legal/individual-cla-v1.0.html

Software Grant and Corporate Contributor License Agreement ("Agreement"), v1.1
http://code.google.com/legal/corporate-cla-v1.0.html

Caveat: In order for outside contributions to the WebM project itself to be accepted into the WebM project codebase, Google must first assure themselves that the new code does not infringe any patents. Quite reasonably, Google wouldn't want some "helpful" outside contributer attempting any code sabotage, would they?

Other people/projects can of course do what they like within their own codebase, at their own risk, such as this project which includes WebM:
http://www.ffmpeg.org/

Edited 2011-03-09 03:33 UTC

Reply Parent Score: 5

RE: Shouldn't the heading be...
by smitty on Wed 9th Mar 2011 03:52 in reply to "Shouldn't the heading be..."
smitty Member since:
2005-10-13

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

That's kind of like saying Linux isn't open because Linus Torvalds is the only one who can do anything with it.

Reply Parent Score: 13

RE: Shouldn't the heading be...
by lemur2 on Wed 9th Mar 2011 06:01 in reply to "Shouldn't the heading be..."
lemur2 Member since:
2007-02-17

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


https://groups.google.com/a/webmproject.org/group/codec-devel/topics

Discussions

Description: For developers who are working on the core VP8 video codec.


https://groups.google.com/a/webmproject.org/groups/dir

Edited 2011-03-09 06:03 UTC

Reply Parent Score: 3

Thom_Holwerda Member since:
2005-06-29

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.


WebM: unencumbered by patents, free, Free, open source, can be implemented by anyone - wherever, whenever, however.

H264: none of the above, but instead of being developed by a single company, it was developed by a few big shots.

And somehow, H264 is more open?

Reply Parent Score: 11

lemur2 Member since:
2007-02-17

""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,
"

Up until that point, no-one would argue that VP8 was anything but closed and proprietary.

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.


No way. 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.

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.


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.

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".)


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.

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.


Whatever gives you the impression that there is only a single implementation? Already there are many. There is the reference codec, made by the WebM project, and there is ffmpeg, I believe the x264 project has another implementation of WebM, and there are a number of hardware implementations.

I think you might be getting confused by the concept of the "reference codec". This is not a single implementation, but rather it is the "gold standard" implementation. What this means is that if your decoder implementation cannot play a WebM video encoded by the reference implementation, then you are doing it wrong. By definition. Likewise if a video encoded by your implementation cannot be played by the reference implementation, then you are doing it wrong. By definition.

Get it?

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.


Sorry, but that is just your misunderstanding. Google's code is not the only code, it is merely, for the time being, until the specification documentation is sold and proven, the reference implementation against which other implementations must test themselves. Once another implementation tests correctly against the reference implementation, then it can be said to be a WebM implementation.

Here are some links:

http://blog.webmproject.org/2010/10/vp8-documentation-and-test-vect...

http://blog.webmproject.org/2010/08/ffmpeg-vp8-decoder-implementati...

Google's implementation is called libvpx.
ffmpeg implementation is called ffvp8.
"The ffvp8 implementation decodes even faster than the WebM Project reference implementation (libvpx), and we congratulate the FFmpeg team on their achievement. It illustrates why we open-sourced VP8, and why we believe the pace of innovation in open web video technology will accelerate."

http://www.osnews.com/story/23598/FFMpeg_s_ffvp8_the_Fastest_VP8_
Just after 3 weeks of the binary compatible vp8 decoder release, the FFMpeg team still impressing us but this time with a new benchmark of their own vp8 decoder. The new ffvp8 decoder written independently using pre-existent FFMpeg code-base is now the fastest vp8 decoder with margins going more than 30% faster than Google's official codec specially on 64bit machines.


The in-work specification:
http://www.webmproject.org/code/specs/

Hope this helps.

Edited 2011-03-09 12:59 UTC

Reply Parent Score: 3

WereCatf Member since:
2006-02-15

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.


Indeed, community didn't. Now they do.

Whereas h.264 was a collaborative project among many companies


Indeed, big, large corporations had a say. Community however didn't. And they still don't.

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.


So, your argument is that there needs to be more than 1 entity when creating the initial version of something for it to be open, regardless of how many entities can freely modify and study it after the inception of the initial version?

Initial reports also held that VP8 documentation was very poor


News at eleven: a new project doesn't yet have full and complete documentation, people to barricades.


because it was (and may still be) impossible to create a copyright-clean reimplementation.


There is no such a thing as copyright-clean reimplementation, unless released as public domain. Being copyrighted isn't even a problem as VP8/Webm is released under a license that waives Google's rights to it. Ergo, your point is moot.

Oh well, nice trolling attempt mate, with enough practice you might make a true alpha troll when you grow big! Just hang in tight and keep your head high!

Reply Parent Score: 7