Apple-centric observers weren't the only ones to get the facts wrong, and phrasing like that title is only used to make a point. This implies that non-Apple-centric observers got the facts right. I don't know about you, but I'm not an "Apple-centric observer" and I had no idea H.264 wasn't free.
And since I'm one of many, then the goal of this article was either to a) notify Apple-centric observers that H.264 isn't free and/or b) point out to everyone how biased Apple-centric oberservers are, how they just eat up everything Steve Jobs says, and high-five non-Apple-centric observers for being so coolheaded, rational, and informed. And since "Apple-centric observer" is clearly a codeword for "Apple fanboy," the implication here is essentially "smart people don't like Apple" or worse yet "if you like Apple, you're stupid."
This is just flamebait disguised as news. Fanboys accusing fanboys of fanboyism. Move along, nothing to see here.
Oh dear... I understand the good intention, but I think the author has got a lot wrong.
All these talk about Safari being the only roadblock...
First: Internet Explorer is apparently fine because Microsoft supports it via separate coders... but that's exactly what Apple does too. Safari simply uses whatever is installed in the OS.
Second: I'd be surprised if Safari, the forth browser online with something like 5% of the market could actually force anything. This is not IE6 that we are talking about!
It's Mobile Safari with its impressive mind/marketshare and total lack of user customizability that's the main battleground here. (Though luckily most of the iDevice installed base can only cope with baseline H.264.)
Safari on Mac OS X will pick up WebM decode as soon as Perian auto-updates to it. Perian (basically ffmpeg for Quicktime) being one of the must-have installs on Mac OS X in order to play any video/audio codecs and containers outside the blessed subset that Apple chooses to support.
What does Blackberry use then? Or what will Windows Phone 7 use? And WebOS? (I am asking seriously)
I think in the mobile realm you can't blame a company for not supporting a format without hardware acceleration. Now, once the new chips arrive with WebM acceleration, and someone doesn't support it then sure, I agree that sucks.
Apple's the only manufacturer that seems to make a selling point out of not shipping tools that users can shoot themselves in the foot with.
A perfect example is mobile Flash, which is (or soon will be) a major selling point of basically all non-Apple mobile devices and runs lots of legacy VP6 video without hardware acceleration. And Adobe has committed to supporting VP8/WebM in future Flash versions.
Ok. First I think the jury is still out if it will be a major selling point or not. Maybe you are right, maybe you are not. It seems a bit premature to use such adjectives.
Second that is true about Apple. But that's their philosophy: I am sure if Firefox can have their own philosophy so can Apple. They like things that work, and work well (though sometimes they fail, as shown by the antenna problem). I don't see any reason why Apple wouldn't include WebM support once its hardware is capable of decoding it in hardware.
But if your argument is that Apple should implement WebM despite it being much worse for mobile simply because otherwise Firefox can't join in, then I think you are asking a bit much.
If it hardware acceleration weren't important for the battery then I would agree with you that Apple should implement WebM pronto (while still keeping AVC). As it is, I think there are not clear rights or wrongs, and it's up to each company to decide what they think we'll be best.
> Perian (basically ffmpeg for Quicktime) being one of the must-have installs on Mac OS X in order to play any video/audio codecs and containers outside the blessed subset that Apple chooses to support.
Or just not using QuickTime Player, which was basically mandatory in previous versions as QuickTime Player rather sucked balls (QuickTime Player X is pretty big improvement over the Player 7 so it's a viable option)
I don’t think it’s such a big drama. My prediction would be that h.264 will continue to dominate in the next years, either displayed using Flash with a HTML5 fallback (for mobile Webkit browsers) or the other way around, depending on how that whole Flash thing turns out. Heck, that’s not even much of a prediction, that’s pretty much reality right now. What Firefox does or doesn’t do doesn’t matter, the next changes will only come with the next generation of codecs.
OS X and Windows have licensed encoders, right? Is it possible for Firefox and others to use those on OS X and Windows and use a less-than-legal decoder on Linux as is, AFAIK, done for MP3s and DVDs?
The first time there is an exploit in system-provided video decoder (any decoder, not just H.264), you can be sure, who will get blamed for that - the browser, of course. So any browser maker wants to make sure, that they can update anything, that is being touched by web.
In case of Apple and Microsoft, they both can update the system provided H.264 decoder. In case of Opera, Mozilla and Google, they can not. This is one of reasons, why all three browsers bundle their own decoders (the another one is multi-platform consistency).
I think there's a certain irony in this. Isn't FOSS a big proponent of these sort of dependencies? I mean, whenever you discuss Windows or MacOS way of installing software, you'll hear how Linux does it better because each component is separate and therefore they can fix something upstream and your software will automatically use it.
But suddenly now people complain because a piece of software doesn't have control of their pieces...
How are these two views consistent?
(incidentally: I like the Linux's way, and try to replicate it as possible with Macport).
I think this has more to do with GNU/Unix design philosophy rather than being an explicit part of FLOSS ideology.
Also, you need to remember that GNU/Linux projects do have a certain amount of control over upstream, seeing as the source is publicly available and can be forked/modified. On the other hand, if Firefox relied on proprietary software, they would be completely at the mercy of decisions made upstream.
Do you think so little of the vendors that you believe they won't want to fix an error in a widely-used security-critical OS component?
Do you think so little of the ability of the Mozilla team to communicate on the details on a matter of platform security?
When programming anything, you have to decide what components you're going to depend on, and what you're going to write and maintain yourself. On a codec, or C library, or whatever.
And if there are issues with the foundation, then applications will have issues. Other applications will have issues, too.
And if you're rolling your own code for common tasks, there will still be issues. You'll all of them, too. And you'll have a much larger project.
> Do you think so little of the vendors that you believe they won't want to fix an error in a widely-used security-critical OS component?
Considering he never said that... no?
> Do you think so little of the ability of the Mozilla team to communicate on the details on a matter of platform security?
Pointless, that'll still get them blamed.
> And if you're rolling your own code for common tasks, there will still be issues. You'll all of them, too. And you'll have a much larger project.
You have a larger project but you control all the variables, or as many as you can anyway. And you can handle everything on your schedule, you don't have to depend on a third party which may or may not play ball with you (and may have absolutely no interest in playing ball).
> How are they doing now with Flash? Any record of users complaining with Firefox for a Flash bug?
Uh yes? Users complain about the browser when Flash crashes it, why do you think Firefox finally moved Flash to an external process, following the lead of Chrome and Safari (and MSIE?). Sure Flash having no 64b support plays a role, but it's not like most users realize it when Flash is involved in making their browser burst in flames or crawl to a halt.
Sorry, I meant security bug, not crashing in flames bug. :)
Often you hear of some security flaw in this or that program that requires Microsoft or Apple to patch the OS. When those happen, are people demanding a fix from Microsoft/Apple or Mozilla?
The first time there is an exploit in system-provided video decoder (any decoder, not just H.264), you can be sure, who will get blamed for that - the browser, of course.
Is this really the case? Aren't there security flaws in platform code all the time that affect browsers along with other apps on the platform? Are those blamed on a specific browser? If both Firefox and Safari use Mac OS X's built-in h.264 and there's a hole in it, is there going to be significant widespread outrage against Firefox?
Err, I fail to see any bug in the in the Windows 'shell:' protocol handler. But other parts of the article indicate that the bug was in Firefox and was fixed in there.
>Current versions of Mozilla and Firefox pass unknown protocol handlers to the operating system shell to handle. In this case, the location passed to the shell is a program name that the shell executes.
>Internet Explorer is reported as being less vulnerable. When the user clicks on the link, it opens an "open/save" dialog box in which the user is allowed either to run the program, save it to disk or cancel. Mozilla and Firefox simply run the program without any further user action.
OS X and Windows have accelerated H.264 decoders that are available to programmers. Firefox is an application on each of these platforms. Firefox can use the native decoders like every other developer. They are already using a third-party's H.264 license (Adobe with Flash) to play this sort of video on many sites. I have a hard time seeing why using Flash is any different than using the built in.
For platforms that haven't paid the license, leave a plug-in way to do it and let others fill it just like they are letting Adobe do now.
It would be possible for Firefox to do use the system video codecs. This is the approach Microsoft has chosen to go with for IE9. Mozilla has chosen not to do this partly to prevent h.264 in Firefox from catching on, but also because doing so would surely lead to to the same problem as before: Requiring end users to install things to play video. We're back in the codec nightmares we had that flash replaced when people stopped using <object> and <embed> for video on web pages.
They originally were going to only use H.264, and only provide IE9 on operating systems where they themselves had provided the H.264 codec (Vista & 7).
They've since committed to supporting a user install of WebM but I've seen no technical details of how this will pan out e.g. what if you install more than one WebM codec from different sources? They have been clear that no other codecs (e.g. DivX, WMV, Dirac, Theora) will be picked up regardless of built in support or user installation.
As you rightly note Mozilla, particularly on XP which makes up about 60% of their user base, would be relying on god knows what kinds of codec packs that users have acquired over time, a known malware vector and so bundle their own codecs.
The "vectors" aren't installed, vectors are the way that they get installed. Training people to install codec packs when prompted in order to see a video is considered risky, since the next time they see a similar message it's likely to be someone up to no good.
My impression is that everyone will have support for h.264 on the computer anyway (it's such a common codec). And even if they don't WebM could be used as a fallback. There is no reason why we could not have support for both, and Firefox will only support h.264 via the OS.
Realistically Firefox will play H.264 via Flash just the same as IE 6, 7, 8 and so will play any video on the net (including those in old Flash formats) till those 3 browsers collectively drop below 5% or so. By which time the conversation will be about H.26_5_ and a royalty-free successor to VP8.
The solution is that IE 6, 7, & 8 won't load Flash for the HTML5 video tag either, so the same Flash fallback (probably delivering the same H.264 file given to HTML5 browsers) works for all of these highly popular browsers which currently account for something like 80-90% of all browsers between them.
Firefox only has to worry about niche, tech-forward sites that feel they can disregard all pre HTML5 browsers and also actively choose to ignore Firefox (and Opera) as well by not providing a WebM fallback video. No ordinary business can afford to simply refuse to deliver a Flash video to 1/3rd of their audience when they've already built it and are serving it to another 1/3rd on older version of IE. (This obviously occurring at some future time when the HTML5 video delivery is preferred over Flash for any platform other than the Apple ones that don't have Flash, otherwise the Flash would be going out to 99% of browsers anyway).
There's not much downside for Firefox except pissing off people who really passionately hate Flash, but are quite happy with H.264's patent situation. I'm thinking the crossover is pretty small on those two populations and probably shrinking greatly now that Apple has let Adobe use their hardware acceleration API for H.264 decode, certainly not big enough to derail a browser used by tens of millions of ordinary people.
The whole codec discussion instigated by the Mozilla Foundation is so mind-numbingly odd that it makes me cringe. I fully understand the arguments that creating a completely free and open source web browser is an important and non-negotiable goal. Nevertheless the (non-existent) dilemma relies on the false assumptions that:
1. Deciding on a single codec that everyone should use for everything, forever (or until we get to have the same discussion again with HTML6) is the only way forward. Which is just stupid and ignorant. Different codecs are good for different use cases. There is no "one true codec"and there never will be. H.264 is a good all-around video codec for hi-def internet video, which is why it is popular on sites like YouTube, etc.
2. "Support" does not have to mean including code in the Firefox browser for decoding H.264 video. It simply means that the browser makes a best effort try to play the video. That's all that the end user really cares about, and that is easily accomplished by using the codec frameworks already present in most modern operating systems. Webkit uses Quicktime to play media on OS X and thus supports all formats that Quicktime supports, for example.
> Which is just stupid and ignorant. Different codecs are good for different use cases.
That's irrelevant, any codec(s) has to be implemented across the board or everything's broken. That's the point. There are basically 3 image formats at this point, but everybody supports them. If half the browsers only supported GIF and the other half only supported PNGs (and nobody supported JPEG at all), displaying image would be a chore.
And it's not like recompressing images is a big deal, that can be automated and takes a fraction of a second for most images. Compressing video on the other hand... takes hours and quite a bit of fiddling with a dozen of mind-numbingly boring compressor options to get the best bang for your buck.
> That's all that the end user really cares about, and that is easily accomplished by using the codec frameworks already present in most modern operating systems.
Yes, and now your cross-platform browser has widely different behaviors from one platform to the next, fantastic.
But most browsers will support all of them: Safari and IE will use whatever is in the OS, and Chrome supports both.
Only Firefox (and Opera) has decided not to support AVC.
To me Firefox sounds like they want things their way and they can't compromise in any form. They won't use whatever is installed in the OS, nor will they include a codec they have to pay for. If they wanted they could implement it as a plug-in, and then FOSS people will be able to use it like they use Flash.
It seems Firefox can't choose between compromising on either principles (be that free software, or no external dependencies) and therefore is forcing everyone else to adapt to them.
> Only Firefox (and Opera) has decided not to support AVC.
And Chromium. Because Google's h.264 license only covers the Chrome they distribute themselves, which leads us to...
> To me Firefox sounds like they want things their way and they can't compromise in any form.
They don't have the money to pay for it, and even if they did the money would only cover Firefox distributed by the Mozilla Foundation themselves in binary form. Which means for instance that no unice out there would be covered (neither linux nor BSD) as they pretty much all repackage upstream and each of them would have to pay for its own license. So that option is dumb, to start with.
As to the OS stuff, as I said above that implies the capabilities of firefox would be widely different depending on the OS and its precise configuration. Not to mention most of the Firefox userbase is still on Windows XP, which doesn't get Microsoft's built-in h.264 support.
Nobody compiles Chromium that way — it has a dependency on libavcodec (ffmpeg), and everyone just links it with the version already installed on their system.
If you're a freetard running gNewSense, you'll only have support for WAV, Vorbis, and Theora in OGG containers. Everyone else will have support for every codec under the sun.
I find that hard to believe. They get a whole bunch of money from Google and last known, were paying their CEO about $500k an year even in the days when they were asking donations for the NYTimes ad.
"Deciding on a single codec that everyone should use for everything, forever (or until we get to have the same discussion again with HTML6) is the only way forward. Which is just stupid and ignorant."
Mozilla never dictated that there should _be only one codec_. It's my understanding that they are happy to support any coded, which is not encumbered by patents.
You're putting words into their mouth, which they never said in this form.
Not quite. Mozilla was one of those pushing for the HTML5 spec to require support for Ogg Theora. Fortunately, saner minds prevailed and explained what a stupid thing it would be for a spec with an expected lifetime of a decade or so to mandate a 2009-era (when this first started being an issue) codec.
However, because they have that stipulation, instead of having championing for the browser to use any and all OS codecs, they have declared that only Theora and WebM shoul be part of the standard.
Actually, they just wanted Theora (now WebM) blessed as the one codec you knew would always be available. They were quite happy for "better" codecs to be provided in specific circumstances as long there was a baseline that would be guaranteed to be supported everywhere. It was Apple & Nokia that pushed for only one codec (namely H.264, which coincidentally couldn't be mandated as part of the standard and implemented everywhere because of patents).
Firefox does not support OS provided codecs. Not that it's not possible, but they don't. Regardless of what Apple/Nokia do, Mozilla is very much pushing to not support h264.
If they were being open about it, we'd already be able to do it.
Apple-centric observers weren't the only ones to get the facts wrong, and phrasing like that title is only used to make a point. This implies that non-Apple-centric observers got the facts right. I don't know about you, but I'm not an "Apple-centric observer" and I had no idea H.264 wasn't free.
And since I'm one of many, then the goal of this article was either to a) notify Apple-centric observers that H.264 isn't free and/or b) point out to everyone how biased Apple-centric oberservers are, how they just eat up everything Steve Jobs says, and high-five non-Apple-centric observers for being so coolheaded, rational, and informed. And since "Apple-centric observer" is clearly a codeword for "Apple fanboy," the implication here is essentially "smart people don't like Apple" or worse yet "if you like Apple, you're stupid."
This is just flamebait disguised as news. Fanboys accusing fanboys of fanboyism. Move along, nothing to see here.