<div dir="ltr">I found the culprit. <div><br></div><div>The block pad that I installed in the tee's src pad was blocking data flow for the entire element and not simply the pad it was assigned to. So once the data flow is blocked simply unlink the desired branch downstream of the tee and then drop the probe. </div><div><br></div><div>I initially thought that having data flowing out of unlinked pads would cause problems, but apparently not. </div><div><br></div><div>Sérgio</div></div><div class="gmail_extra"><br><div class="gmail_quote">2014-11-27 13:15 GMT+01:00 Sérgio Agostinho <span dir="ltr"><<a href="mailto:sergio.r.agostinho@gmail.com" target="_blank">sergio.r.agostinho@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Let me build on this case. I gave it another test, this time with different elements<div><br></div><div>v4l2src ! tee name=t \</div><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>t. ! queue ! xvimagesink \</div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>t. ! queue ! x264enc ! rtph264pay ! udpsink</div><div><br></div></blockquote>Once more, shutting down the udpsink branch, makes the feed in xvimagesink freeze, even though I explicitly enforce and check that the pipeline is in playing state. Adding and linking all elements back in the updsink branch, makes xvimagesink resume the normal behavior. </div><div><br></div><div>With this test I can narrow that the issue must be on the way I'm removing my elements from the stream. Let me provide some additional insight on how that's being made, once more considering the example of removing the udpsink branch:</div><div><br></div><div>- I first install an event probe in udpsink's pad listening for eos. (GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM)</div><div>- I then block tee src_1 pad. (GST_PAD_PROBE_TYPE_BLOCK_DOWNSTREAM)</div><div>- Upon entering the block callback, I send and eos event through the peer_pad, i. e. through queue_1 sink pad. Note that I do not unblock the pad (drop the probe) at this point and I do not release the request pad from the tee element.</div><div>- Once the eos is received on udpsink's pad, I drop the event probe, unlink all the elements belonging to the branch, set their state to NULL and remove them from the pipeline. </div><div>- At this point, the video feed in xvimagesink freezes</div><div>- To restore the udpsink branch, I start by adding the elements back to the pipeline</div><div>- I link them all</div><div>- I remove the blocking probe from the tee</div><div>- I send the entire pipeline to PAUSE and then to PLAY. I'm being forced to send it to pause first because otherwise the livesinks refuse to transition to play. </div><div><br></div><div>Cheers, </div><span class="HOEnZb"><font color="#888888"><div>Sérgio</div></font></span><div><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2014-11-25 15:16 GMT+01:00 Sérgio Agostinho <span dir="ltr"><<a href="mailto:sergio.r.agostinho@gmail.com" target="_blank">sergio.r.agostinho@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello, <div><br></div><div>I'm currently trying to build a pipeline that is changed upon request. Most (if not all) of the work has been based on the guidelines provided in this <a href="http://gstreamer.freedesktop.org/data/doc/gstreamer/head/manual/html/section-dynamic-pipelines.html#section-dynamic-changing" target="_blank">example from the manual</a>. For now I'm working with the following setup</div><div><br></div><div>pulsesrc ! tee name=t \</div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div>t. ! queue ! faac ! rtpmp4apay ! udpsink \</div></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>t. ! queue ! audioresample ! tcpserversink</div></blockquote><div><br></div><div>My idea is to able to active/deactivate each one of these sinks (and the required upstream elements) as needed, while the pipeline is live in playing state. Currently I'm facing some issues when I need to disable and remove one of the sinks/branches. Every time one of the sinks is not needed, I block the corresponding srcpad on the tee element, unlink all elements in that branch of the pipeline and remove them from the pipeline, set them to a NULL state. When I do that (e.g. udpsink branch), I've noticed that the other branch (tcpsink brnahc) stops streaming data. To be honest, it is more like it pauses, because once I activate the other one again (udpsink branch), it (tcpsink branch) resumes streaming from exactly the point it initially stopped. It is as if the tcp branch was buffering but not sending data while the udpsink was off. </div><div><br></div><div>Any hints on what might be happening?</div><span><font color="#888888"><div><br></div><div>Sérgio</div><div><br></div><div><br></div><div><br></div><div><br></div></font></span></div>
</blockquote></div><br></div></div></div></div>
</blockquote></div><br></div>