Mozilla reconsiders H.264 [LWN.net]

March 21, 2012

This article was contributed by Nathan Willis

Mozilla raised eyebrows in mid-March when a patch materialized that would allow Gecko to fall back on operating system or hardware media decoders for multimedia content — in particular for patent- and royalty-encumbered codecs like H.264, which are not supported natively in Gecko. The project had fought hard to promote the adoption of unencumbered alternatives (such as Ogg Theora or Google's WebM), so many on the mozilla.dev.platform discussion group saw enabling any support for H.264 as a violation of principle. Mozilla's Chief Technology Officer Brendan Eich argued, however, that the decision is an improvement over the existing Flash-fallback method, that Mozilla has more important fights to focus on, and that the blame for WebM's snail-paced adoption lies squarely at the feet of Google.

History of the WebM, part 1

Eich posted his take on the situation in a round-up at his own blog (which was then syndicated at the official Mozilla Hacks blog), which started with a history lesson on H.264, WebM, and the HTML5 <video> element. As far back as 2007, Eich and Mozilla had argued for the standardization of the <video> and <audio> elements to include "unencumbered" baseline codecs — at the time, Ogg Vorbis for audio and Ogg Theora for video. Eich argued that the term "unencumbered" most accurately describes the state of the codecs needed to ensure that the open web remains open; the issue is not about open source (for there are open source implementations of encumbered codecs), nor is it about patents (for standards bodies can and will accepted a patented codec if the patent holders agree to license it under royalty-free terms).

In 2007's <video> element fight, the main opponent of Theora was H.264, which was being pushed by a royalty-collecting consortium of companies. The protracted battle ultimately resulted in a non-decision, with the default codec language being removed from the draft standard. But the situation appeared to take a sudden shift in favor of unencumbered codecs in 2009, when Google purchased codec-maker On2 and released the WebM codec under unencumbered terms.

WebM was far newer than Theora and offered quality roughly on par with H.264; Theora's relative performance was a big reason Google did not advocate it as the default codec.. Google subsequently announced its intention to transcode YouTube videos to WebM, and in 2010 Adobe announced that it would support WebM in its Flash products (meaning not just the browser plug-ins, but the content-creation tools and media-delivery servers as well). In January 2011, Google went a step further, and publicly announced that it would drop support for H.264 from its Chrome browser.

But that change never happened. 14 months later, Chrome still supports H.264, and Eich and other Mozilla employees report that Google has remained silent about the decision when asked. Adobe didn't implement the WebM support that it promised either.

Meanwhile, Eich said, H.264 adoption has continued to spread, which has hampered Firefox's growth. For starters, Google's oft-cited promise to trancode YouTube's content to WebM is not all it is cracked up to be: to date Google has only transcoded half of the site's videos, and more importantly, YouTube only delivers WebM content to desktops, and only for those videos that serve no ads (which Eich said makes up a shrinking portion of the total). No other major sites have rejected H.264 in favor of WebM delivery either, while the consumer electronics industry builds more and more H.264 encoding support into video cameras.

On the desktop, Firefox falls back on the Flash plug-in's H.264 support, but on mobile devices, there is no such option. Mozilla believes that mobile browsers are clearly the battlefield deserving the most attention, and on top of that, the project's Boot to Gecko (B2G) effort stands no chance of making it into device-makers' products without H.264 support, Eich said.

Patches and a new API

The combination of Google not pushing WebM and content creators adopting H.264 puts Mozilla in an untenable position, Eich said. Yet the majority of phone and tablet designs ship with a pre-authorized (meaning the royalty fees have been paid) H.264 decoder in silicon, which is what led developer Andreas Gal to propose letting Gecko hand H.264 decoding (and perhaps other encumbered formats like MP3 and AAC) down to the OS or hardware level. Although other option have been discussed, Eich endorses Gal's solution. The upshot is that Firefox and B2G users will be able to see H.264 content on platforms that support it, Mozilla will not have to pay royalty fees (or pass them on to users), and the project can turn its attention to fighting for unencumbered codecs in the next round of standardization battles.

Those battles are not far off, Eich said, starting with the WebRTC real-time chat standard — which is already in-progress and looks poised to recommend unencumbered codecs. There will be other fights, he said, and other generations of video streaming codecs. Continuing to ignore H.264, particularly on mobile devices, would ultimately risk making Mozilla irrelevant further down the line, if not nonexistent altogether:

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. Failure on mobile is too likely to consign Mozilla to decline and irrelevance.

Gal's patch is attached to bug 714408. In essence, it creates a new API (which Gal dubbed the Media Player API, or MPAPI) for use by OS or hardware decoders. On desktop OSes like Linux, MPAPI would likely be tied in to a media framework like GStreamer (which can use encumbered codecs). It is also possible that the Mozilla Flash plug-in could continue to serve as the H.264 decoding chain on desktop systems, which would require work to expose MPAPI to the Gecko's main plug-in API, NPAPI. Of course, Adobe has also said that it will stop developing its NPAPI Flash plug-in for Linux, which means Flash-fallback will not remain a solution for free OSes in the long term.

As of now, the patch itself is the main source of information on MPAPI, which is still very much a work in progress. MPAPI would hand audio and video frames back to the main Gecko rendering toolchain, however, meaning the content would be fully integrated with the page's JavaScript, HTML, and CSS like any other <video> or <audio> element. The vast majority of the energy expended about the move has not been with its technical points, but with whether or not Mozilla's decision itself is wise, foolish, too pessimistic, or long overdue.

Reaction

The mozilla.dev.platform discussion thread about Gal's proposal is rife with critics arguing that Mozilla is making the wrong move, and with defenders inside and outside the project. The criticisms fall into three basic camps: those that think the H.264 situation is not as bad as described, those that feel Mozilla has not tried hard enough to advocate WebM (or that it should try Just One More Time), and those that object to enabling any form of H.264 playback on principle alone.

Critics who say that WebM has not lost to H.264 tend to point to Google's YouTube transcoding effort (which Eich countered in his blog post), or hold out hope that Google will indeed drop H.264 support from Chrome (often based on the number of WebM "supporters" listed). On the latter point, Eich argues that Chrome's H.264 support is moot, because the desktop browser would simply fall back on the Flash plug-in like Firefox does today. In fact, he said, Chrome's heavily optimized Flash plug-in amounts to a "practically custom" Flash offering "best-of-breed fallback".

Christopher Blizzard added that ultimately, the content-delivery sites simply are not interested in WebM:

I keep talking to people building sites and there are only a couple of organizations that are willing to embrace WebM because it's the right thing to do. Transcoding & hosting costs are huge. Beyond that I've not really run into anyone who wants to do WebM. It's just seen as a cost that Firefox is incurring on web developers.

Justin Lebar typified the position that Mozilla is giving up too quickly, calling it "going down without a fight," and saying that he would:

publicly call on Google to fulfill its promises of old. I'd communicate through official channels why we don't want to support H.264, MP3, etc, and why we think Google is harming the web. [...] And I might set a public deadline — if Google doesn't un-support H.264 by date X, then we'll start supporting system H.264 and MP3 codecs.

Side-stepping the fact that Lebar's public deadline idea paradoxically threatens to increase support for H.264 if it is not abandoned, Mozilla's Robert O'Callahan calls it "grossly unfair" to suggest that Mozilla has not fought hard enough or long enough against H.264 adoption:

We have fought. We, alone of all major browsers (sorry Opera desktop), have held out against supporting patent-encumbered codecs for a long time. I feel it's grossly unfair to our efforts to describe that as "not a real fight". We held the line in the hope that the industry would follow, and that Google would do a lot to improve and support WebM, especially removing H.264 support from Chrome. So we've held the line, and watched, and waited, and personally I am extremely disappointed by the results.

Likewise, Asa Dotzler confirmed that Mozilla has spent months trying to get a response from Google on the H.264 support question, only to be met with silence. O'Callahan also observed that there is already mobile hardware capable of decoding WebM video, but that Google does not enable it on Android devices. In the absence of support from the format's owners, Mozilla says, it alone cannot move WebM forward.

The objection on principle is trickier. Some in the discussion thread expressed personal hurt that Mozilla was not standing its ground against H.264 playback support, but more were concerned that relenting would make it harder for the organization to lobby against encumbered formats in the future. Eich argued that anyone who ignores the fact that Firefox users watch H.264 video via the Flash plug-in is "hiding behind Mother Adobe's skirts" and is not taking a "realistic view of the entire fallback logic chain, and of Firefox's current acute dependency on Flash", which is not different in kind from falling back on an OS decoder. Gal concurred, noting that the MPAPI proposal is only "using existing accelerated decoders that already are licensed and available on the system."

Regarding Mozilla's ability to advocate for open and unencumbered formats in the future, Doztler said that the project has backed down on other lost battles in past, such as the document.all DOM feature, but has maintained it credibility. Mozilla can influence the web, and from time to time kill a bad idea, he said in another message, but "sometimes the Web decides to go where we don't want it;" not supporting it only costs the project developers and users.

Ultimately, though, Dotzler argues that even in light of H.264's popularity, Mozilla's WebM advocacy does not constitute a wasted effort:

WebM is in much better shape because of Mozilla's efforts. Not only is WebM in better shape, but I think it actually proves that open codecs can compete. It didn't win, but it demonstrated viability and it may yet go on to claim a critical role in WebRTC. Finally, I think there's something important in our having taken that stance. We've demonstrated that we don't default to "what's easy". We may not be able to win every battle, but we don't shy away from fighting the good fight.

A continuing story

It is worth remembering that however one feels about the H.264 lobby and its royalty-collecting schemes, the presence of dedicated video decoding chips is hardly an isolated situation. There are currently a great many components in our computers which are covered by patents, and many chips for which we do not have source code. Yet enabling software access to those components is not perceived as a violation of principle. Furthermore, it is hard to argue that the Flash plug-in that Firefox currently falls back on is turf worth fighting for — it has a history of bugs and security holes unrelated to the video decoders it ships.

The debate over enabling H.264 playback via MPAPI shows little sign of calming down. Eich, Dotzler, Gal, and the other project members continue to argue that enabling the format is a purely pragmatic move, and that it would be a better use of Mozilla's energy to combat encumbered codecs on the still-in-development format battles.

They got a boost on March 18 when Mozilla chief Mitchell Baker posted her own blog entry in support of the proposed change. Baker said that "giving our users a great experience" is both one of the project's key values, and a demanding goal that drives realistic product development.

It's possible to fall into the view that the only way to live up to Mozilla values is to ship the product we think people should want. This aspect is one element, but it's not the only one. Another critical element is shipping products that work for people now so they can love them.

The comment thread on Baker's blog follows much the same pattern as the discussion group. There are supporters, commiserators, and vocal critics. But wherever H.264 itself ends up on future versions of Firefox and B2G, one thing is for sure: H.264-vs-WebM is not the last codec fight the software world will see. As several in the thread pointed out, progress on H.265 is already well underway, and the players involved are similar — there can be little doubt that the battle will be similar, too.

Index entries for this article
GuestArticles	Willis, Nathan

to post comments

Mozilla reconsiders H.264

Posted Mar 22, 2012 1:41 UTC (Thu) by gmaxwell (guest, #30048) [Link] (10 responses)

If you'll note— not a single comparison post has been made with figures comparing battery life for "hardware" H.264 platform decoders and the WebM/Theora decoders (which on some platforms are hardly any less hardware than the H.264 decoders).

Perhaps its a big deal on some devices, perhaps it's not. The thing is no one is posting the figures. And in my own profiling Firefox appears to spend more CPU time moving the pixels around in the rendering pipeline than it does actually _decoding_ the video. (Due mostly to a respectable, if not at all pragmatic, decision to make <video/> first class in the HTML rendering model thus breaking all the classic accelerated video rendering)

In light of all that, I think it's deceptive to cast this as a hardware compatibility story. It's a content compatibility story— for sure.

But I think it's also at least a little bit of a scapegoating for Firefox's declining market share— market share loss that has little to do with video and a lot to do with those chrome popups on every Google site and the hermetic seals on new Apple devices. But I thought the tone was clear enough for the discussion— people feel the declining relevance. "We Must Do Something. This is Something. Then it Must Be Done.". That fact that a lot of their market share is being lost due to aggressive marketing by their primary financial sponsor has to cause a heck of a lot of cognitive dissonance.

I think it's also a story about Apple's increasing influence on the tech decision maker market— Almost every Mozilla person, technical or otherwise, I know/have met (with the exception of the codec DSP folks) is a true apple aficionado, with one or two of each of the shiny idevices. How do you make a platform with a modest market share as important as a platform ten times larger? Make it appeal to the project managers, engineers, and managers of technology companies. With influence like that simple inaction, "don't ship a codec you don't hold patents on" changes the world, Mozilla used to have that kind of influence. I thought it still did, I guess Mozilla doesn't think so. Brilliant strategy, but one which in Apple's hands doesn't bode well for the world of Free Software at all.

And of course, this is a story about Google's lost direction and failure to scale— spend $125 million buying a codec company to free its codec, make grand promises... take all the engineering cost to deploy the codec on Youtube, but only to leave it incompatible with their new advertising incentives program. Ultimately resulting in a reguression to fewer and fewer videos available via WebM. Though this aspect is a story that has been covered in many places.

Mozilla reconsiders H.264

Posted Mar 22, 2012 4:11 UTC (Thu) by roc (subscriber, #30627) [Link] (8 responses)

I'm not sure what you're getting at with "Almost every Mozilla person I know/have met ... is a true apple aficionado". I just did a survey of the 7 Mozilla developers in the Auckland office:
-- 0 out of 7 own an iPhone
-- 0 out of 7 own an iPad
-- 1 out of 7 uses a Mac as their primary machine
Feel free to list the Mozilla people you know or have met, and identify which ones are "true Apple aficionados", but I suspect that you may not have a representative sample.

Even if it were true, I'm not sure what you're implying. That liking Apple products induces a desire to use patent-encumbered codecs?

> in my own profiling Firefox appears to spend more CPU time moving the
> pixels around in the rendering pipeline than it does actually _decoding_
> the video

Maybe true when GPU compositing is not enabled. Not true when GPU compositing is enabled, when I've profiled it. If you're seeing those results with GPU compositing enabled, please file a bug and we'll fix it.

Contrary to your speculation, this has little to do with desktop market share. On desktop we could support H.264 via Flash for a good while yet without too much user impact. The sticking point is mobile: to be relevant, we have to grow market share on mobile devices, which means we have to be able to play H.264 on those devices. And of course, on mobile, Flash is either non-existent or horrible and withering.

Mozilla reconsiders H.264

Posted Mar 24, 2012 0:18 UTC (Sat) by robert_s (subscriber, #42402) [Link] (6 responses)

"to be relevant, we have to grow market share on mobile devices"

because...?

Mozilla reconsiders H.264

Posted Mar 24, 2012 2:38 UTC (Sat) by roc (subscriber, #30627) [Link] (5 responses)

Because Web browsing is moving to mobile devices.

Mozilla reconsiders H.264

Posted Mar 24, 2012 8:50 UTC (Sat) by dlang (guest, #313) [Link] (2 responses)

'moving to' or merely 'growing on'?

Yes, the use of mobile devices is growing significantly, but is the use of desktop/laptop machines actually shrinking? or is it just shrinking as a percentage of all use (which will always happen when a new use starts at 0%)

Mozilla reconsiders H.264

Posted Mar 24, 2012 9:15 UTC (Sat) by khim (subscriber, #9252) [Link] (1 responses)

It's losing proposition. PC use is most defenitely shrinking in certain niches but this shrinkage is offset by growth in other niches. Eventually it'll start shrinking across the board.

Mozilla can dismiss mobile like Nokia and RIM dismissed iPhone back in 2007: eventually it'll be disrupted and will collapse even if it'll take 4-5 years.

Mozilla reconsiders H.264

Posted Mar 29, 2012 22:59 UTC (Thu) by blujay (guest, #39961) [Link]

I think your crystal ball needs polishing.

This trend of one-UI-fits-all-devices is just plain fail. We don't even need Firefox and Gecko on phones, especially not until it's underlying architecture is fixed up (i.e. Electrolysis needs to become Firefox).

Nokia and RIM were in the business of selling devices--Mozilla is not, and should not be. Mozilla needs to refocus on its core mission of making the best browser for computers (i.e. systems with keyboards and mice).

Mozilla reconsiders H.264

Posted Mar 25, 2012 15:08 UTC (Sun) by drago01 (subscriber, #50715) [Link]

That's nonsense.

There is a growing marked of web browsing on mobile devices but it is not moving there. Also people tend to accept missing features on such devices more than on traditional desktop devices (see flash).

Mozilla reconsiders H.264

Posted Mar 29, 2012 22:56 UTC (Thu) by blujay (guest, #39961) [Link]

My laptop and netbook are mobile devices.

Oh, you mean phones? And tablets? Touchscreen devices? Who cares!

It's time for Mozilla to focus its mission and scale back its grandiose ambition. We don't need Firefox on phones and tablets--there are already good browsers there. It might be neat, but that's not as important as maintaining the existing browser and developing it further. Desktop/laptop/netbook systems are not going away! I don't need my phone's browser to do everything Firefox can do! (And with Firefox's eternal freezing and stuttering, I don't want it to. How about fixing that before expanding to completely new platforms? What if all the Mozilla devs spent two weeks on that one problem and killed it once and for all?)

Mozilla may end up spreading itself out and doing nothing well--then it will really lose relevance. I'm becoming more interested in other, smaller-scale browsers that are user-focused, without the baggage of the Mozilla project.

Nokia and RIM were in the business of selling devices--Mozilla is not (and should not be!).

IMO, Mozilla's mission should be to make the best desktop/laptop/netbook/systems-with-keyboards-and-mice browser there could possibly be. A secondary mission should be to encourage the open Web--but I'm not convinced that putting Gecko and Firefox on phones and touchscreen tablets is necessary to accomplish that goal. Indeed, if trying to do so hurts Mozilla in the long run, then the open Web will suffer in the long run.

Mozilla needs to set trends, not follow them. It used to do just that, but then Chrome caused a panic, and now Mozilla is pandering.

Get back to your roots, Mozilla! Rise like a Phoenix!

Mozilla reconsiders H.264

Posted Mar 25, 2012 14:54 UTC (Sun) by drago01 (subscriber, #50715) [Link]

> Maybe true when GPU compositing is not enabled. Not true when GPU compositing is enabled, when I've profiled it. If you're seeing those results with GPU compositing enabled, please file a bug and we'll fix it.

Well it has been both disabled and broken on linux since day one and it seems that there is no progress being made to fix it. (WebGL is fine GPU compositing is still broken).

Mozilla reconsiders H.264

Posted Mar 23, 2012 21:45 UTC (Fri) by wazoox (subscriber, #69624) [Link]

> Almost every Mozilla person, technical or otherwise, I know/have met (with the exception of the codec DSP folks) is a true apple aficionado, with one or two of each of the shiny idevices.

Strange. I'm committed to Firefox mostly because I don't like Chrome interface and I'm hooked to 45 extensions; but Firefox decidedly sucks bricks on Mac OS. Fortunately, I myself plan to get rid of my last Mac soon (not free enough, son. Need more GNU tasting technology), and Firefox really runs great on Linux.

Mozilla reconsiders H.264

Posted Mar 22, 2012 2:53 UTC (Thu) by slashdot (guest, #22014) [Link]

Any news about the Google/Motorola patents?

Can Google just refuse to license their H.264 patents and sue everyone shipping H.264 products, unless the MPEG-LA is disbanded, and all their video compression patents and mobile device patents licensed for free forever to everyone?

Most/all the H.264 patent holders seem to sell actual products using it, so perhaps this could really either free H.264 or kill it?

Mozilla reconsiders H.264

Posted Mar 22, 2012 4:08 UTC (Thu) by AndreE (guest, #60148) [Link] (6 responses)

I would really like some information as to failings of WebM. It would nice to have some analysis. Is it seriously lacking with respect quality/utilization/power? Was MPEG-LA correct in asserting that it is also patent encumbered? Basically, why did Google back down?

Mozilla reconsiders H.264

Posted Mar 22, 2012 7:45 UTC (Thu) by alankila (guest, #47141) [Link] (1 responses)

WebM might have been bought and developed as a strategic weapon, to be deployed if necessary. Holding control of the codec used over one of the most important video sites on the Internet certainly gives you some leverage. Perhaps it was done merely to ensure that demands from the H.264 patent holders would be limited from above by the cost of performing full-on switch to WebM.

Mozilla reconsiders H.264

Posted Mar 22, 2012 10:15 UTC (Thu) by AndreE (guest, #60148) [Link]

If it was bought for that purpose, why the huge fanfare about it being patent and royalty free and about support open web standards? Why the promises re Chrome? Google buy plenty of technology for strategic purposes and to build up their patent portfolio and aren't shy about it.

It seems pretty clear that the initial plans have changed, and it would be nice to hear more from Google.

Mozilla reconsiders H.264

Posted Mar 22, 2012 9:03 UTC (Thu) by Seegras (guest, #20463) [Link] (1 responses)

They can assert what they wish; be it for WebM or for H.264. Unless a court decides it's valid, the whole point is moot. And since software patents are patents on math anyway, they are invalid everywhere, even in the USA. It's just the question of when the courts will realise this.

Mozilla reconsiders H.264

Posted Mar 22, 2012 10:04 UTC (Thu) by AndreE (guest, #60148) [Link]

I'm talking about the realities of the situation. Patents are being granted, licensed, and upheld right now as we speak. Let's not pretend they are irrelevant

Mozilla reconsiders H.264

Posted Mar 22, 2012 10:14 UTC (Thu) by AndreE (guest, #60148) [Link]

It seems pretty clear that the initial plans have changed, and it would be nice to hear more from Google.

Mozilla reconsiders H.264

Posted Mar 22, 2012 11:48 UTC (Thu) by slashdot (guest, #22014) [Link]

H.264 is technically the best codec overall, and has the best existing encoder overall (x264) and has the most hardware support.

That's fundamentally why people use it.

The ideal outcome is somehow neutralizing the patents, not replacing it with something else, since that's going to be worse.

Mozilla reconsiders H.264

Posted Mar 22, 2012 6:14 UTC (Thu) by cmccabe (guest, #60281) [Link] (2 responses)

Lately it seems that Firefox has been making the exact same decisions as Google Chrome, but trying to execute them with less money and talent. This doesn't seem like a recipe for long-term success.

The should figure out what makes their project actually different than Chrome and focus on that. Making principled decisions about codecs and privacy issues could be one possible avenue.

Mozilla reconsiders H.264

Posted Mar 22, 2012 10:20 UTC (Thu) by smurf (subscriber, #17840) [Link] (1 responses)

If you want to make principled decisions about codecs, then do them right.
This means that you either support H.264, or you don't.

If you do, you can do it half-assed – via a Flash plugin that's full of security holes and tends to crash the browser, or you can do it right – via OS support.

If you don't, then don't. Period. However, DownloadHelper and mplayer et al. are available for those who want to see the video, regardless of what Mozilla says. So is Chrome. Thus, the only outcome of adhering to The Principle is to further inconvenience and/or alienate users.

The current situation (pseudo-support via Flash) is an ad-hoc mess which follows no principle whatsoever.

Mozilla reconsiders H.264

Posted Mar 25, 2012 15:04 UTC (Sun) by drago01 (subscriber, #50715) [Link]

via a Flash plugin that's full of security holes and tends to crash the browser

This cannot happen with any current browser, (the plugin runs in a separate process). Besides there are a lot of sites that support flash and only flash.

Mozilla reconsiders H.264

Posted Mar 26, 2012 12:08 UTC (Mon) by meyert (subscriber, #32097) [Link]

So what's the difference to the old bug https://bugzilla.mozilla.org/show_bug.cgi?id=422540 ? Will finally a gstreamer support arrive for Firefox? Hopefully yes!

Mozilla reconsiders H.264

Posted Mar 29, 2012 20:14 UTC (Thu) by Zizzle (guest, #67739) [Link] (1 responses)

This definitely changes the way I see mozilla.

All the stuff on www.mozilla.org about believing in "free, open and accessible to all" is just lip service.

If market share is actually threatened, then all that quickly goes out the window.

Market share is more important than their principles.

I'm not even sure I want them to succeed if that is now their approach.

So what happens in the future if mozilla decide that selling my browsing habits will be good for their market share?

How will mozilla resist H.265 with a straight face given they caved on H.264? Or any encumbered codec for that matter.

What about DRM video, will mozilla cave in on that too? Only after the other guys have?

What will this mean for linux users? The distros won't be able to legally ship H.264 codecs in a lot of the world. So there is no OS level codec to hand off too. Mozilla won't buy a H.264 license (or at least probably can't get one that covers open source and all downstream) and so can't ship it themselves.

Desktop PCs have video codecs in HW these days, but ATI/NVIDIA etc. are too scared to release doco, so the free video drivers can't expose that capability.

And what does this say about HTML5. Supposedly meant to free us of the proprietary and buggy flash player. It seems post-flash player, linux users won't even be able to legally watch most web video.

And does that mean you can't even implement HTML or a complete web browser in software while being open source?

Linux will be a second or third class citizen of the web?

Maybe only proprietary OS vendors (Apple/MS) and advertising platform vendors will be the only ones able to implement a complete web browser from now on.

Mozilla reconsiders H.264

Posted Mar 31, 2012 7:53 UTC (Sat) by roc (subscriber, #30627) [Link]

The goal is to make the Web better, not to have principles for their own sake. Having "principles" but no market share and no influence on the Web would not be a success. Likewise, if sticking to a "principle" has no effect other than harming Mozilla and Firefox users, there is no point in sticking to it.