Mozilla Considers H264 After WebM Fails To Gain Traction 182
HerculesMO writes with word that "Looks as though Mozilla is considering using H264, one step closer to unification of a single protocol for video encoding. It's a big deal for HTML5 traction, but it still leaves Google holding onto WebM." The article, though a bit harsh on Ogg Theora, offers an interesting look at the way standards are chosen (and adopted by the browser makers).
Kind of serves them right really (Score:5, Insightful)
Mozilla wouldn't even have to taint itself by supporting it. Just hook the video tag to the media framework in the host OS - Quicktime, DirectShow, gstreamer etc. and invoke the default h264 codec if its present and suitable or point the user at a way to obtain it if it isn't. They could still ship Theora with the browser if they wanted.
The justification for WebM (Score:5, Insightful)
The justification for WebM is that it would allow people to freely share videos using your own infrastructure without charge and without additional cost.
It's not about the consequence for the consumer, it's about the chilling effect it has on free culture.
It has HUGE consequences. Mozilla knew that, that's why they tried to play hardball.
Re:H.264 is a terrible solution (Score:5, Insightful)
The article is an Apple troll.
Re:Kind of serves them right really (Score:5, Insightful)
h264 is ubquitous. It's really stupid to deny the reality that people want to use it because of politics which is what it boils down to.
The aren't denying reality, they were trying to shape it.
And I'm glad they tried, even if they didn't win this time.
Re:open standard yes, open source no. (Score:5, Insightful)
The notion that H.264 is not "free" isn't a result of a development methodology, it's because people think that somehow patents make it that way, despite the fact that the software authors have no choice in the matter.
H.264 is not free-as-in-freedom nor free-as-in-beer, and patents are the reason. IP amounts to copyright, trade secrets and patents, but the first two don't apply here. It's a patent issue.
Re:open standard yes, open source no. (Score:4, Insightful)
Parts of MPEG-2 (AAC, for one) were not published until 1997, and some hardware codec chips might have patents that were filed much later. Similarly, there may be patents on algorithm optimizations that were filed much later, e.g. patents on ways to use pixel shaders to perform some part of the MPEG-2 decoding process. So although the format will ostensibly become free and clear of patents four years from now in its barest reference implementation, that does not necessarily mean that you can't get sued if you write your own implementation. :-)
Re:Alternative? (Score:3, Insightful)
Yes, it really is that hard. I've written some of these things. It's not that the knowledge is inaccessible: most of the concepts involved are covered in a good undergrad discrete math course. It's just that 99.999% of the programmers out there either don't take the course, or forget what was taught the moment after the final is handed in.
Look at the sorry state of linux audio, for one. Layer upon layer, library upon library, everyone's an architect slinging metaphors and objects around but very few actually know how to write a good sample-rate conversion function, for example, or to even build the filters necessary to do so.
And video's harder. There's tons of mind-twisting buffer management issues to handle interpolated, motion-compensated frames that can take as reference past frames, future frames, and even other interpolated frames either past or future, using any of a number of different block sizes as the base motion-compensating element to which the discrete cosine transforms are applied. All with modified coefficients from the mathematically pure transforms -- powers of two to improve hardware decoding ease (even if it makes the filesize somewhat larger) -- that's what one of the key patents is about.
So, yes, it's hard enough and arcane enough that the likelyhood of someone with both the free time and the knowledge to do so, does it.
Don't bother reading TFA (Score:5, Insightful)
TFA is not worth your time. He says all sorts of outrageous stuff as if it were fact: apparently he knows exactly what Google was collectively thinking when it introduced WebM, for example.
And the ending is sort of surreal. Hooray! The patent-encrusted H.264 has defeated the challenge by the free and open software! Here are my wrists; there's still room for a couple more handcuffs, put them on! (Eh, probably not a fair summary, but about as fair as his treatment of Google.)
steveha
Re:open standard yes, open source no. (Score:5, Insightful)
If patents really define what makes software "free" or not-free, then no one would be able to chose to make a free H.264 codec.
I am not sure what you are trying to say. One can certainly write H.264 codec and distribute the source code under the GPL. But the recipient does not have the right to _use_ it unless he obtains a license. So, these implementations are not fully free and the authors cannot make them free (without offering to pay the license fees for all of the users).
My point is it's stupid to not support a codec just because of how it was invented. It's still free software.
At present no H.264 implementation _can_ be free software. If you use it for certain purposes or at a certain volume you have to give money to the MPEG consortium. You may think this is OK, but it is not "stupid" to be unhappy with this arrangement.
Re:open standard yes, open source no. (Score:5, Insightful)
H.264 is not free-as-in-freedom nor free-as-in-beer, and patents are the reason. IP amounts to copyright, trade secrets and patents, but the first two don't apply here. It's a patent issue.
No. It's a licencing issue. H.264 is not an open, royalty-free standard and that's what makes it bad choice for the web. VP8 is covered by patents but it's licenced under royalty-free terms. If H.264 was licenced under royalty-free terms for all use cases then there would be no issue.