Superiority of processes over threads in gstreamer framework

[Andoni Morales]

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

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

Cheers,
Andoni

>
> 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:
> http://gstreamer-devel.966125.n4.nabble.com/Superiority-of-processes-over-threads-in-gstreamer-framework-tp4659072.html
> Sent from the GStreamer-devel mailing list archive at Nabble.com.
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>



-- 
Andoni Morales Alastruey

LongoMatch:The Digital Coach
http://www.longomatch.ylatuya.es
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20140621/04342ea0/attachment.html>