Monday 25 January 2010
ActiveX All Over Again
Many responses to my post about video codec issues have expressed the opinion that "Mozilla should do whatever is most useful for users today, regardless of 'politics' or 'ideology'" and also that "if a user already has codecs on their system, it's wrong for Mozilla to refuse to use them". These opinions fail due to various legal and technical issues that I've already discussed, but I also want to point out that taking such positions is nothing new for Mozilla and history has proved us right for doing so, in particular regarding ActiveX and Web standards in general.
Perhaps it's not widely known, but Gecko has had code to support hosting ActiveX controls, dating back as far as 1999. ActiveX controls are very much like system video codecs. ActiveX support would have been very useful to users ever since 1999, and still would be now --- certainly in corporate intranets, and everywhere in China and South Korea. Enabling ActiveX support would probably boost our market share significantly. Most users have useful ActiveX controls on their machines. But for the last ten years, even during Mozilla's most desperate days, we have consistently refused to turn this feature on, because we believe that ActiveX is not good for the Web.
I think history has proved that this decision was completely right. Our market share rose anyway. The ActiveX ecosystem was a big vector for security attacks. Most importantly, if we'd caved, the Web everywhere would look like it does in China and South Korea, but more so --- dependent on ActiveX, and tied to Windows. No resurgent Apple, no Linux netbooks, precious few Linux users, no ChromeOS, no iPhone, no usable browsers on phones at all, and Microsoft's grip on the industry stronger than one dare imagine. We would have sacrificed huge long-term wins for users --- ALL users, not just Firefox users --- for the sake of a temporary filip.
During the ascendancy of IE, we had similar pressures over the issue of whether to follow Web standards or focus on IE compatibility. The "pragmatists" wanted us to focus on IE compatibility for the very sensible reason that authors had to develop for IE anyway, so it would be easier and cheaper for them if we just fell in line. Obviously pursuing IE compatibility would also have been good for our market share --- and our users --- at the time. We chose standards. Again, I think history shows we made the right decision.
I'm not suggesting that the consequences of exposing system codecs to the Web would be identical to exposing ActiveX. That's unlikely, and unknowable. But favouring our principles over short-term gains for users is nothing new for Mozilla, and when we've done it in the past, history shows it was the right thing to do.
Comments
1) Would you use/implement H.264, if MPEG-LA wouldn't require licensing for decoding (no fees, free implementation)?
2) What will you (Mozilla) do to make Theora/Ogg better. How do you want to improve quality/bitrate ratio and the issues with hardware en-/decoders?
"Free" won't impress much people, but "better" will! And Firefox was and is better than Internet Explorer. But will Theora/Ogg be better?
steve
If I have to stick to the demonized proprietary formats I'd better do it in the browser I choose at least.
Eventually Youtube will give up on it (since most requesters for HTML5 video were linux/OSS advocates/hippies/flash haters, it can happen, but not warranted. The Youtube support page for the topic is full of "WTF" comments) or a way to add the codecs to firefox will arise, even as a hack or fork.
Unlike DirectX, however, this has a solution (sticking to flash) so I don't think this case can become such a part of history, personally...
This is totally off topic, but it has bugged me for a long time. The 3px wide black column dividers are very heavy and distract from your content.
Please consider something like
.colums {
-moz-column-rule: 1px solid #ccc;
etc
}
Jim: done!
DirectShow on Windows
Quicktime on Mac
and GStreamer on Linux
Wouldn't that allow you guys to get around having to pay license fees?
and thanks to Firefox 3.6 you guys could push this without a large update, plus this would make a nice temporary fix until a more HTML5 worthy codec springs up.
To which I guess the counter-argument is "there's no point having principles if you abandon them when the going gets tough".
This is especially relevant for Christians like me, because God is a potential source of unexpected blessings.
However, as I said in comments in my other post, there is point short of total annihilation where it would make sense for us to compromise our principles. We're nowhere near that yet.
2. H.264 _is_ a standard. (unlike Flash)
3. You already use any number of parts of the operating system you run upon, why not treat video as just another part (you'll use the OS's own text rendering or TCP stack, but not its licensed support for a standard?)
I'm still having a hard time understanding the problem.
2. Yes, H.264 is a standard, but being a standard isn't enough to make it good.
3. Free, unencumbered implementations of text rendering and TCP exist, so our principles are not at risk.
don't get me wrong. i agree that h264 is a bad idea. but not for exactly the same reason.
the only reason h264 is bad, is that it enforce a vendor lock-in due to licensing. it's simple, if you want to make a HTML5 youtube copy, to stream in the USA (and you want that), you'd have to pay billions of dollars JUST for the "fucking video codec".
likewise, if you want to make your own player, except it will be thousand of dollars instead of billions (which you won't be able to pay in both cases = lock in, everyones forced to use an iphone and youtube for HTML5 stuff yay.)
It would be nice if they'd make clear whether they have some Theora-related plans for the future, but whether they intend to go that direction or not, offering HTML5 for the millions of video files they already have is hardly unexpected.
As it stands, I have heard and seen the discussion on the indexing issue and others areas of the format. Many have not, and assume that the Theroa project is dead due to a perceived lack of communication (As much as you and I read the mailing lists, many others don't) and site activity.
I would really like to see Xiph start talking more... if possible.
It is also my enthusiasm for the free web why I contribute, which I should do more often again.
I saw you answered "If decoding was unencumbered but encoding still required licensing, I think we'd still try to resist it,".
I have a similar, but slightly different question: what if encoding and decoding in software didn't require licensing, but encoding (ev. decoding) in hardware did. In that case, would it be ok for Mozilla to implement it?
I'm thinking about it because that way the MPEG-LA could still earn money with it (via hardware manufacturer like now) but all software would be free of licensing.
Why didn't Mozilla turn off GIF display?
Plus, it doesn't make sense to take a stand that completely destroys the usefulness of the browser.
If this is the case and this will be a non-issue in few years, then IMO it seems this is being blown out of proportion and after all it's only fair for the Moving Picture Experts to get paid for their expert work. This slow development of everything surrounding ogg/theora just seems to say "free doesn't pay for the plumber/food". I bet the development would accelerate if you could buy more experts to develop the free alternative. I suggest starting with getting ogg/theora radio/video streaming work from WMP if they're not already (they're not last I checked) because as a user I want the freedom to use my preferred player that comes with the OS and not install some one more 3rd party player for each codec to work around some specific bugs (eg. mkv vfr bugs in VLC).
Or what do I get wrong?
In one of your previous posts, you mention that this approach is a problem in the case of windows : malware can be embedded in video codecs. Fair enogh.
But i.e. on Ubuntu, at first attempt of playing a patent encumbered video, the system will download "ugly" packages automatically after a proper warning to the user.
If the user said OK to that warning, he should be able to play those videos in Firefox as well. Mozilla would be protected against legal issues because the download is performed by the OS, not the browser.
You mention "idealism" as a reason for the current status. But in my opinion, idealism is more about the client design : video decoding is an OS thing, it should be treated at OS level.
如果说增加对ActiveX的支持,会增加在中国市场的占有率,那说明你不了解中国市场。
Our organization is about to put a lot of content on the Web. I'm going to argue that it MUST be in a standard format. If anyone wants to view it, they can view it with Firefox. And if they don't want to view it, that's their problem.
https://wiki.mozilla.org/Gecko:Layers
Directly references Core Animation, including it's organization of layer trees and transactions, you should be aware of Apple's patent application in this area:
http://www.google.com/patents?id=p9qnAAAAEBAJ
Which is basically a patent on Core Animation and a system organized like this.
have fun.
But, definitely doesn't make any sense comparing support to ActiveX with support to play H264. This doesn't make any sense to me.
We've never been in a situation where we could drop support for Flash without driving away most of our users and becoming irrelevant. Doing that would not help our mission. That's probably the primary reason why we've never even considered it AFAIK.
Reducing use of Flash on the Web is a much, much larger project than dealing with the problem of encumbered codecs accessed via the tag. The first step is to ensure we can offer Web authors standards-based functionality as an alternative to Flash. We are working very hard on that!
webuser: that would be very difficult. However, producing your own Firefox derivative browser which supported those codecs would be doable. That's what free software is all about.
nicoO: I've talked in several places about how moving the problem down to the OS is not a good idea. I do agree that if we were to support system codecs, GStreamer on Linux would be the least problematic platform.
cjwl: just the fact that a patent exists isn't necessarily a problem. A patent is a problem when someone is going to threaten us with a lawsuit and demand licensing. If they aren't, we can ignore it. The problem with H.264 is that everyone is expected to pay license fees to the MPEG-LA or get sued (unless they're too small to bother with; we aren't). Patents aren't a problem if we don't need to license them, which is why the GIF patents weren't a problem for us.
In general I'm not particularly concerned that Apple would demand licensing from free software projects. That would trigger a firestorm of negative PR, freak out a lot of their own employees, and cripple their relationship with the free software community, which they depend on in many ways. As far as I know, they haven't done it.
I didn't look at the Apple patent, but in general it requires detailed comparison of the claims with our code to determine if our code would actually infringe, so it would be unwise to jump to a conclusion that that patent bears on what we're doing. For what it's worth, there are other frameworks that work in a similar way, for example Clutter, and Microsoft's WPF (which probably predates Core Animation).
I agree with what you say, but how exactly is NPAPI different from ActiveX? It's the same thing. You visit a page that needs a proprietary, closed-source plugin. You download and install it. What makes these plugins better than ActiveX ones? The fact that they're available for a different plugin architecture?
Let's not pretend the web today is plugin-free. Unfortunately you are in for a world of hurt without Flash, and chances are you'll need to use Java some day. The other ones are easier to replace as they're just a way to open documents in the browser (what a stupid idea) and compromise security (if I had a dime every time a shady ad network triggered a PDF download... I don't want to think what would happen if I had that plugin enabled).
Same for the video thing: instead of installing a codec, they'll just install a plugin (which is worse, as it implicitly has more code, which means more attack surface, worse integration and worse stability).
To reiterate I agree with the message but I find a bit hypocritical calling on ActiveX or other such mechanism to execute opaque binary closed-source stuff inside the browser, when every browser starting with Firefox happily supports it.
"But for the last ten years, even during Mozilla's most desperate days, we have consistently refused to turn this feature on, because we believe that ActiveX is not good for the Web."
I first want to correct that. I don't think it's true. IIRC, there was a time (several years) where we shipped with activex enabled and maybe even whitelisted a few ActiveX components, but never allowed all by default. I might be mis-collecting this, though, or confusing it with the Netscape browser.
More to the point, I don't think that the situation between enabling ActiveX and allowing MPEG 2/4 specifically (which I asked for) is anyhow comparable.
1) MPEG is an ISO standard, not a vendor API.
2) MPEG is not limited to a certain platform nor implementation.
3) Enabling MPEG codecs would be selective. It's not the same as enabling any and all system codecs or system APIs.
4) The security risk is opening a file (MPEG) vs. allowing hostile code to call your API (ActiveX).
Another important difference is NPAPI is platform-independent. You can build NPAPI plugins and browsers for any platform with no dependencies on any particular platform functionality or framework. ActiveX, however, depends very heavily on COM, which is a huge Windows-only framework.
Another important difference is that ActiveX was designed based on VBX Visual Basic controls, so from the beginning there was a large ecosystem of Windows-only ActiveX controls, and of course since Microsoft was the driving force behind ActiveX, they kept building more Windows-only ActiveX controls. ActiveX was never pitched as anything but a Windows technology. On the other hand, in the NPAPI ecosystem people were building plugins for Mac and X from the beginning.
Having said all that, dependence on closed-source NPAPI plugins isn't a good situation either. Just a lot better than ActiveX.
As I said in the final paragraph of my post, I am not trying to draw a direct analogy between ActiveX and supporting system codecs. I am merely pointing out that denying Web access to code on your system is not unprecedented for us, and history shows that at least in some cases it's been good for the Web.
Actually, I think you're in for a world of hurt, if you do install Flash. I've tried it for a moment, and was disgusted by the Flash ads, I couldn't stand it anymore.
I am doing just fine without Flash. Apart from videos: YouTube and others on news sites and similar. Thus, I'd be happy if I could play videos right in my browser, on the 2-3 websites where I run into videos.
(And to avoid misunderstanding: I was also always strongly against ActiveX. I am also very much against closed formats.
The "only" problem with MPEG are patents - and whether software patents are legal at all is still an open debate.)
That's why I filed bug 541286 ;-).
> history shows that at least in some cases it's been good for the Web.
Unquestionably. I agree with the general stance, too.
Too bad the W3C pulled back from their Theora recommendations at the pressure of big companies.
Why does Google use H.264 (Youtube, Android)? You'd think they'd want to save money, at least...
What I do not like, and believe to be contrary to Mozilla's goal of being open and making the Internet a better place, however, is the fact that there's no way to extend the decoders available. With image decoding, this is theoretically possible - I had a JavaScript based imgIDecoder a few years back (too slow to be practical, but it was possible), as well as a C++ based one that actually functioned for an obscure image format. There's no possibility of that here; nsMediaDecoder is completely internal, and the list of possible decoders is statically coded in nsHTMLMediaElement::CreateDecoder.
Extending Mozilla in ways that Mozilla doesn't have energy for is what makes the platform - both Gecko and Firefox - awesome. Please make <video> awesome by opening the gates to external, non-libxul, programmers?
P.S. Somehow your comment preview manages to clear the text entry box, so once you preview you lose the post!
As noted before, h.264 is what youtube was already encoded in before Google bought Youtube. Takes time/money/space to convert, so it's something that they'll have to work on over time.
"More to the point, I don't think that the situation between enabling ActiveX and allowing MPEG 2/4 specifically (which I asked for) is anyhow comparable.
1) MPEG is an ISO standard, not a vendor API.
2) MPEG is not limited to a certain platform nor implementation.
3) Enabling MPEG codecs would be selective. It's not the same as enabling any and all system codecs or system APIs.
4) The security risk is opening a file (MPEG) vs. allowing hostile code to call your API (ActiveX)."
And the biggest issue right now is that the big content sites (aka youtube) have gone with the "commercial" codec. And as long as they're targeting devices that require hardware offload chips to play the content, they're going to stay with h.264. No-one is making a Theora decode chip to put in cell phones, netbooks, tablets, set-top streaming media players, etc. and they aren't putting in enough CPU power to handle HD content either. The sheer amount of h.264 stuff out there already means you are going to have to co-exist with it (not just YouTube/Vimeo, but most BluRay disks, iTunes video stuff, AVCHD camcorders, ...)
I don't care.
Sure, I WANT Web developers to use open standards. However, they don't.
If I see a site that I can't view in Firefox, I'll open up Safari or Chrome, not write a 300-page manifesto about Theora.
Denying users access to their own codecs is biting off the nose to spite the face.
Plus, if you're really that into not supporting proprietary standards by any means, disable Flash and THEN we'll talk.
Couldn't you just turn it on, but bury it deep in about:config so only people who really don't care about Theora turn it on?
Are you sure about that? AFAIK Youtube content was VP6. They converted to h.264 sometime later either when it was first supported by Flash (perhaps when they started offering higher 480?) or perhaps to offer it to mobile device like the iPhone. It's possible Youtube always had h.264 in the background but I'm not convinced. I do believe they had to reencode most of their videos when they switched to h.264. (I presume they stored the original videos and used these as sources hence the reason they were able to add higher res to long existing videos, makes the most sense to me.)
Incidentally I wasn't aware until researching stuff for this post but Google now owns On2. If they wanted to, they could contribute whatever patents On2 has to the open source community. Since Theora is based on VP3, even if On2 granted related patents I wonder if there's some new stuff from their later developments that may be useful. Of course they could also open source all the other codecs (along with the patents as I already mentioned) and perhapds something there could be a new Xiph codec. I'm personally still unconvinced Theora is ever going to come close to VC-1 let alone h.264 which makes problems for it trying to gain a foothold given the widespread usage of these codecs including with hardware support. If they had something closer, they may fare better. I've had some hope for Dirac, but perhaps VP8 would be something to look at too.
Of course I'm not convinced Google is actually going to do something like that. And even then, lacking the vast patent portfolio that's behind h.264 I wonder whether they'll really get close.
P.S. It seems I'm not the only one to have this idea, I came across a FSF campaign.