<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 30, 2017 at 4:25 PM, Nicolas Dufresne <span dir="ltr"><<a href="mailto:nicolas@ndufresne.ca" target="_blank">nicolas@ndufresne.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-HOEnZb"><div class="gmail-h5">Le mardi 30 mai 2017 à 11:02 +0200, Bogdan Pavkovic a écrit :<br>
> Hi all,<br>
><br>
> I realized that an attachment cannot be seen from the archives so here is the link just in case...<br>
><br>
> <a href="https://mega.nz/#%21h8wFVarA%21leTOvjLg4VhBxX-wNPY3_w8jcFE-W-vspXw7FOT_SAU" rel="noreferrer" target="_blank">https://mega.nz/#!h8wFVarA!<wbr>leTOvjLg4VhBxX-wNPY3_w8jcFE-W-<wbr>vspXw7FOT_SAU</a><br>
><br>
> Best,<br>
> B<br>
><br>
> > On Tue, May 30, 2017 at 10:49 AM, Bogdan Pavkovic <<a href="mailto:bogprs@gmail.com">bogprs@gmail.com</a>> wrote:<br>
> > Dear all,<br>
> ><br>
> > Here is the diagram for your convenience.<br>
> > I hope there is someone that can answer at least some subset of my questions.<br>
> ><br>
> > Thanks again in advance.<br>
> ><br>
> > Best,<br>
> > Bogdan<br>
> ><br>
> ><br>
> > > > On Fri, May 26, 2017 at 1:15 PM, Bogdan Pavkovic <<a href="mailto:bogprs@gmail.com">bogprs@gmail.com</a>> wrote:<br>
> > > Dear all,<br>
> > ><br>
> > > I am a newby to GStremer Community <br>
> > > but I managed to thoroughly go through ALL offered tutorials.<br>
> > ><br>
> > > GOAL: I need to design a performance-critical pipeline and create a couple of new filter plugins.<br>
> > > Any help will be appreciated.<br>
> > ><br>
> > > General pipeline is divided in 3 bins: input, core, and output.<br>
> > > For the input part we have already completed 4 options: RTP client (existing plugin), MJPEG, V2L, and FILE (existing).<br>
> > > For the output part we use Wayland.<br>
> > ><br>
> > > Core part is processing which roughly is done in 3 stages: <br>
> > > pre-processing, heavy processing, and some sort of Kalman filtering.<br>
> > > Q1: My idea is to make 3 plugins that will form a larger bin. Is this the right way to go?<br>
> > > Pre-processing plug-in need to have on-request sink pads since number of input video streams can vary between 1 and 4.<br>
> > > Source (output) pads (on request) will be created and linked to consecutive elements on the fly as they appear.<br></div></div></blockquote><div><br>Bonjour Nicolas. Merci pour ta réponse.<br></div><div>Find my answers below.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-HOEnZb"><div class="gmail-h5">
<br>
</div></div>Is there a relationship between the input streams ? Since having a<br>
single element in the context were there is not link between each<br>
input/output pair will just make your pipeline more complex to handle.<br>
You will endup having N+1 thread making call into your element. You<br>
could though use a bin just to group and manage the internal filters.<br></blockquote><div><br></div><div>Input streams are not in any relationship. Each comes from separate camera and after same processing stages (3 in total as described) will be displayed in 2 different windows.<br><br></div><div>If I understand correctly your answer, for each PAD in an element, there will be a separate thread called to handle the <b>_chain </b>function every time a buffer arrives.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-"><br>
> > > Q2: Do all consecutive elements in Core bin need to have on request pads due to non-deterministic number of input videos?<br>
<br>
</span>If I understand correctly, you are asking if the element inside the bin<br>
need to have request pads. If that is correct, the answer is no. You<br>
can have a bin with request sink pads, that will use ghost pad to<br>
interface with internal filters static sink pads. The bin can then<br>
notify sometimes src pads by ghosting a filter static src pad.<br></blockquote><div><br></div><div>Understood. We will then implement 3 filters with N static sink pads and map them with ghost pads to a bin.<br></div><div>What about src pads of an element inside bin? Do they need to be created on request or as a simple static pads?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-"><br>
> > ><br>
> > > Heavy processing plug-in needs to do heavy lifting and we intend to use multi-threading on 4 available cores.<br>
> > > Q2: Do we need to use 2 queue elements before each of the pads of this element to separate processing of each video stream?<br>
<br>
</span>It depends of how you implement the parallel processing. If you can do<br>
parallel processing on a single GstBuffer, then you don't need any<br>
queuing. This method is usually used to achieve low latency processing<br>
as queuing multiple buffers to feed multiple threads will introduce<br>
latency.<br></blockquote><div><br></div><div>Clear. Since we will do parallel processing on a single GstBuffer then we will not use a queue element.<br>  <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-"><br>
> > > Q3: I understood there are tasks that can do further multi-threading. Can we use them behind a queue element?<br>
<br>
</span>I'm not sure I understand this question. What do you mean by tasks ?<br>
You can of course create and manage threads in your element.<br></blockquote><div><br></div><div>I meant GTask but you've already explained below.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-"><br>
> > > Q4: If we use 4 tasks, is there a way to signal and sync all of them? i.e. Do we get a signal  when all 4 task outputs are ready?<br>
<br>
</span>I'm not sure this question correlate with anything in GStreamer.<br>
GstTask is a wrapper around a thread, with proper state that let you<br>
start/stop/pause the task and link it to a thread pool. Signalling that<br>
data is ready has to be done by your code, could be using GCond or some<br>
advance queue data structure.<br></blockquote><div><br></div><div>Understood. GCond seems like an elegant way.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-"><br>
> > > Q5: How can we configure a task to target a specific core?<br>
<br>
</span>This is doable in a portable way, hence not expose through the GThread<br>
abstraction. In general, you should trust your scheduler not to move<br>
the thread around in a way that it would degrade the performance. If<br>
you are implementing this only for unix system, you can of course<br>
implement your own, and use pthread API directly (see<br>
pthread_setaffinity_np).<br></blockquote><div><br></div><div>Great! Looks exactly like what we need.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-"><br>
> > ><br>
> > > Finaly, Kalman plugin is not calculation intensive and can handle both streams.<br>
> > > Q6: Can we somehow undo the queue element? Does it make sense?<br>
<br>
</span>What does "undoing" an element means ? If by chance you are referring<br>
to the requires queues after demuxer elements, be aware that this is<br>
needed because demuxers receives buffer from a single streaming thread<br>
and does not create any new threads for the output. The queues are<br>
needed so that each branch of the demuxer can work independently. If<br>
you have input/output pairs in your bins, you'll have 1 streaming<br>
thread per pair, hence each output will already work independently from<br>
each other.<br></blockquote><div><br></div><div>Actually, this question became redundant with your previous answers.<br></div><div>Thanks for giving details about demuxers.<br><br></div><div>Best,<br></div><div>Bogdan<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-"><br>
> > ><br>
> > > I can provide a diagram of the proposed pipeline if needed to clarify things.<br>
> > ><br>
> > > Many thanks in advance.<br>
> > ><br>
> > > Best regards,<br>
> > > Bogdan<br>
> > ><br>
> ><br>
> ><br>
><br>
</span>> ______________________________<wbr>_________________<br>
> gstreamer-devel mailing list<br>
> <a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.<wbr>freedesktop.org</a><br>
> <a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/<wbr>mailman/listinfo/gstreamer-<wbr>devel</a><br>______________________________<wbr>_________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.<wbr>freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/<wbr>mailman/listinfo/gstreamer-<wbr>devel</a><br>
<br></blockquote></div><br></div></div>