After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 607932 - Create a sandboxed playback element
Create a sandboxed playback element
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
unspecified
Other All
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-01-24 14:13 UTC by Johan (not receiving bugmail) Dahlin
Modified: 2018-11-03 11:16 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Johan (not receiving bugmail) Dahlin 2010-01-24 14:13:19 UTC
GStreamer should provide a playback element that separates the network IO and decoding from rendering. Demuxers and decoders are more likely to contain security bugs and should be separated as much as possible from the rest of the playback pipeline.

Source/demuxing/decoding should ideally be done in one process and communicate and send the data over shmem/pipe etc to another process which is only sending the decoded data to the audio and videosink.

See also:
http://code.google.com/p/chromium/issues/detail?id=32861#c23
Comment 1 Olivier Crête 2010-01-24 16:12:25 UTC
I wrote a pair of shmsrc/shmsink elements that provide a pipe-like interface using shared mem for that kind of case.
Comment 2 Sebastian Dröge (slomo) 2010-01-24 16:53:52 UTC
Or you could simply use gdp over TCP or unix domain sockets. In the case of chromium it would probably be a better/easier solution to do all GStreamer stuff in a separate process and just embed the video sink into the chromium window.
Comment 3 Johan (not receiving bugmail) Dahlin 2010-01-25 12:37:21 UTC
I'm not sure if GDP would suffice, ideally the process which does the rendering should contain initial setup code and after that point it should only working on existing state. Eg, no file system access, no memory allocation, only use existing file descriptors with a limited set of system calls (read/write).
Comment 4 Olivier Crête 2011-05-23 14:58:20 UTC
The shmsrc/sink have a shmpipe.[ch] files that are non-gst dependant and that you can use in your main app to transfer the data.. That said, the shm stuff doesn't carry timestamps or caps or anything like that. But it does provide zero-copy if your shared memory buffer is large enough to use it as a queue.
Comment 5 Sebastian Dröge (slomo) 2013-08-16 11:57:42 UTC
Is anybody planning to work on this? There is this here also http://guij.emont.org/blog/2012/05/08/video-decoding-in-a-sandbox/

I think it would be great to have a generic sandboxing mechanism in GStreamer that allows to run any part of a pipeline inside a different process, while having this completely transparent for all involved GStreamer elements... by implementing all of the GstElement/GstPad API via IPC.
Comment 6 GStreamer system administrator 2018-11-03 11:16:16 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/29.