The Ambiguity of "Open" and VP8 Vs. H.264 493
An anonymous reader writes "With all the talk about WebM and H.264, how the move might be a step backwards for openness, and Google's intention to add 'plugins' for IE9 and Safari to support WebM, this article attempts to clear misconceptions about the VP8 and H.264 codecs and how browsers render video. Firefox, Opera and Google rely on their own media frameworks to decode video, whereas IE9 and Safari will hand over video processing to the operating system (Windows Media Player or QuickTime), the need for the web to establish a baseline codec for encoding videos, and how the Flash player is proprietary, but implementation and usage remain royalty free."
Dear Editors (Score:5, Informative)
Re:Wow this is a bit onesided. (Score:4, Informative)
Unfortunately, that means you don't get H.264 on Linux as its a proprietary codec that requires some form of (paid) licencing.
I mean, Firefox doesn't support H.264, but Microsoft will happily provide you with the capability of playing H.264 in firefox using a driver that leverages the OS capability... as long as you're running it on Windows.
I think you're partly right though, all the codecs should be implemented as drivers (or similar) and then you are technically using the OS-provided capability, once the correct codec is installed. But its not like the OS is providing the drivers directly, you'll haver to go get them from somewhere. As WebM is free, codecs for it will be freely available for all OSs.
I guess the problem comes for those OSs that are locked down, but then you'er always on to a loser - if Apple only supports H.264 on iPhone and Microsoft only supports (say) H.265 on WP7, and neither allows you to upgrade the video support, then you will never get a video to play universally.
At least there's no excuse for not supporting WebM by all manufacturers, and any who try to give one will quickly be found out by consumers.
As an analogy - look at the non-free 'internets', Microsoft tried to lock you into MSN, and AOL tried similarly. Look where they are now.
Re:Ambiguity (Score:2, Informative)
It's not free for anyone to buy and implement.
So then ODF or C++ are not "open" either, right? One has to pay to get a copy of the spec for those technologies. Secondly, you can freely implement H.264 and release it in source form. MPEGLA has applied an exemption to source code for quite some time which is why, for example, the XviD or x264 people face no problems.
Secondly, even if you are distrbuting binary encoders/decoders you don't pay anything until you hit about 50,000 units shipped.
I can't for example buy and implement it in my app which is released under gpl
And yet there are plenty of apps released as GPL using the GPLed x264 encoder.
And just the thought that I should have to pay each time I publish a video, just because it is encoded with h.264 is insane**.
If you are streaming videos for free you have never paid royalties, and even if you are doing so for pay you have a pretty big threshold to hit before you even start paying royalties.
**This may have been postponed a few years for most people, but still.
Actually back in August the MPEGLA said they will NEVER charge royalties for freely streamed H.264 videos.
Open Standards != Open Source (Score:5, Informative)
There are open standards, and open source, and they are not the same. The IETF, for example (subject to yesterdays Birthday Article [slashdot.org]) deals with open standards. Linux, by contrast, is open source.
An open standard means that no one party controls the generation of the standard, and that the standard is openly available. Generally, open standards are developed by SDOs (Standards Defining Organizations, such as the IETF or the W3C). As a general rule "anyone" can participate in their creation (but this may require that you or your company be a member of some organization or have some other qualifications). Many open standards have patent encumbrances. Typically, SDOs seek RAND [wikipedia.org] (Reasonable and NonDiscriminatory) licensing terms; some even require a particular patent licensing policy as a condition for participation. The IETF, however, requires disclosure [ietf.org] and seeks, but does not strictly require, RAND terms. While an open standard may have some code associated with it, typically the entire point of an open standard is to allow you to go off and write your own code, generally under whatever code license you want. This is how the Internet was developed.
Open source means that the source is licensed by GPL [opensource.org] or BSD> [opensource.org] or some similar licensing. Now, generally open source means that the code is available, but in practice many open source projects are more or less closed to outside participation, and they frequently do not provide documentation sufficient to replicate what they are doing.
Re:Wow this is a bit onesided. (Score:4, Informative)
Really?
Yes, really. Before Google opened the code in May of last year, On2 was developing VP8 as a closed-source proprietary codec since 2008. H.264 on the other hand was developed by the ISO standards board and a whole host of companies in it's development. Like all ISO standards one could get access to the full spec. Such a thing was impossible for the first 2.5 years of VP8's life.
Really H.264 may have been public but I would not call it open.
Can you use the spec in your own software and publish it with out a large amount of jumping through hoops?
Sure, x264 developers have been doing so for the better part of 6 years.
It's no less open than most of the other standards which are called "open".
So no I do not feel that H.254 meets the definition of open as far as development goes.
And neither was VP8 until 7 months ago when it was a completely closed-source codec.
Re:Shocking: Apple and MS are doing the right thin (Score:5, Informative)
You're missing what the GP said - no-one's suggesting forcing anyone to buy an OS, the suggestion is to hand off video playback to the OS. In this case, the right thing to do would be to release it to a video decoding layer for Linux and then call it from Firefox/Chrome.
Cheers,
Ian
Re:Ambiguity (Score:3, Informative)
Re:Wow this is a bit onesided. (Score:5, Informative)
Can you contribute code to H.264?
The question does not make sense. It's like asking 'can you contribute code to HTML?' H.264 is a standard, not an implementation. The license of various implementations is independent of the way in which the standard was developed.
H.264 was developed jointly the ITU-T Video Coding Experts Group (VCEG) and the ISO/IEC Moving Picture Experts Group (MPEG). These groups solicited contributions from anyone. If you wanted to contribute something to the spec, you could. There was a lot of political stuff as well, with a few things being added to the spec just so that companies could get one of their patents in.
In contrast, VP8 was developed in private by On2 and dumped on the public by Google. The x.264 developers raised some issues with the spec, but were told that the format was frozen and would not be modified. Theora and Dirac are both frozen now, but they had an open development process and modified the bitstream format several times based on feedback from external groups.
So, when you are talking about the process for developing the spec, Theora, Dirac, and H.264 were all open. When you are talking about using the spec, Theora, Dirac, and VP8 are all open.
Re:Wow this is a bit onesided. (Score:3, Informative)
Re:Wow this is a bit onesided. (Score:3, Informative)
The critical difference between the two formats now is that one is royalty free and one is temporarily royalty free - in other words, we have no idea how H.264 could evolve. Maybe it'll stay royalty free forever, which would make it an interesting alternative. Maybe it will not, though, and that could be a potential disaster for video on the web - or just a thorn in the side of Google and other big video sites.
The problem, of course, is we don't know whether VP8 will stay royalty free either with the patent threats hanging over it. And with Google refusing to indemnify users of the spec, and refusing to take legal action to get a legal opinion (from a court - what are those called?) that it violates no patents, one can't be sure whether MPEG-LA's rumbling has any basis in fact.
Re:Wow this is a bit onesided. (Score:5, Informative)
You are confusing the standards with their implementations.
All of these standards are now frozen, so no one can contribute to them. H.264 was open during its design, and VP8 was closed (and suggestions for improvement were ignored when the spec and reference implementation was made available). Since they are both frozen, I'd say H.264 spec was and is more open *as a standard*.
Now, as far as implementations go, it's a different story (though still not as cut and dried as people claim). VP8/WebM is now open source, great And x264 is a GPL implementation of H.264, so it is just as "open". The difference all comes down to licensing - a number of patents are required to implement the H.264 standard, so anyone who implements it and wants to use it in a country that recognizes those patents has to pay licensing fees or risk being sued.
That last bit definitely makes VP8 more attractive to people who don't want to pay license fees. So, call it "more expensive to use", "patent encumbered", or some other more descriptive term. But just throwing around the vague concept of "open" without the real context doesn't help the discussion...