rtspsrc creating multiple video source pads from single stream

[Tim]

Hi Tim,

Some more information on running with the additional logging you
suggested....

After the pipeline is commanded to play, rtspsrc gets a "new manager pad"
from rtpbin for the audio and ghosts it.  We get notified of this new
ghostpad and link it to our audio bin.  So far, so good.

It appears then in our failure cases that rtspsrc gets a "new manager pad"
from rtpbin for the video, but the sticky events it copies off the "new
manager pad" say the SSRC value is different from what is expected from the
SDP file.  And it just so happens this SSRC was previously used for the
video in the previous pipeline that is still PLAYING.

Shortly after that rtspsrc gets a "new manager pad" from rtpbin for the
video and this time it is the SSRC we'd expect.

My next step is to instrument rtpbin, rtpsession, rtpssrcdemux, rtpptdemux
to see what is happening in the lower layers that causes that middle
"manager pad" to be created by rtpbin.  We looked at the corresponding
wireshark capture and it doesn't look like there is any SSRC change for that
multicast IP/port combo that that session manager (rtpbin) would have
managed.  Is there some way that pipeline 1's video packets could be
intercepted by pipeline 2's video rtpsession?  Video traffic from video
source 1 and video source 2 use the same port, but different multicast
destination IPs (different multicast groups).

Thank you,
Tim



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/