Why Mozilla will support H.264 on OS that comes with it
hacks.mozilla.org
hacks.mozilla.org
WebM was originally a proprietary codec called VP8, developed by a single vendor (On2 Technologies) with a single implementation and no real specification. It was purchased by Google, and an ersatz specification was extracted from the implementation.
I admire Google for what they are trying to achieve. But given both Windows and Mac ship with H.264 decoding support, and it is fast becoming the de facto format for mobile, the decision seems to be a no brainer.
I guess the big question is whether H.265(6,7) could be argued to be more open than VP9(10,11). I get the feeling the former will continue down the patent route and the latter will be more likely to be a well-engineered open source success story (hopefully emulating the Opus codec effort, who by the way, opted for the code as specification route too), but you never know.
I think this is as close as we'll get to having our cake and eating it too while patents on algorithms are still recognized.
If I have to pay royalty fees to ship an h.264 decoder, that's not open. If I have to pay royalty fees for my startup to distribute videos in h.264, that's not open.
Standardized doesn't mean "open".
[Edit: I think several people in this thread disagree what Open means. Since this is the context of a Mozilla story, I think it is fair to use "Open" in the sense of "Open Source".]
WebM is free. Good luck implementing your own encoder/decoder.
And factually there's several independent WebM implementations now, some would argue that it's easier to be compatible with an open source codebase than a spec, though having (at least) two independant codebases developed before finalizing is better for finding spec bugs.
Nor does "open" mean "free".
I've found the VLC firefox plugin more stable than flash, downsides being it doesn't always get detected by javascript feature tests and UI integration isn't the greatest.
it boils down to software patents.
The Mozilla people wasted a ton of energy conflating WebM with open-ness rather than directing attention to the actually problem: current patent law. As long as someone else can show up and demand money for independent work the environment will predisposed against complete openness.
But one of the key aspects of the open web is that it is a platform that is open for anyone to access and participate in -- by creating content, or by building software to publish or consume content -- without any gatekeeper who can withhold permission or demand fees. This is why the W3C, for example, requires royalty-free licensing of members' IP that covers its standards.
This is the type of open platform that Mozilla and others were trying (but failing, so far) to create for video on the web.
> Losing a battle is a bitter experience. I won’t sugar-coat this pill. But we must swallow it if we are to succeed in our mobile initiatives.
Mozilla fought the good fight, and lost. Instead of standing on a street corner with a bullhorn, Mozilla is going to move on to fight the next battle. Those would be WebRTC and Google/Netflix's Web DRM initiative.
Having said that, the silliness of patented codecs seems to have been recognized for lower bitrate use cases (image, speech, audio) so I guess it's only a matter of time for video.
I think a Googly approach where the encoder and decoders are assumed to be software like anything else in Chrome and updated every 6 weeks would be interesting to see.
There are multiple reasons for this, like the huge cost of re-encoding everything that was once encoded in MP3, the broad hardware and software support or the fact that MP3 is good enough for most purposes.
Broadband plays a role here as I'd bet that if it weren't so prevalent today, then people would actually want formats that sound better at lower bitrates. As it is, Amazon doesn't have a problem in selling songs encoded at 256 kbps, although you won't hear a difference when comparing that to an 128 kbps encoded AAC file from iTunes.
An upgrade scheme only works if files encoded with the newer codecs don't have a problem being played on older software/hardware, because here's the thing ... H.264 is already good enough as far as video codecs go, just as MP3. And this is doable, but the newer patents will most likely touch the encoders, not decoders and the newer patents themselves will get more fragile over time, as you can't really innovate on top of the same technique forever.
All in all I agree with the general sentiment ... proprietary platforms are more dangerous than patents and native apps are more dangerous to the future of the Internet than proprietary codecs.
You could even argue that the fact that it always comes with such (relatively) large size video files makes the improvements of AAC over MP3 even less relevant, but still the "standard" has moved on and everyone needs to keep up. I also believe that 3G phones needed to support AAC but I could be just making that up.
I've seen one "mp3 player" that dropped AAC support, but I can't see that happening for any device that also wants video. The direct result will be paying separate royalties on two mostly overlapping audio formats.
Which of these is right?
The real issue for Mozilla is that you can get great benefits (shared history, passwords etc.) if you use the same browser on both platforms and sync them. Luckily Apple and Microsoft's lock-in approach seems to be holding them back here, but I'd imagine Android Chrome will be a big driver for Desktop Chrome (and possibly vice versa).
It would be really nice to have VDPAU video playback in the browser!