Adding another RtpBin to the pipeline

[Benjamin Trent]

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.

On Fri, Nov 7, 2014 at 3:09 PM, Benjamin Trent <ben.w.trent at gmail.com>
wrote:

> My pipeline design is this:
>
> 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.
>
> The first client connected works fine.
>
> 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?
>
> Each rtpbin has a unique name, all elements added have unique names and I
> am not sending duplicates to the previous client.
>
> 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?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20141110/442973fc/attachment.html>