5 ms·

Things I don't understand: * Fork? * H.264 HTML Video support via a plugin? Why aren't these valid solutions?

blasdel 17y ago
Yes, someone could fork Gecko + XULrunner + Firefox; but it is a huge pain-in-the-ass to even track it as upstream, much less diverge from it. It's purposefully architected to make a plugin very unsavory — you could do it with a plugin/extension that inspected every DOM for failed <video> embeds, dynamically replacing them with an <embed> of its own NSAPI plugin. You'd be guaranteed to get FOUC, poor detectablity, and regular breakage. At that point the author is better off just seamlessly falling back to Flash.
- carussell 17y ago
  "It's purposefully architected to make a plugin very unsavory" I'd like a citation for this please, or at least some synthesis based on some explicit rationale (which is what I expected on the with that em dash, instead of a non-sequitur).
  - blasdel 17y ago
    Gecko links directly with liboggplay to restrict themselves to exclusively WAV and vorbis+theora in ogg containers. Every other app out there uses a standard media handling library: ffmpeg (esp. if bundling), GStreamer, QuickTime, DirectShow, or some combination of them. This was made explicit when us proles discovered that Mozilla has had a GStreamer <video> implementation for two years, for use in their mobile port so that they have a hope of playing video in real time: > My exclusive focus for this GStreamer integration has been to make it work with Fennec. Not enabling it in Firefox on platforms where GStreamer has been ported to, is as far as I know a political decision. https://bugzilla.mozilla.org/show_bug.cgi?id=422540#c105 https://bugzilla.mozilla.org/show_bug.cgi?id=422540#c105 Architecting against plugins is not new in the free software community. RMS purposefully designed GCC so that you couldn't interface with its internal representations to make it impossible to have independent language frontends, optimizers, or target backends. That led directly to ECGS, a complete fork of GCC away from the FSF's control after they let it languish and refused patches — the FSF lost and eventually blessed it as the 'real' GCC. Its closed architecture is the primary motive behind LLVM's ascendancy.
allyt 17y ago
Because you need to pay licensing fees measured in "millions of USD per year" if you're going to distribute software which decodes H.264.
- ubernostrum 17y ago
  Or you just delegate to the OS, which either already ships a licensed copy of the codec (Windows and OS X) or has users who ignore patents and install unlicensed codecs (Linux). By doing this you incur a whopping license fee of... zero dollars, because licensing becomes someone else's problem.
  - ZeroGravitas 17y ago
    It's not someone else's problem if your stated mission is to be "dedicated to promoting and preserving an open, shared and innovative web." It's like a shareholder owned corporation deciding that making money is someone else's problem.
    - ubernostrum 17y ago
      It is an ideological issue; look at my other comments and you'll see me saying that. My problem with comments like the one I was replying to is that they refuse to see this; there is an easy solution to the financial issue of codec licensing, but it keeps getting thrown out as a red herring, when the focus should be on whether Mozilla's ideological stance is a good thing.
      - allyt 17y ago
        they refuse to see this Nah, just hadn't read up/thought about the issue enough, thanks for explaining. I'm actually a bit of a supporter of software patents, as they give business reason to invest boatloads of money in things like H.264 to begin with.
    - GHFigs 17y ago
      Then why do they still allow me to use Adobe's h.264 license?
rlpb 17y ago
It's a valid solution for a client. For a web developer, chances are that your visitor isn't using the fork and hasn't installed the plugin. This means that web sites won't be able to rely on HTML5 to deliver video, and so will use something else (such as Flash).

Yes, someone could fork Gecko + XULrunner + Firefox; but it is a huge pain-in-the-ass to even track it as upstream, much less diverge from it. It's purposefully architected to make a plugin very unsavory — you could do it with a plugin/extension that inspected every DOM for failed <video> embeds, dynamically replacing them with an <embed> of its own NSAPI plugin. You'd be guaranteed to get FOUC, poor detectablity, and regular breakage. At that point the author is better off just seamlessly falling back to Flash.

carussell 17y ago
"It's purposefully architected to make a plugin very unsavory" I'd like a citation for this please, or at least some synthesis based on some explicit rationale (which is what I expected on the with that em dash, instead of a non-sequitur).
- blasdel 17y ago
  Gecko links directly with liboggplay to restrict themselves to exclusively WAV and vorbis+theora in ogg containers. Every other app out there uses a standard media handling library: ffmpeg (esp. if bundling), GStreamer, QuickTime, DirectShow, or some combination of them. This was made explicit when us proles discovered that Mozilla has had a GStreamer <video> implementation for two years, for use in their mobile port so that they have a hope of playing video in real time: > My exclusive focus for this GStreamer integration has been to make it work with Fennec. Not enabling it in Firefox on platforms where GStreamer has been ported to, is as far as I know a political decision. https://bugzilla.mozilla.org/show_bug.cgi?id=422540#c105 https://bugzilla.mozilla.org/show_bug.cgi?id=422540#c105 Architecting against plugins is not new in the free software community. RMS purposefully designed GCC so that you couldn't interface with its internal representations to make it impossible to have independent language frontends, optimizers, or target backends. That led directly to ECGS, a complete fork of GCC away from the FSF's control after they let it languish and refused patches — the FSF lost and eventually blessed it as the 'real' GCC. Its closed architecture is the primary motive behind LLVM's ascendancy.

allyt 17y ago

Because you need to pay licensing fees measured in "millions of USD per year" if you're going to distribute software which decodes H.264.

ubernostrum 17y ago
Or you just delegate to the OS, which either already ships a licensed copy of the codec (Windows and OS X) or has users who ignore patents and install unlicensed codecs (Linux). By doing this you incur a whopping license fee of... zero dollars, because licensing becomes someone else's problem.
- ZeroGravitas 17y ago
  It's not someone else's problem if your stated mission is to be "dedicated to promoting and preserving an open, shared and innovative web." It's like a shareholder owned corporation deciding that making money is someone else's problem.
  - ubernostrum 17y ago
    It is an ideological issue; look at my other comments and you'll see me saying that. My problem with comments like the one I was replying to is that they refuse to see this; there is an easy solution to the financial issue of codec licensing, but it keeps getting thrown out as a red herring, when the focus should be on whether Mozilla's ideological stance is a good thing.
    - allyt 17y ago
      they refuse to see this Nah, just hadn't read up/thought about the issue enough, thanks for explaining. I'm actually a bit of a supporter of software patents, as they give business reason to invest boatloads of money in things like H.264 to begin with.
  - GHFigs 17y ago
    Then why do they still allow me to use Adobe's h.264 license?

rlpb 17y ago

It's a valid solution for a client. For a web developer, chances are that your visitor isn't using the fork and hasn't installed the plugin. This means that web sites won't be able to rely on HTML5 to deliver video, and so will use something else (such as Flash).