<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">2013-03-12 13:55 GMT+01:00 Baby Octopus <span dir="ltr"><<a href="mailto:jagadishkamathk@gmail.com" target="_blank">jagadishkamathk@gmail.com</a>></span>:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
Gstreamer framework has been well accepted in open source community and has<br>
been a well accepted product in terms of its flexibility and functionality<br>
as a media framework. I guess its 12 year old now<br>
<br>
Was just wondering why one aspect has not been looked into as yet to make<br>
the framework more robust i.e., using processes instead of threads. A<br>
certain media pipeline can get really complicated with so many queue, tee,<br>
multiqueue and might lead to a large number of active threads. And in case<br>
if any thread crashes say for some reason, the whole pipeline collapses.<br>
This isn't an ideal situation to be in. Processes instead, will not make the<br>
complete pipeline to crash. Any crash in a process will lead to only that<br>
process to crash. And Inter process communication isn't that costly either<br>
since it can be handled at kernel level<br>
<br>
So any particular reason here why thread is preferred over processes? It<br>
could also be true that its is just written that way without any reason. I'm<br>
just curious to know here<br></blockquote><div><br></div><div>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.<br>

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

<br></div><div>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.<br>

<br></div><div>Cheers,<br>Andoni<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Please see that I'm not referring to any good,bad,ugly component here. I'm<br>
only referring to the gstreamer framework.<br>
<br>
~BO<br>
<br>
<br>
<br>
<br>
--<br>
View this message in context: <a href="http://gstreamer-devel.966125.n4.nabble.com/Superiority-of-processes-over-threads-in-gstreamer-framework-tp4659072.html" target="_blank">http://gstreamer-devel.966125.n4.nabble.com/Superiority-of-processes-over-threads-in-gstreamer-framework-tp4659072.html</a><br>


Sent from the GStreamer-devel mailing list archive at Nabble.com.<br>
_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>Andoni Morales Alastruey<br><br>LongoMatch:The Digital Coach<br><a href="http://www.longomatch.ylatuya.es">http://www.longomatch.ylatuya.es</a>
</div></div>