Superiority of processes over threads in gstreamer framework

Sebastian Dröge sebastian.droege at collabora.co.uk
Tue Mar 12 06:15:26 PDT 2013


On Di, 2013-03-12 at 05:55 -0700, Baby Octopus wrote:
> Hi,
> 
> Gstreamer framework has been well accepted in open source community and has
> been a well accepted product in terms of its flexibility and functionality
> as a media framework. I guess its 12 year old now
> 
> Was just wondering why one aspect has not been looked into as yet to make
> the framework more robust i.e., using processes instead of threads. A
> certain media pipeline can get really complicated with so many queue, tee,
> multiqueue and might lead to a large number of active threads. And in case
> if any thread crashes say for some reason, the whole pipeline collapses.
> This isn't an ideal situation to be in. Processes instead, will not make the
> complete pipeline to crash. Any crash in a process will lead to only that
> process to crash. And Inter process communication isn't that costly either
> since it can be handled at kernel level
> 
> So any particular reason here why thread is preferred over processes? It
> could also be true that its is just written that way without any reason. I'm
> just curious to know here
> 
> Please see that I'm not referring to any good,bad,ugly component here. I'm
> only referring to the gstreamer framework. 

Hi,

people already worked on that and it definitely makes sense for
sandboxing, but using processes instead of threads is a) much more
complex and b) causes a lot of overhead to pass data between the
processes.

One example I know about is
http://guij.emont.org/blog/2012/05/08/video-decoding-in-a-sandbox/

However a more generic solution would be great to have, by which you
could generically proxy the GstElement/GstPad/GstBin APIs between
difference processes. It's possible, just quite some work to get
right :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130312/36e5a6cb/attachment.pgp>


More information about the gstreamer-devel mailing list