Announcement

Collapse
No announcement yet.

G-Streamer For Google's Chrome Proposed But Denied

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

  • #16
    Originally posted by r1348 View Post
    You're aware right, that Phonon uses either GStreamer or Xine as backend?
    ... + vlc or/and mplayer backend ...

    But what's more important is DirectShow backend on Windows and QuickTime one on MacOSX.

    Comment


    • #17
      Originally posted by Chewi View Post
      I'd consider that bad practise. Do most people even use the static version of Opera? I don't and I haven't seen many that do. I find it runs noticeably slower.
      I do. I'm running a Solaris 10 machine at work and don't have the ability to install packages... like Qt. It's not that I don't know how, I just don't have root access. In this case, the statically-linked Opera works great for me, as I can just install Opera in my home directory and it works fine. It actually works much better than Firefox 3.5.x (faster, much more stable, and handles 20+ tabs much better).

      Comment


      • #18
        webkit, webkit-gtk and gstreamer

        webkit is already using gstreamer as its html5 video/audio decoder.
        That sandbox thing...

        Well, ffmpeg does not have scheduling/sync code compared to gstreamer, but ffmep is leaner.
        Last edited by sylware; 01-25-2010, 07:43 AM.

        Comment


        • #19
          Originally posted by val-gaav View Post
          ... + vlc or/and mplayer backend ...

          But what's more important is DirectShow backend on Windows and QuickTime one on MacOSX.
          Going to QT4 or not is irrelevant and using phonon would of solved zero issues for Google vs using Gstreamer or ffmpeg or anything else.

          They still would have to ship ffmpeg or gstreamer codecs or something like that with their browser. There is nothing with Phonon that solves the patent licensing problem that Google faces; which is the core of the problem here.

          BTW.. gstreamer runs quite happily on Windows and OS X. As does ffmpeg's codec libraries. So there is nothing to be gained in portability either.

          Comment


          • #20
            Originally posted by val-gaav View Post
            If they used Qt4 from start there would be no problems and they would just use phonon (and it would use native codecs on different platforms)

            Actually they should still use phonon. Seems way more better choice considering the browser is to be multiplatform but the main target is not Gnome/Linux but Windows.
            Last I heard Phonon was considered almost abandonware, where nokia (upstream qt) is now preparing another as-yet-unreleased abstraction layer to replace phonon.

            oh, and there are two versions of phonon - the qt version and the KDE version.

            Such abstractionitis is crazy

            Comment


            • #21
              The reason is GStreamer loads the untrusted code at runtime. It would cause a potential security breach to the Chrome's security architecture.

              Chromium runs RenderProcess (HTML, CSS, JavaScript) in a separate process with less access to platform/OS resources. If chromium uses GStreamer, then GStreamer should have run as a part of RenderProcess which finally tends to load some untrusted plugin code. GStreamer's plugin may need some system privileges to run, but it may fail because RenderProcess is already sandboxed.

              What happens if security is breached because of the untreated GStreamer plugin? You blame Chromium right?

              Comment

              Working...
              X