I haven't looked at the repositories but I'm fairly sure this is wrong, I believe most ports hook up some sort of system framework, apples port uses Quicktime, the gtk port uses gstreamer, the qt port uses phonon (a multimedia API that can map to several multimedia frameworks such as gstreamer/xine/quicktime/directshow). Chome/Chromium bundles ffmpeg with or without support for patented codecs depending on which version you get.

I haven't looked at the repositories but I'm fairly sure this is wrong, I believe most ports hook up some sort of system framework, apples port uses Quicktime, the gtk port uses gstreamer, the qt port uses phonon (a multimedia API that can map to several multimedia frameworks such as gstreamer/xine/quicktime/directshow). Chome/Chromium bundles ffmpeg with or without support for patented codecs depending on which version you get.

I'm less concerned about the implementation specifics and more concerned with the fact that the open source distribution of Webkit *can* play back H264 video.

Edit: The point here is that there's a perfectly reasonable way for Firefox to implement H264 video in a cross platform way and without having to license and / or distribute the code for H264 decoding themselves. Webkit uses such a method but Mozilla is simply refusing to go down that same path out of a (in my opinion, misguided) sense of “standing up for software freedom.”

I'm less concerned about the implementation specifics and more concerned with the fact that the open source distribution of Webkit *can* play back H264 video.

Edit: The point here is that there's a perfectly reasonable way for Firefox to implement H264 video in a cross platform way and without having to license and / or distribute the code for H264 decoding themselves. Webkit uses such a method but Mozilla is simply refusing to go down that same path out of a (in my opinion, misguided) sense of “standing up for software freedom.”

Depends on the meaning of can, mozilla has said they are against hooking up to directshow/quicktime even in an indirect way ala qt-phonon due to possible security issues they can't fix, they could ship with gstreamer on all platforms, but either they would have to buy the licensed h264 codec or people would have to download gstreamer codecs separately (bad user experience)-they could have a search offering patented codecs for free noting that it might be illegal where they live but that is a dangerous move and they might be a bigger target then many linux distros, plus even if they had money to pay for themselves they are worried about downstream distributors(mozilla might not be as embedable as webkit but plenty of people still embed it/have a browser based of off of it-including sugar(OLPC),Flock,ect., many applications based of it that allow web browsing-thunderbird,miro,songibrd,ect., and many other open source distrubutors such as linux distros or ports to non official platforms.

Depends on the meaning of can, mozilla has said they are against hooking up to directshow/quicktime even in an indirect way ala qt-phonon due to possible security issues they can't fix, they could ship with gstreamer on all platforms, but either they would have to buy the licensed h264 codec or people would have to download gstreamer codecs separately (bad user experience)-they could have a search offering patented codecs for free noting that it might be illegal where they live but that is a dangerous move and they might be a bigger target then many linux distros, plus even if they had money to pay for themselves they are worried about downstream distributors(mozilla might not be as embedable as webkit but plenty of people still embed it/have a browser based of off of it-including sugar(OLPC),Flock,ect., many applications based of it that allow web browsing-thunderbird,miro,songibrd,ect., and many other open source distrubutors such as linux distros or ports to non official platforms.

Does Webkit support h.264 *on Linux*? On Mac, and probably Windows, it can use system media libraries. On Linux, what is required to support h.264? Is it properly licensed?

Also, the corporations behind WebKit (Google and Apple) have a lot deeper pockets to absorb patent problems than Mozilla, and also have h.264 licenses themselves. That is a fairly significant difference, and I can understand Mozilla not wanting to take that risk.

Does Webkit support h.264 *on Linux*? On Mac, and probably Windows, it can use system media libraries. On Linux, what is required to support h.264? Is it properly licensed?

Also, the corporations behind WebKit (Google and Apple) have a lot deeper pockets to absorb patent problems than Mozilla, and also have h.264 licenses themselves. That is a fairly significant difference, and I can understand Mozilla not wanting to take that risk.

Truthfully, I haven't looked–and I probably won't. It's not that I don't respect the users of Linux desktops, it's just that it's a non-issue for me and should be a non-issue for Mozilla. The world is not such that “As the Linux Desktop goes, so goes Firefox.” In terms of pure numbers, there are a lot more people using Firefox on Windows and OS X than are using it on Firefox.

And again, my argument isn't that Mozilla shouldn't support Theora. My argument is that there's a perfectly good way they could implement h264 support where its available in the OS and they're refusing to do that. There's no technical limitation that would prevent it; it's a purely idealistic standpoint that will make it impossible for developers to deliver the majority of the existing video content to the browser without the use of a plugin like Flash or Silverlight.

Truthfully, I haven't looked–and I probably won't. It's not that I don't respect the users of Linux desktops, it's just that it's a non-issue for me and should be a non-issue for Mozilla. The world is not such that “As the Linux Desktop goes, so goes Firefox.” In terms of pure numbers, there are a lot more people using Firefox on Windows and OS X than are using it on Firefox.

And again, my argument isn't that Mozilla shouldn't support Theora. My argument is that there's a perfectly good way they could implement h264 support where its available in the OS and they're refusing to do that. There's no technical limitation that would prevent it; it's a purely idealistic standpoint that will make it impossible for developers to deliver the majority of the existing video content to the browser without the use of a plugin like Flash or Silverlight.

The whole thing boils down to idealism vs. pragmatism. If you ignore the fact that h264 appears to produce better quality video, that is.

Idealism sounds great when you don't have other things you need to be doing instead, but I'm busy and I need to be pragmatic. H264 is out there in popular use already and there's a considerable cost in re-encoding video…

The whole thing boils down to idealism vs. pragmatism. If you ignore the fact that h264 appears to produce better quality video, that is.

Idealism sounds great when you don't have other things you need to be doing instead, but I'm busy and I need to be pragmatic. H264 is out there in popular use already and there's a considerable cost in re-encoding video…

Hopefully Google will be both idealist and pragmatist, opening up the VP8 codec from On2 who they recently acquired, thus solving the licencing issues around h264. Then we would have a high quality video codec for all browsers on all platforms.

Hopefully Google will be both idealist and pragmatist, opening up the VP8 codec from On2 who they recently acquired, thus solving the licencing issues around h264. Then we would have a high quality video codec for all browsers on all platforms.

You forgot the line:

Webkit passes on the responsibility for purchasing H.264 patent licences to any end-user or project that builds on it.

Firefox passes on Theora code that can be used freely by anyone, for any purpose.

This is why even the mighty Google doesn't support H.264 in Chromium, its webkit based, open source browser, but only in Chrome. And even in Chrome you can only use the H.264 for personal and non-commercial use.

You forgot the line:

Webkit passes on the responsibility for purchasing H.264 patent licences to any end-user or project that builds on it.

Firefox passes on Theora code that can be used freely by anyone, for any purpose.

This is why even the mighty Google doesn't support H.264 in Chromium, its webkit based, open source browser, but only in Chrome. And even in Chrome you can only use the H.264 for personal and non-commercial use.

I've just read your other posts, which sadly seem quite troll-y, I thought this was a genuine misunderstanding about the interstection of patents and open source software.

You appear to work for a company that distributes H.264 media. Do any of your customers distribute video for business reasons, say recordings of business seminars? What do you tell them about those viewing via Flash that only have licence to view the video for personal and non-commercial reasons?

I've just read your other posts, which sadly seem quite troll-y, I thought this was a genuine misunderstanding about the interstection of patents and open source software.

You appear to work for a company that distributes H.264 media. Do any of your customers distribute video for business reasons, say recordings of business seminars? What do you tell them about those viewing via Flash that only have licence to view the video for personal and non-commercial reasons?

> Webkit includes support for h264 video.

As someone tried to point out above, this isn't true. Webkit's 'ports' (that's Safari, Chrome, Qt, Gtk, etc) are provided with the raw streams from the media engine in Webkit, and it is up to them what to do with it. Safari passes it to Quicktime, which can decode H.264. Chrome passes it to ffmpeg, which can decode H.264 in Chrome-not-Chromium. I think Gtk passes it to Gstreamer, and Qt has its own thing.

The point is that there is NO H.264 decoding in Webkit, That would be a violation of the MPEG-LA's patents. For Firefox to do something similar to that setup they would have to become closed-source like Safari and Chrome-not-Chromium. I don't see Mozilla crossing that big red line, no matter what anyone says.

> Webkit includes support for h264 video.

As someone tried to point out above, this isn't true. Webkit's 'ports' (that's Safari, Chrome, Qt, Gtk, etc) are provided with the raw streams from the media engine in Webkit, and it is up to them what to do with it. Safari passes it to Quicktime, which can decode H.264. Chrome passes it to ffmpeg, which can decode H.264 in Chrome-not-Chromium. I think Gtk passes it to Gstreamer, and Qt has its own thing.

The point is that there is NO H.264 decoding in Webkit, That would be a violation of the MPEG-LA's patents. For Firefox to do something similar to that setup they would have to become closed-source like Safari and Chrome-not-Chromium. I don't see Mozilla crossing that big red line, no matter what anyone says.

Chromium-not-Chrome, being an open-source project, includes a fairly simplistic method of filtering out H.264 content before passing it on to ffmpeg. Several of the downstream distributors have bypassed that filtering, so H.264 gets passed down along with the rest.

The argument, I suppose, is that even with the filtering removed, Chromium itself still doesn't directly include any of the offending codecs, so it still isn't treading on any patents – ffmpeg might potentially be.

And as for the system on which such a modified Chromium is installed… Well, if the system's administrator saw fit to install ffmpeg with its full slate of patent-encumbered codecs intact, then she should have already been aware of the patent situation, and had decided that either:
1) She has already separately purchased/obtained a legitimate license for the H.264 decoder included in ffmpeg, or
2) She lives in a jurisdiction where she thinks H.264 either isn't patented, or any such patent is invalid, or
3) She doesn't care that she's violating the patent.

Chromium-not-Chrome, being an open-source project, includes a fairly simplistic method of filtering out H.264 content before passing it on to ffmpeg. Several of the downstream distributors have bypassed that filtering, so H.264 gets passed down along with the rest.

The argument, I suppose, is that even with the filtering removed, Chromium itself still doesn't directly include any of the offending codecs, so it still isn't treading on any patents – ffmpeg might potentially be.

And as for the system on which such a modified Chromium is installed… Well, if the system's administrator saw fit to install ffmpeg with its full slate of patent-encumbered codecs intact, then she should have already been aware of the patent situation, and had decided that either:
1) She has already separately purchased/obtained a legitimate license for the H.264 decoder included in ffmpeg, or
2) She lives in a jurisdiction where she thinks H.264 either isn't patented, or any such patent is invalid, or
3) She doesn't care that she's violating the patent.