H.264 is not a "proprietary video codec", it's a patent-encumbered codec. The spec is available for free on the ITU website(http://www.itu.int/rec/T-REC-H.264) and several open source implementations exist.
The spec is useless, even harmful, if 3 years from now MPEG LA decides to start charging content providers a licensing fee for their content, even if that content is distributed for free.
If we start using a codec for which the patents are owned by a company, and that company dictates the licensing terms for that codec, then aren't we handing control to how the content is distributed to said company?
I was responding to the line "if 3 years from now MPEG LA decides to start charging content providers a licensing fee for their content, even if that content is distributed for free."
Which is paid for by the folks making the software tools unless the OS paid the fee for the codec in which case you're good. The camera manufacture either paid the fee or shoots a format that can be converted on the PC.
That says absolutely nothing about h.264 decoder or encoder implementations, such as the decoders needed in web browsers to handle h.264 in <video> tags; that just says MPEG-LA won't charge people distributing h.264 video files.
The parent post didn't mention decoders / encoders, it mentioned free content. These articles[1][2] explain the costs and possible increases[3]. Apple, Microsoft, and Google have bought the license for their libraries on their platforms.
Exactly. All they've said is "we promise we won't charge you for sending bits of h.264-encoded data across a wire". It's not clear that they legally could charge for that even if they wanted do!
And yet they've fooled vast numbers of people into thinking that h.264 is free-of-charge as a result. It's the most impressive piece of anti-FUD I've ever seen, sadly.
> Unfortunately that dream has failed to pan out. Instead of proprietary plugins, the web ended up with proprietary video codecs, which has created a split in browser support for HTML5 video. Firefox and Opera support the open Ogg and WebM codecs, while Safari and Internet Explorer supported H.264.
Funny, it looks like a major browser was left out there (in fact the #1 browser in usage according to some metrics).
The article is pretty good overall, but is missing a key piece that is important to understand the background.
Yeah, from the "related" links at the bottom you can see this article from January 2011 entitled "Google Dropping H.264 Codec from Chrome Browser" ( http://www.webmonkey.com/2011/01/google-dropping-h-264-codec... ), which has still yet to come to pass.
I blame Google for this, too. They should've made Youtube play on WebM by default, with a fallback to Flash in browsers that don't support it. That would've forced the others to adopt WebM.
I watched the Amazing Spiderman trailer[1] in 720p in both formats - using youtube-dl - and I honestly couldn't tell the difference. The webM file is ~16% larger, though.
So... yeah, I'd say it profoundly affected the MPEG-LA's behavior. If Google didn't have an easy out with (what would become) WebM, their Youtube licensing would be much more expensive.
Whether that patent promise has any bearing on the Mozilla decision is a more complicated issue. People have strong opinions on both sides.
H.264 was already well entrenched when On2 was bought. Whether or not it was a good purchase will be seen more by a) how H.265 fares, b) how well AAC holds up against patent free mp3, Vorbis and Opus, c) how IETF's proposed Internet Video Codec and VP-Next fare (and they may potentially become a single project), and d) how many people are still paying for H.264 licences when it's no longer technically impressive, software-based companies in particular seem poised to jump off the upgrade treadmill early unlike earlier hardware based generations that could be milked for far longer.
H.264 vs. WebM is a far more nuanced tradeoff – widespread support and higher-quality implementations versus [hopefully] freedom from patents. Either way, the web wins if there's more <video> and less <embed> depending on an opaque binary blob from a single vendor with a track record of platform neglect.
You say "no extra effort", as if widespread platform support, hardware acceleration, more than one high-quality implementation, significant support by authoring software, and direct-to-format hardware capture would happen for free. Avoiding royalties would be nice - although it's almost certain we'd still have lawsuits absent patent reform - but as a business decision that's a LOT to give up.
I really think Mozilla did the web a disservice. They should have implemented platform codec support immediately and added other formats so content vendors could adopt HTML5 video independent of the codec wars
And that's one of the biggest problems with software patents. In 15 years, we'll likely be using a different codec (or, at least I would hope we'd make some progress in that amount of time).
On the plus side, the situation is much less dire than it was back when Mozilla first made the argument against H.264. WebM is a serious alternative, and if MPEG LA tries anything funny, people will be able to switch.
Unfortunately, WebM isn't _really_ a serious alternative. It's a fine codec and produces great quality video in a similar filesize to H.264, but it's not supported on the majority of mobile devices. H.264 is also what many consumer video cameras produce, like iPhones and most DSLRs.
Pragmatically, I'm happy that all the major browsers (with the exception of Opera) will now support one common codec, even if it's patent-encumbered.
Depends on the threshold for calling something "serious". It's far more serious than any alternative before WebM, that's for sure. No competing format will ever be an instant drop in replacement for an entrenched format, but there is a continuum of scenarios below that.
I hope content publishers will find publishing HTML5 video convenient enough to drop Flash. Once publishers are all on board the HTML5 video train, they have the opportunity to experiment with new (and unencumbered) codecs without affecting their user experience.
How do they plan to defend against vulnerabilities in the system codecs? Especially a GPU-accelerated codec has the potential to wreak all sorts of nefariousness.
By deferring to system codecs, they manage to defer some licensing questions, too.
It's a nice compromise, and it still encourages using royalty free codecs (since those are the only ones with a chance of guaranteed deployment, even if Apple is still acting funny these days)
