Announcement

Collapse
No announcement yet.

G-Streamer For Google's Chrome Proposed But Denied

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

  • #11
    Sorta.

    Gstreamer is designed to deal with these sorts of situations. Ffmpeg is not. It's just a bunch of libraries containing different codecs you compile stuff against.

    You can write your program to check and see if libraries exist before you use them or something like that, but the burden is on you- the programmer- and it's not something that is easy.

    In contrast Gstreamer solves theses sorts of issues for you. It's designed to isolate programs against licensing issues and codecs can be shipped independently as Gstreamer plugins.


    Oh. And ffmpeg is a popular Gstreamer plugin. Just so you know were these things stand. (they are not mutually exclusive)

    This is the _purpose_ behind Gstreamer, which is why Chrome should use it.

    The 'sandbox' excuse sounds like a bunch of bullshit to me.

    Why?

    $ ldd /usr/lib/chromium-browser/chromium-browser
    linux-gate.so.1 => (0xf7726000)
    libX11.so.6 => /usr/lib/libX11.so.6 (0xf75ec000)
    libXrender.so.1 => /usr/lib/libXrender.so.1 (0xf75e3000)
    libXext.so.6 => /usr/lib/libXext.so.6 (0xf75d3000)
    librt.so.1 => /lib/i686/cmov/librt.so.1 (0xf75ca000)
    libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0xf7208000)
    libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0xf7173000)
    libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0xf7158000)
    libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0xf7132000)
    libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0xf7119000)
    libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0xf710e000)
    libgio-2.0.so.0 => /usr/lib/libgio-2.0.so.0 (0xf707a000)
    libcairo.so.2 => /usr/lib/libcairo.so.2 (0xf7003000)
    libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0xf6fbe000)
    libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xf6f47000)
    libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xf6f18000)
    libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xf6edb000)
    libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0xf6ed7000)
    libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0xf6ed1000)
    libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0xf6e1c000)
    libnss3.so => /usr/lib/libnss3.so (0xf6d47000)
    libnssutil3.so => /usr/lib/libnssutil3.so (0xf6d32000)
    libsmime3.so => /usr/lib/libsmime3.so (0xf6d14000)
    libplds4.so => /usr/lib/libplds4.so (0xf6d11000)
    libplc4.so => /usr/lib/libplc4.so (0xf6d0c000)
    libnspr4.so => /usr/lib/libnspr4.so (0xf6cd8000)
    libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xf6cbf000)
    libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xf6cbb000)
    libgconf-2.so.4 => /usr/lib/libgconf-2.so.4 (0xf6c88000)
    libm.so.6 => /lib/i686/cmov/libm.so.6 (0xf6c62000)
    libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0xf6c41000)
    libpng12.so.0 => /usr/lib/libpng12.so.0 (0xf6c1d000)
    libxml2.so.2 => /usr/lib/libxml2.so.2 (0xf6af4000)
    libxslt.so.1 => /usr/lib/libxslt.so.1 (0xf6abc000)
    libasound.so.2 => /usr/lib/libasound.so.2 (0xf69f4000)
    libbz2.so.1.0 => /lib/libbz2.so.1.0 (0xf69e3000)
    libexpat.so.1 => /usr/lib/libexpat.so.1 (0xf69bc000)
    libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xf68cb000)
    libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xf68ae000)
    libc.so.6 => /lib/i686/cmov/libc.so.6 (0xf6767000)
    libz.so.1 => /usr/lib/libz.so.1 (0xf6753000)
    libxcb.so.1 => /usr/lib/libxcb.so.1 (0xf673a000)
    /lib/ld-linux.so.2 (0xf7727000)
    libXcomposite.so.1 => /usr/lib/libXcomposite.so.1 (0xf6736000)
    libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0xf6733000)
    libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xf672e000)
    libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0xf672b000)
    libXi.so.6 => /usr/lib/libXi.so.6 (0xf671e000)
    libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0xf6716000)
    libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0xf670d000)
    libpcre.so.3 => /lib/libpcre.so.3 (0xf66dd000)
    libresolv.so.2 => /lib/i686/cmov/libresolv.so.2 (0xf66c8000)
    libselinux.so.1 => /lib/libselinux.so.1 (0xf66ae000)
    libpixman-1.so.0 => /usr/lib/libpixman-1.so.0 (0xf6654000)
    libdirectfb-1.2.so.0 => /usr/lib/libdirectfb-1.2.so.0 (0xf65df000)
    libfusion-1.2.so.0 => /usr/lib/libfusion-1.2.so.0 (0xf65d6000)
    libdirect-1.2.so.0 => /usr/lib/libdirect-1.2.so.0 (0xf65c2000)
    libxcb-render-util.so.0 => /usr/lib/libxcb-render-util.so.0 (0xf65be000)
    libxcb-render.so.0 => /usr/lib/libxcb-render.so.0 (0xf65b6000)
    libORBit-2.so.0 => /usr/lib/libORBit-2.so.0 (0xf6561000)
    libdbus-glib-1.so.2 => /usr/lib/libdbus-glib-1.so.2 (0xf6544000)
    libdbus-1.so.3 => /lib/libdbus-1.so.3 (0xf650b000)
    libXau.so.6 => /usr/lib/libXau.so.6 (0xf6507000)
    libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xf6502000)
    That's why.

    Why does it make sense to trust a shitload of system resources and then turn around and say that using Gstreamer would be counter productive?

    If any of those libraries are hacked then they could violate the security of the browser.

    I can use LD_PRELOAD or LD_LIBRARY_PATH to load any libraries ahead of launching a browser in my user environment and it can be used to violate the security of the browser.

    So how is preventing me from easily installing codecs in Gstreamer going to make my browser any more secure?

    Ergo... It's a crap excuse.



    The reality is that Google wants you to get Chrome from them and they want to make sure that you always have H.264 support. Porting away from ffmpeg is a pain and is something that, franky, they don't want to do. It's something they don't care about doing.

    Telling people that they just don't want to bother with this approach because they don't give a shit will just piss people off. It's easier to tell them some silly excuse about sandboxing.

    -----------------------

    Anyways. If you are serious about sandboxing in Linux nowadays you use LXC. I can take any application I care and throw it into a stripped down Linux environment in a LXC and boost the security of my system far higher them anything you can reasonably do in a application. At it is easy and takes a low amount of effort.

    The major downside, of course, is that you need a system with 2.6.29 linux or newer.

    Comment


    • #12
      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.

      Comment


      • #13
        Opera can use gstreamer on all 3 platforms and Chrome can not? Strange...

        http://my.opera.com/core/blog/2009/1...roducing-video

        Comment


        • #14
          Wait a minute. I'm on an up-to-date 64 bit GNU/Linux/apt/GNOME based operating system with address space layout randomization, using Chrome for its tabs-on-top, usability, and speed.

          Um.

          The only thing I want from 'sandboxing' is keeping crashing tabs from taking down my browser window. I don't need its overkill security.

          Comment


          • #15
            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.
            You're aware right, that Phonon uses either GStreamer or Xine as backend?

            Comment


            • #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

                      Working...
                      X