The third format is OGG as Linux does not support H.264 nor VP8 out of the box.
That's a wrong claim. VP8 support on Linux is commonplace. As well as H.264 support (if we are talking about system frameworks like gstreamer and etc.).
Browsers is another matter, and they ship with their own decoders. Mozilla provides an option to use gstreamer for Firefox, but it's not built by default. Mozilla can't use built in H.264 decoders simply because it will require licensing and will make it non redistributable.
Also, OGG is not a codec, it's a container. The author probably meant Theora.
Ogg as a fallback for Linux... Actually Theora was seriously planned to be the codec for HTML5 video, but Apple and Nokia spoiled this in 2007 due to some virtual patent problems.
That's known, but Theora never could compete with H.264 in quality. It was proposed simply because it was the best available open coded at that time. When VP8 arrived it replaced Theora for that role.
It's not that bad, moreover the game is always about quality/quantity ratio. And if it had become a standard, its development would be heavily pushed forward and vp8 would likely now be really free and called theora 2.0.
Latest builds of Chrome and FF play webm/vp8 fine on my Ubuntu machines.
Given that previously Linux users had to manually enable flash, asking them to update to recent browsers is a reasonable request (also good security). Saying you need Ogg/Theora for legacy Linux support is a bit silly -- that's a vanishingly small segment of the target audience, and they tend to be tech savvy anyway.
I wonder why it's not on by default. It can't be illegal to ship a browser that uses gstreamer, right? Users can purchase and install fluendo's codec pack to decode h.264 videos, or use the hw decoders in their graphics cards.
The main reason was Mozilla's openness martyrdom, but they've relaxed that position somewhat. There are still problems with pluggable codecs (of while GStreamer is one form): different users will have different codecs installed, leading to poor interoperability and trojan "codec packs" have been a vector for malware.
There is hope that Nokia is just FUDing, and these patents can be invalidated or shown to be irrelevant to VP8. (That's the story with Opus audio codec being attacked by various patent trolls). But all this takes time and these trolls naturally hate the idea of open HTML5 video.
It's not incompatible with anything, Simon is saying if it was an open source license it would be incompatible.
But it's not an open source license, it's a separate agreement with no bearing on either VP8 or the existing patent grant.
You can sign the cross license, and still be able to release/reuse/whatever any open source versions you like.
Sure, this agreement doesn't really affect any encumbrance or non encumbrance of VP8 by any patents. One can ignore this agreement altogether. The reason Google made it was to reduce FUD, but Simon Phipps suggests that it might not reduce, but actually increase it.
Whatever you may think of their patents or their strategy, is it fair to call Nokia a troll? Are they not actually manufacturing products which implement the patents?
Often the term "patent troll" is used to denote NPEs which don't produce any technology. However a broader meaning is simply extortionist / racketeer. Whether extortionist produces anything useful is already secondary. So I think it's proper to call patent aggressors trolls, especially when this aggression is directed simply to block competition.
In Nokia case, their products are not harmed by VP8 in any way. They just picked up a pile of patents for the sole reason of attacking an open codec and to prevent its adoption. It's also probable that it's not even Nokia's own initiative, but someone's who is behind them. Using third party patent trolls to fight competition while staying in background to avoid attention is a common technique amongst patent aggressors known as patent privateering: https://en.wikipedia.org/wiki/Patent_Privateer
Is this post coming from the past? It cites a table from diveintohtml that was made in 2011. Figures of h264 penetration also dating from 2011.
Things have changed since then: firefox has announced it would support h264. Opera has had versions supporting h264 but no longer does. Also, it fails to mention Google's agreement with MPEG-LA.
Finally, more than not giving anything new, it contains mistakes and confusions, the paragraph on Linux is terrible as it confuses containers and codecs, claims wrongfully that linux does not support h264 nor vp8 on the browser out of the box (all graphical linux browsers do support h264 or vp8, most support both). The only good thing to keep from this article is its title (oh and the update about firefox nightly).
Unlike VideoLAN, Mozilla has a big, obvious income stream for H.264 patent-holders to go after. Mozilla, quite reasonably, thinks they should spend that income advancing their mission rather than paying off patent holders (in a way that undermines it). They're also, again unlike VideoLAN, headquartered in a very, very software-patent-friendly jurisdiction.
Mozilla isn't refusing to ship H.264 because they lack "balls". They're refusing because there are serious practical constraints that get in the way.
Update October 2012: Wooohooo! Brendan Eich just announced on his blog that work for MP3 and H264 support in Firefox is underway. You can track the work on BugZilla: Support H.264/AAC/MP3 video/audio playback on desktop Firefox
Update February 2013: After much heavy lifting from Firefox developer Chris Pearce, this patch flips the switch to enable MP3, MP4, H.264, and AAC playback by default in HTML5 <audio> and <video> elements when running on Windows 7 and later. We should see some native web MP3 support in the next stable FF release.
Update April 2013: Woohooo! The latest stable Firefox has experimental support for MP3. To turn it on, type about:config in Firefox, find media.windows-media-foundation.enabled and set it to true. Restart Firefox, and you're all set; go to a site with HTML5 audio (e.g. my radio site) and you'll see Firefox is indeed playing the native MP3 and not resorting to a Flash fallback.
Update May 2013: At last! Firefox 21 was released today, and it includes native HTML5 MP3 support on Windows. I just verified it supports native MP3 audio out-of-the-box, provided your operating system supports it. I tested on Windows 8, but I believe this will automatically work on Windows 7 and Vista.
Such opposition is reasonable. Someone has to fight against closed codecs. But fighting alone is hard. Google pretended to be the "white knight" when they promised that they'll drop H.264 support from Chrome, but they deserted the battle and didn't keep the promise. They could really influence the industry by dropping H.264 support from Youtube, but they don't have guts to do it since it's quite disruptive.
I'm positive that anyone who misuses the word "closed" to refer to patent encumbrance has never had to suffer through working with actual by-definition closed codecs.
You should have enough information from the context, to distinguish closed as "no known specs", from closed as "not free to use". May be the term non free / free (as liberated) codec is more descriptive, but closed/open will do as well.
Yes it does. Mozilla couldn't avoid using H.264 in Firefox OS because VPx hardware decoding isn't widespread yet (though it catches up in the newest SoCs). But it uses the capability of the underlying system. I don't think Mozilla licenses anything from MPEG-LA.
Availability in SoCs is paired by actual deployment of those SoCs to end user devices. The majority of currently available end user devices don't have hardware VP8 decoding yet. As time goes by and newer SoCs push out older ones this will improve, but we aren't there yet.
Windows 7, 8, Firefox OS, Firefox for Android are working as we speak on release.
gstreamer is working on Linux and Mac, but not built by default _yet_, it should be ready in a couple weeks or something.
We decided to release the support for mp3/h264 as we implemented them, rather than waiting for all the platforms to have the support.
Supporting Android and Firefox OS, then Windows (in that order) is a simple matter of prioritization and human resources. Most of our users use Windows, so it kind of made sense to have released support for Windows first.
I can point you to builds of Firefox for Linux/Mac with gstreamer enabled if you want to test something and don't want to compile it yourself, username at mozilla dot com.
My issues are three fold: that Mozilla is propagating proprietary standards, that it is selectively implementing per platform on a majority basis, and that by doing this it is further fragmenting the web.
My issue was not whether it actually works or not on a smattering of platforms. I believe you there. Though I appreciate the response.
Because they were already implementing gstreamer support for Linux, and gstreamer has a high-quality back-end for OS X's apparently awkward audio APIs that I guess Mozilla didn't want to reimplement from scratch.
Yes it is patented which is a definite disadvantage compared with a theoretical[4] patent free codec but it has some real advantages.
1) The standard is controlled and defined by a collective industry group under the auspices of ISO. [1]
2) Most of the major players in video technology at the time took part in the standardisation so are committed to FRAND patent licensing terms. [2]
3) In almost all cases and commercial business models (that do not involve Free software) the MPEG-LA H.264 patent license is really very reasonable and unlikely to cause problems to an otherwise healthy business. Note that the license Google has to the MPEG-LA pool of patents while free is NOT compatible with Free software.
4) Any companies not in the MPEG-LA pool that popped up now with demands really would trolls in the original sense that they have sat under the bridge for a long time waiting for a juicy opportunity rather than being upfront earlier. I don't think that this would help them in a legal case although there is no guarantee that they don't exist. [3]
5) H.264 is really quite good although the latest codecs are showing what can be done with further development and processing power.
6) H.264 decoding (and often encoding) is cooked into a massive amount of existing and deployed devices in ways that cannot be adapted to VP8/VP9 by a software update.
For now H.264 is the no brainer option for any commercial system although multi codec support may be worthwhile in some cases. If you want patent free I recommend MPEG1 as I believe any patents on it should now be expired or at least expiring very soon if they were granted a long time after filing. I'm glad that Firefox has backed down and will now use the OS codecs to allow playback of H.264.
[1] The OOXML case shows that this isn't foolproof but in my view it is a better option than the standard being controlled by a single company even if the controlling company publishes the source code. This applied to Microsoft when they offered VC-1 as a free alternative to H.264 (there is now an MPEG-LA pool) and to Google now with VP8 and VP9 now. Google is the new Microsoft and has fully learnt the lessons of "Embrace, extend and extinguish".
[2] Not Free software compatible but better than nothing. And even Google's license to the VP8 patents from the MPEG-LA pool does not seem to grant Free software compatible rights.
[3] There is a greater risk of people popping up with claims against VP8 or VP9 as they are newer and less prominent. The MPEG-LA's call for a pool of patents has helped draw out those patent owners and many have joined the pool and reached terms with Google (although Nokia and maybe others haven't.
[4] Realistically for patent free greater than 20 years old is the answer so it probably needs to be MPEG1.
Whether it's better or not in some aspects, in practice patent encumbrance makes such decoders non redistributable, therefore open source browsers can never normally adapt such codecs, and it makes sense for W3C/IETF to choose mandatory codecs only from explicitly open (i.e. free and non patent encumbered). The best course of action is not to bow to codec cartels like MPEG-LA, but to fight against current closed codecs domination and to advance open ones by improving and creating new better codecs.
There is a greater risk of people popping up with claims against VP8 or VP9 as they are newer and less prominent. The MPEG-LA's call for a pool of patents has helped draw out those patent owners and many have joined the pool and reached terms with Google (although Nokia and maybe others haven't.
This is common FUD. Whatever was in that "pool" - the end result no one attempted to attack VP8 with patent claims, except for Nokia. The strange counterexample to the claim that "prominence" guarantees safety is Google, who used H.264 against Microsoft themselves. Nothing is protected against sudden patent attacks. But if there are no known patents - then paranoia won't help anything.
I don't claim that W3C or IETF should standardise on H.264. I think it is perfectly sensible for them to hold the line but the practical reality for implementers is that H.264 is a commercial requirement.
Note that I said "greater risk" not that there was no risk for H.264 or that it is a massive showstopper for VP8. I stand by my statement although this really isn't critical EXCEPT for the fact that due to FRAND commitments potential claims are limited (as the Motorola/Google case is showing). If you have made no FRAND commitments you can get injunctions or ask for outrageous (hundreds of millions of dollars or even billions) licensing fees but if FRAND commitments have been made you cannot do this as the courts are educating Google/Motorola.
The obvious baseline for W3C to adopt would in my view be MPEG1 allowing a fallback to a safe free codec and modern non free codecs to be used otherwise.
Quality is important. Using poor quality common denominator is a bad idea. Once Nokia attack is cleared, VPx would be good to use again as a base available open codec. FRAND or non FRAND can affect damages, but as I said above it doesn't change the non redistributable nature of anything that depends on it.
Anything can happen, but On2 was diligent in evaluating public patents related to video. So it looks like Nokia is spoofing things up. Time will tell of course. One of the benefits of the IETF process is the requirement to disclose all the patents, so they can be evaluated and refuted if possible. I'm sure WebM project is busy with reviewing this.
Freedom, zero cost, quality, low legal risk.
Where did you find freedom and zero cost there? Low legal risk is a myth in the land of patent minefields.
the Google license is non-redistributable anyway
Again wrong. VPx content as well as encoders and decoders are redistributable under the current license which is fully open source compatible.
> Where did you find freedom and zero cost there? Low legal risk is a myth in the land of patent minefields.
I made it up, couldn't narrow it down to three. MPEG1 is low risk, free and Free now. AVC is low risk now it has been a juicy target for long enough to draw out trolls and it is high quality. VP8 is high quality and zero cost.
The license that Google has from the MPEG-LA doesn't seem to allow for those who accept the license to sub license. If this is incorrect please send a reference.
You seem to be of the view that the pool contents are either invalid or non-essential. Until I see a detailed study of them that indicates this with claim by claim explanations I will assume that at least some may be valid. Now Google has taken the license it is highly unlikely they will challenge the pool patents (and they may be contractually obliged not to). This means there is no big player likely to fight the patents and make the status clearly open source compatible.
Ah, I see, I thought you meant all 3 as related to H.264.
> The license that Google has from the MPEG-LA doesn't seem to allow for those who accept the license to sub license.
The license is a FUD reduction tool. You can simply ignore it in the context of the open source license of the codec itself - it's not part of that license at all.
> You seem to be of the view that the pool contents are either invalid or non-essential. Until I see a detailed study of them that indicates this with claim by claim explanations I will assume that at least some may be valid. Now Google has taken the license it is highly unlikely they will challenge the pool patents (and they may be contractually obliged not to). This means there is no big player likely to fight the patents and make the status clearly open source compatible.
I'm not sure what you are talking about - patents that MPEG-LA supposedly has against VP8, or the patents that Nokia presented against it?
If the former, those contents can as well be simply non existent and their potential existence used as a tool to spread FUD. Until anything is publicly presented (like Nokia did), there is no reason to pay attention to that "pool". Note that Google didn't license any patents that are known to be affecting VP8. Nothing like that. They just licensed "something", so that MPEG-LA would stop making statements like "what a good codec you have here, a pity if something would happen to it if and when we find some patents against it". I.e. Google bribed them to stop spreading FUD. In no way does it demonstrate that MPEG-LA has any actual patents against VP8.
If the later - the list is published, and now in the process of being reviewed / refuted. Let's see how that works out.
I listed four features and suggested that only two were available from each of the current codecs.
You are also free to use open source AVC implementations and ignore that MPEG-LA license too. Depending on who you are and what you are doing with AVC the probability of action by a patent holder could be very low.
I meant the patents under the MPEG-LA from the eleven companies (some of whom I would take seriously) and including at least two of the biggest Android manufacturers rather than Google's enemies:
CIF Licensing LLC
France Telecom
Fraunhofer-Gesellschaft zur Foerderung der angewandten Forschung e.V.
Fujitsu Limited
Koninklijke Philips Electronics N.V.
LG Electronics Inc.
Mitsubishi Electric Corporation
MPEG LA, LLC
NTT DOCOMO, INC.
Panasonic Corporation
Samsung Electronics Co., Ltd.
Siemens Corporation
You are right that the patent list does not seem to be published which is unfortunate. If the patents in the AVC pool owned by these companies were checked against VP8 by someone credible and preferably independent it would give quite a good degree of assurance about them.
Do note though that Google claimed to have bought On2's patents and they too only seem to be offered under the same non-FOSS compatible licence as the MPEG-KA ones.
As for the Nokia patents I don't think that they would have been brought to courts if Nokia didn't think victory was a realistic outcome. However the drop out rate for claims is very high in all the patent disputes although it seems very hard to predict at the start what will stand up and what will fall so it is entirely possible that they will fail. From my perspective this seems a bad sign for the consistency and predictability of patent law which needs major reform rather than proof that Nokia is claiming rights that IT doesn't believe it has.
The list of companies doesn't impress me. Many manufacturers are engaged in patent racket. It's Google refusal to play the same game that caused their ire and fear mongering. As I said, until they actually publish what's supposedly exists in that pool - there is no point to pay any attention to their claims.
Still not FOSS compatible as the patent grant is only for implementations of the specification. It is still a pretty generous grant without other caveats though.
The patent "racket" is the system enshrined in the current laws which I agree need fixing but our wishes for that to happen don't make it so and the patents won't disappear unless it does or until they expire.
You might want to be more precise about what you mean by "non redistributable", because licensed binaries are redistributable if they either phone home to track the number of copies or if the vendor pays the cap. Mozilla got all bothered about downstream source redistribution which affects approximately zero of their users.
Yes, I mean downstream redistribution. Mozilla stands for open source licensing which allows downstream redistribution and they aren't going to change that. Whether it's used in practice or not is secondary, since that's what the license allows. If they change it, they have to change their license altogether.
Or they could just not include the H.264 decoder in the source code and leave the license the same, like they did with a few other components back in the day.
> [4] Realistically for patent free greater than 20 years old is the answer so it probably needs to be MPEG1.
Rather than waiting 20 years, we could lobby for legislation that developing, distributing, or running a program on generally used computing hardware does not constitute patent infringement. [1]
HLS (http adaptive streaming) is non-existant in Chrome, except for on the Google TV. So I end up having to develop in Safari, which is painful. Especially when I'm making apps for the Google TV (and other SmartTV Platforms).
That's a wrong claim. VP8 support on Linux is commonplace. As well as H.264 support (if we are talking about system frameworks like gstreamer and etc.).
Browsers is another matter, and they ship with their own decoders. Mozilla provides an option to use gstreamer for Firefox, but it's not built by default. Mozilla can't use built in H.264 decoders simply because it will require licensing and will make it non redistributable.
Also, OGG is not a codec, it's a container. The author probably meant Theora.