<div dir="ltr">It turns out that the tee is blocking the stream(which is logical) and thus stopping and then starting the stream again on the downstream RtpBins, and I am not handling it appropriately. </div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 7, 2014 at 3:09 PM, Benjamin Trent <span dir="ltr"><<a href="mailto:ben.w.trent@gmail.com" target="_blank">ben.w.trent@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">My pipeline design is this:<div><br></div><div>I have a pipeline that contains a Tee and when a new stream is requested, a new pad is created on that tee, and then a new RTPBIN is added to the pipeline and its rtp input is linked against the new tee source pad. </div><div><br></div><div>The first client connected works fine.</div><div><br></div><div>When another party request a stream(same process is completed), the previous receiver then starts creating additional sometimes pads for both sessions(recv_rtp_src_%u_%u_%u). It is like a second rtp session is created between the two rtpbins(sender and receiver). Whey is the receiver acting like a new session is happening? </div><div><br></div><div>Each rtpbin has a unique name, all elements added have unique names and I am not sending duplicates to the previous client. </div><div><br></div><div>Why is this occurring? Does the Rtpbin reset the pipeline clock? Does the state of the pipeline change and create a new rtp session with the previous client? <br></div></div>
</blockquote></div><br></div>