There's a relatively simple solution to this that another heavy hitter in the FOSS world has been using for years: Prompt for a "restricted package" install when the user first encounters an h.264 video, similar to how Ubuntu deals with non-FOSS drivers, plugins, and codecs.
It's the best of both worlds; you stay free and you get to be compatible.
Mozilla links directly with liboggplay and actively avoids abstracting it in any way. It can't handle any non-ogm container formats, and ogm was intentionally designed not to handle any other codecs.
They're just assholes. If software patents are repealed in the US they'll mourn the loss of the mainstay excuse with which they force earnest activist wankery on their users. If patents were the real obstacle they'd distribute the x264 decoder to/from locales where the patents are unenforceable, and/or fall back on system libraries.
Their present actions serve only to strengthen the Copyright, Patent, and Trademark status quo, because without IP assholery they would neither have a soapbox to stand on nor an enemy to fight.
There are plenty of other containers, audio formats, and video formats that are believed to be mostly patent-free; the same status as Theora. Firefox won't support any of them. Not Dirac the video format, not Matroska the container format, not FLAC the audio format, and so forth. Despite the fact that, for example, Matroska is far better-designed, more capable, and more popular than Ogg.
Mozilla could care less about patents: all they want is to promote their pet solutions at the expense of everyone else.
The "ogm" file format is an old, unsupported, deprecated variant of the Ogg container. Do you mean "ogv"?
Sorry, this may seem like nit-picking, but such a fundamental mistake makes it harder to take your strong claims about Mozilla's design and intentions at face value.
I intentionally used it to avoid a similar riposte if I had said 'ogg', an even older and shittier container. I didn't know they had implemented a new one, but from what I can tell they took special care to recapitulate all the mistakes of the last one.
Technically, ogg, ogm, ogv, and oga all follow RFC 3533 and can legitimately be called the same file format, namely ogg. The only difference between all those extensions the codecs used; Xiph intentionally left the definition of how to map a given codec into ogg up to the codec.
Even simpler would be to just expose the native capabilities of the platform. Mac OS X and Windows 7 both support h.264 natively, and to my knowledge Mozilla has actively chosen not to use that support.
This is what I was wondering. If this is true that what we're talking about is linking against proprietary libraries that already exist on the user's machine, then I don't understand the argument against it. By the article's logic they should pull the plug on firefox for windows & mac since they are more "non-free" than h.264.
So using Flash/WMP/QT -plugin to playback video via <object>/<embed> -tags is OK but using native APIs to play <video> -tags is insecure and buggy. Riiight.
"Mozilla wants to encourage Web authors to use Theora"
That seems to be working so well. Really they're just encouraging users to not use Firefox. The user chose to have those codecs on their system - either by installing and OS that comes with it, or installing the codec itself.
Let the user chose what codecs they want to support.
Firefox won't use system codecs because they might be insecure, they might be buggy
This does not address the original objection. Calls to the Mac and Windows are not known to be any less buggy or insecure than calls to the h264 APIs. So why accept one and not the other? The only sane answer of course is that you can't build an app at all without calling the OS basic APIs of your host machine, but you can try to have an ugly work around h264.
RedHat did this, and I was very happy about it at the time, being involved with the Xiph.org projects. The users hated it, but I don't see how to educate users about this any other way.
Comments
There's a relatively simple solution to this that another heavy hitter in the FOSS world has been using for years: Prompt for a "restricted package" install when the user first encounters an h.264 video, similar to how Ubuntu deals with non-FOSS drivers, plugins, and codecs.
It's the best of both worlds; you stay free and you get to be compatible.
Mozilla links directly with liboggplay and actively avoids abstracting it in any way. It can't handle any non-ogm container formats, and ogm was intentionally designed not to handle any other codecs.
They're just assholes. If software patents are repealed in the US they'll mourn the loss of the mainstay excuse with which they force earnest activist wankery on their users. If patents were the real obstacle they'd distribute the x264 decoder to/from locales where the patents are unenforceable, and/or fall back on system libraries.
Their present actions serve only to strengthen the Copyright, Patent, and Trademark status quo, because without IP assholery they would neither have a soapbox to stand on nor an enemy to fight.
This is pretty much accurate.
There are plenty of other containers, audio formats, and video formats that are believed to be mostly patent-free; the same status as Theora. Firefox won't support any of them. Not Dirac the video format, not Matroska the container format, not FLAC the audio format, and so forth. Despite the fact that, for example, Matroska is far better-designed, more capable, and more popular than Ogg.
Mozilla could care less about patents: all they want is to promote their pet solutions at the expense of everyone else.
The "ogm" file format is an old, unsupported, deprecated variant of the Ogg container. Do you mean "ogv"?
Sorry, this may seem like nit-picking, but such a fundamental mistake makes it harder to take your strong claims about Mozilla's design and intentions at face value.
I intentionally used it to avoid a similar riposte if I had said 'ogg', an even older and shittier container. I didn't know they had implemented a new one, but from what I can tell they took special care to recapitulate all the mistakes of the last one.
Technically, ogg, ogm, ogv, and oga all follow RFC 3533 and can legitimately be called the same file format, namely ogg. The only difference between all those extensions the codecs used; Xiph intentionally left the definition of how to map a given codec into ogg up to the codec.
Mozilla doesn't want to give users the ability to choose proprietary codecs. You're getting "freedom" whether you want it or not.
Even simpler would be to just expose the native capabilities of the platform. Mac OS X and Windows 7 both support h.264 natively, and to my knowledge Mozilla has actively chosen not to use that support.
This is what I was wondering. If this is true that what we're talking about is linking against proprietary libraries that already exist on the user's machine, then I don't understand the argument against it. By the article's logic they should pull the plug on firefox for windows & mac since they are more "non-free" than h.264.
http://weblogs.mozillazine.org/roc/archives/2009/06/directsh...
Firefox won't use system codecs because they might be insecure, they might be buggy, and Mozilla wants to encourage Web authors to use Theora.
So using Flash/WMP/QT -plugin to playback video via <object>/<embed> -tags is OK but using native APIs to play <video> -tags is insecure and buggy. Riiight.
"Mozilla wants to encourage Web authors to use Theora"
That seems to be working so well. Really they're just encouraging users to not use Firefox. The user chose to have those codecs on their system - either by installing and OS that comes with it, or installing the codec itself.
Let the user chose what codecs they want to support.
Firefox won't use system codecs because they might be insecure, they might be buggy
This does not address the original objection. Calls to the Mac and Windows are not known to be any less buggy or insecure than calls to the h264 APIs. So why accept one and not the other? The only sane answer of course is that you can't build an app at all without calling the OS basic APIs of your host machine, but you can try to have an ugly work around h264.
RedHat did this, and I was very happy about it at the time, being involved with the Xiph.org projects. The users hated it, but I don't see how to educate users about this any other way.