I have two streams feeding into the udpsrc attached to a gstrtpbin. One stream is live data and the other is from a audiotestsrc intended to wake up the pipeline (blocked waiting on the async recv_rtp_src_%d_%d_%d pad to connect.) It is not always possible to know the order the streams will arrive, so either may be "first".
noise stream =======\
>>> udpsrc---->gstrtpbin
live stream=========/
When the first stream connects, cb_pad_added in the receiver pipe finishes the async connection from the recv_rtp_src_%d_%d_%d pad to the rest of the receive pipe.
When the second stream comes online, I get a second callback indicating a new recv_rtp_src_%d_%d_%d pad has been requested. Makes sense, the second stream should have a different SSRC.
Wanting to know which stream was which, I added an identity to the pipe producing the "noise" stream between the payloader and udpsink and connected a pad_probe to it. The cb_pad_probe() does nothing more than tell me the SSRC of the packets. Figured I could use this info to tell the main gstrtpbin which connection to keep.
,---padprobbe() {print ssrc}
|
--->encodeer-->identity-->udpsink === noise stream =======\
>>> udpsrc---->gstrtpbin
live stream=========/
Well, lo and behold, the SSRC reported from each packet is different! Siimilar looking numbers, but different. What I don't get is a message from the cb_pad_added() in the main pipe telling me each different SSRC is requesting a new recv_rtp_src_%d_%d_%d pad!
So, friends, why are the SSRCs different and whay does the gstrtpbin see them as equivalent? How does it tell the next stream is different? *both streams have payload type = 96).
I am about to add an identity between the udpsrc and the gstrtpbin to see it sees the same thing. Will add that information when have it.
Warmly,
Wes
Locked
