Superiority of processes over threads in gstreamer framework

Andoni Morales ylatuya at
Sat Jun 21 09:36:24 PDT 2014

2013-03-12 13:55 GMT+01:00 Baby Octopus <jagadishkamathk at>:

> 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

This approach is the used by Flumotion wrapping GStreamer elements into
pipelines (fdsrc + gdpdepay + pipeline + gdppay + multifdsink) that run in
a worker process. It has the advantage of being able to distribute
precesses in the cloud where the capture, encoding and streaming could run
in different machines and being able to handle failures more easilly by
restaring the component that crashed.

But this approach has a big impact when processes are running in the same
machine, adding additional memcpy's with gdppay and gdpdepay, although this
could be handled in a more efficient way today with shmsink and shmsrc.

This design made sense a few years ago, when servers didn't have any
processing power to run everything in the same machine, but nowadays you
can easily capture and encode several streams in the same machine.


> Please see that I'm not referring to any good,bad,ugly component here. I'm
> only referring to the gstreamer framework.
> ~BO
> --
> View this message in context:
> Sent from the GStreamer-devel mailing list archive at
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at

Andoni Morales Alastruey

LongoMatch:The Digital Coach
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the gstreamer-devel mailing list