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

H.264 / MPEG-4 AVC
Pros:
-Has open source implementations of encoders and decoders.


This is not a "pro". Open source implementations of encoders and decoders simply ignore the fact that users in some countries require a license. It is left up to said users to get that license. People (especially in the US) could be caught unawares by this, and have to pay fines.

-The audio, video, subtitling, and container specs is open and well documented


"Well documented" is true, "open" is not, because to be "open" requires that implementing the specification is royalty-free. This is not the case with H.264.

Cons:
-Has parts patented by a vast number of companies, so a single holding company for the patent load was created.
-Container and audio codecs were both developed by Apple, the spec audio is AAC, and the spec container is mp4, which is essentially a Quicktime MOV container.
-At some point in the near future, royalty payments will have to be made to the holding company by someone.


A large number of cons have been missed out here. The most obvious one is that h.264 development costs have been recouped ages ago, and so now all of the money that royalties continue to bring in is pure cream, and a dead-weight loss on the economy. The second most serious con is the chilling effect on innovation that a heavily-patented codec has.

VP8/WebM
Pros:
-Has multiple free and open source implementations.
-Use VP8 video, Vorbis Audio, and Makrosta container, which are all free and open source. MKV and Vorbis have well defined open specs


VP8 has a well-defined spec ... it is just not proven for now because it is new. The 105-page bitstream spec is here:
http://www.webmproject.org/media/pdf/vp8-bitstream.pdf

That is well defined, the only problem is that it may have inaccuracies. For now, if any inaccuracy is found in the spec compared to what the WebM Project reference codec produces, then the spec will be changed to correct the discrepancy rather than the refernce codec. This is needed because the spec is new, and may still contain inaccuracies, and there is a need to preserve the validity of existing encoded files rather that freeze the spec right now.

Cons:
-The final standard of VP8 is defined by code, not a well defined spec. Essentially, as WebM evolves, movies will compatible with WebM-git-DATETIME, like HTML is moving to be.


Nope. The bitstream format, as instanced within the existing corpus of WebM files, and defined as the bitstream format produced by the webM Project reference code, is frozen. That is the webM format.

FTA:
http://blog.webmproject.org/2011/03/vp8-codec-sdk-bali-released.htm...
Today we're making available "Bali," our second named release of the VP8 Codec SDK (libvpx). Note that the VP8 format definition has not changed, only the SDK.


The only thing that is not frozen is the specification document for that format:
http://www.webmproject.org/media/pdf/vp8-bitstream.pdf
... because it is 105 pages of complex and realtively new text, and it may still contain divergences from the frozen bitstream format it is meant to describe. Once those have been shaken out of the specification, it will become the formal specification, and this document will then be frozen also.

-While open source, Google "holds the keys to the cathedral," so there is not that much community involvement in the central defining project.


Nope. There is a pretty decent community and building momentum behind WebM, and a number of independent implementations of it. Where do you get this guff from, exactly?

-Probably uses some H.264 patents (FFMPEG reuses a large amount of their H.264 decoding functions in their implementation of WebM decoder.)


Probably not. There is a great deal of "common ground" video compression technology that has prior art (and is therefore not patentable by anyone), or for which applicable patents have expired. Piror to buying On2, as part of due diligence Google undertook a lengthy and what they describe as thourough patent investigation of VP8, and they gave it a clean bill of health.

-TO MY KNOWLEDGE, NO DEFINED SUPPORT FOR SUBTITLES ( http://www.webmproject.org/code/specs/container/#demuxer_and_muxer_..... )


Full quote from link: "WHATWG / W3C RFC will release guidance on subtitles and other overlays in HTML5 <video> in the near future. WebM intends to follow that guidance".

So, when the subtitles and other overlays requirements of HTML5 are settled, WebM will support them. There is plenty of capacity in underlying the format structure to do exactly that. This is a "pro", not a "con".

PS: despite repeated attempts to characterise it otherwise, WebM is both free as in gratis (no charge) and free as in libre (no royalties).

Edited 2011-03-10 04:24 UTC

Reply Parent Score: 3

ruinevil Member since:
2009-01-08

Has open source implementations of encoders and decoders.

This is not a "pro". Open source implementations of encoders and decoders simply ignore the fact that users in some countries require a license. It is left up to said users to get that license. People (especially in the US) could be caught unawares by this, and have to pay fines.


Source code is speech, which is supposedly free in "civilized" nations.

Binaries on the other hand...

-The audio, video, subtitling, and container specs is open and well documented


"Well documented" is true, "open" is not, because to be "open" requires that implementing the specification is royalty-free. This is not the case with H.264.


Only in Europe, which is also the only place your definition of libre makes sense.

Edited 2011-03-10 05:30 UTC

Reply Parent Score: 1

lemur2 Member since:
2007-02-17

"Has open source implementations of encoders and decoders. This is not a "pro". Open source implementations of encoders and decoders simply ignore the fact that users in some countries require a license. It is left up to said users to get that license. People (especially in the US) could be caught unawares by this, and have to pay fines.
Source code is speech, which is supposedly free in "civilized" nations. Binaries on the other hand... "

This does not rebut the point made.

""Well documented" is true, "open" is not, because to be "open" requires that implementing the specification is royalty-free. This is not the case with H.264.
Only in Europe, which is also the only place your definition of libre makes sense. "

This does not rebut the point made.

Reply Parent Score: 2