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 465424
To view parent comment, click here.
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..."
atsureki
Member since:
2006-03-12

"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

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

TheGZeus Member since:
2010-05-19

Exactly.

How anyone can be so out-of-touch and not be dropped-on-the-head stupid amazes me.

They were able to form sentences, punctuate things correctly, spell properly, and overall form things into cohesive paragraphs.

Yet they somehow think "Many companies is more open than one. Period."

*head implodes*

Reply Parent Score: 8

atsureki Member since:
2006-03-12

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?


Greater than or equal to, yes. Open is a separate dimension from free and/or Free.

And WebM is not patent-free, though it is, as you say, unencumbered, in the sense that it is licensed Freely for free.

But being open, anyone can indeed implement h.264, wherever and whenever, but the "however" is a problem - a freeness problem. Depending on implementation, royalties may be levied.

But that kind of openness, despite its shortage of Freedom, is beneficial to the Web, because it solves the single vendor problem both in theory and in the real world. No one is stuck going to MPEG-LA simply to make it work.

In the absence of adequate specs, this is not the case with WebM or Flash. I believe you personally have brought up several times during this whole saga that Flash is a supposedly open spec as well. But in practice, for Flash to run on any computer requires huge cooperative investment between Adobe and the platform developer. Apple takes some heat for not playing along to get support on iOS, but the Xoom, for all its enthusiasm about Flash, can't run it either. Working implementations of Flash outside of mainstream PCs simply don't exist, with or without Adobe's involvement. That's a hell of a single vendor problem, and really calls into question even the freeness of Flash. It takes a tremendous outlay of resources to get it working, and that cost trickles down.

Whether the same problem will arise with WebM remains to be seen, as development in that area is currently obscured by h.264 + native app solutions on smartphones.

Bottom line, I don't believe giving something away is inherently good, nor is charging for something inherently evil, and when you factor out openness, that's essentially what we're left with.

Reply Parent Score: 3

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

atsureki Member since:
2006-03-12

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.

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.

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.

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

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.

Reply Parent Score: 2

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