Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 21

Thread: G-Streamer For Google's Chrome Proposed But Denied

  1. #11
    Join Date
    Sep 2006
    Posts
    714

    Default

    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.

  2. #12
    Join Date
    Dec 2007
    Posts
    248

    Default

    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.

  3. #13
    Join Date
    Aug 2009
    Posts
    18

    Default

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

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

  4. #14
    Join Date
    Jun 2007
    Location
    The intarwebs
    Posts
    385

    Default

    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.

  5. #15
    Join Date
    Jul 2007
    Posts
    238

    Default

    Quote 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?

  6. #16
    Join Date
    Dec 2007
    Posts
    248

    Default

    Quote 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.

  7. #17
    Join Date
    Nov 2008
    Location
    Madison, WI, USA
    Posts
    861

    Default

    Quote 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).

  8. #18
    Join Date
    Dec 2008
    Posts
    166

    Default 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 at 07:43 AM.

  9. #19
    Join Date
    Sep 2006
    Posts
    714

    Default

    Quote 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.

  10. #20
    Join Date
    Nov 2007
    Location
    Die trolls, die!
    Posts
    525

    Default

    Quote 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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •