Announcement

Collapse
No announcement yet.

Adobe Rants Over Linux Video Acceleration APIs

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #71
    Originally posted by RealNC View Post
    The only ridiculous thing here is that you failed to read what I wrote. Otherwise you wouldn't claim that Mozilla would need to pay any royalties.

    So, up and read again. This time *all* the words. Reading every third or fourth makes it difficult to grasp what's written.
    Who *exactly* do you think will have to pay the royalties if Mozilla distributes a H264 decoder?

    Comment


    • #72
      I think RealNC is arguing about a third party developing a plug-in that would provide that functionality, effectively taking the royalties burden off Mozilla.

      Comment


      • #73
        We already have 3rd party plugins for video: Flash and Silverlight. The idea is to get rid of them.

        Mozilla cannot guarantee cross-platform H264 playback without shipping a decoder inside Firefox, which means shouldering the associated (per download) cost. Even if Mozilla could afford this, smaller browser makers will be essentially locked out of the browser market: how would Epiphany or Konqueror afford to pay the royalties?

        Also note that distributing H264 video requires the *distributor* to pay a fee. This further fragments the web: independent website owners have to choose between relying on the big players (Google/youtube and the like), paying up (not an option - check the fees) or simply stop using video. Coup de grace.

        Do you really desire a future where the big players control the web?

        Comment


        • #74
          RealNC, you just play with words unfortunately.

          Comment


          • #75
            Call me crazy, but isn't this sort of thing why we have NPAPI? FFMPEG can already decode h264-- I wouldn't be terribly surprised to find that someone is already hacking up a fix to this "issue".

            Comment


            • #76
              Originally posted by Wyatt View Post
              Call me crazy, but isn't this sort of thing why we have NPAPI? FFMPEG can already decode h264-- I wouldn't be terribly surprised to find that someone is already hacking up a fix to this "issue".
              Can NPAPI handle implementation of the necessary DOM methods? I was skimming some docs and it looks like it's possible for a plugin to extend <embed> with methods, but could the <video> API be provided in a sane way?

              Comment


              • #77
                HTML5 does not say anything about a codec for the video element. That means that a browser is not required to implement any specific codec at all. And this is why a plug-in makes sense. You people don't grasp what a plug-in actually is. Sure, they're used for embed stuff. But they can be used for whatever else you can think of.

                Also, don't forget that a plug-in might not even be needed. Firefox could just use the platform's video codec. Just like a media player who uses external codecs doesn't have to think about codec royalties, Mozilla wouldn't have to either.

                Furthermore, if Mozilla won't try to externally support H.264, then Google Chrome will win it all, since it's the one and only browser that supports both H.264 and Theora. All other browsers are Theora-only and H.264-only. And since, as I said above, the HTML5 spec does not dictate any codecs, websites are bound to use whatever codec they want and the only browser that will cope with both is Chrome.

                Comment


                • #78
                  Furthermore, if Mozilla won't try to externally support H.264, then Google Chrome will win it all, since it's the one and only browser that supports both H.264 and Theora. All other browsers are Theora-only and H.264-only. And since, as I said above, the HTML5 spec does not dictate any codecs, websites are bound to use whatever codec they want and the only browser that will cope with both is Chrome.
                  "External" support is no solution. Chrome does that with FFMPEG and guess what? Fedora users are locked out of youtube, because their distro doesn't build FFMPEG with H.264 support.

                  Comment


                  • #79
                    Moreover, the original HTML5 spec did mandate Theora, something that was removed later on. Also guess who stands to make a lot of money out of H.264 (hint: it ends in "Microsoft").

                    While we are at it, why don't we make Silverlight a web standard, too? If anything it's less patent encumbered than H.264, so why not?

                    Comment


                    • #80
                      So what if it won't work everywhere? The standard doesn't mandate that Flash must work in all platforms either. The <video> tag isn't any different from <embed>. Just as it isn't important what types of objects work in an <embed>, what kind of video codec works in a <video> tag isn't important either.

                      And who makes money out of H.264 isn't important in this discussion. You're now shifting your original claims about the reason Mozilla doesn't provide H.264 support into monetary politics. That makes you a hypocrite. You should have said what you really think from the beginning.

                      Mozilla can provide H.264 on "supported platforms" (meaning platforms that either have an external H.264 codec that Gecko can use or provide one in the form of a brower-plugin) with no fear of royalties. I certainly don't see Mozilla disallowing Flash completely in their browser just because some platforms don't have an implementation of it. Yet you give the same argument about H.264. Who cares? If some platforms won't have H.264 so be it, just like with Java and Flash objects. There's absolutely no reason why the same can't be done with H.264 too.

                      Comment

                      Working...
                      X