rtpssrcdemux: Does not behave correct when adding pads
All other demuxers are mandated to expose pads for which caps has been sticked to. rtpssrcdemux is doing something quite odd. If you only attach one of the input pad and push buffers to it (there is two sink pad, rtp and rtcp)) will will automatically expose two src pads (rtp and rtcp). One of the two pads won't have caps.
In this context, sending EOS to the sink pad was only sending EOS to the rtp pad. Which I wrongly fixed here:
I'm thinking it might have been the wrong fix, since conceptually, the events from RTP sink pad should be forwarded to all RTP sink pad, and the events from RTCP sink pad should be forward to all the RTCP src pads. So internal links should look like (if you have two SSRC):
[rtp_sink]------------------[rtp_src_0] | ---------[rtp_src_1] [rctp_sink]-----------------[rtcp_src_0] | ---------[rtcp_src_1]
But by creating and exposing the RTCP src pads regardless if there will ever be RTCP in the stream, we now create a really hard to handle bindings between the pads. With the current fix, what I think is happening, is that if we send new caps after the first buffer has been pushed, the caps will be sent to all pads, which does not seem to stick with the design.
I'm not too sure how to fix this yet. Dissociating the pad creation to only add the pad when caps are available will clearly break rtpbin. And then, there is no logic why this would be one element instead of rtpssrcdemux and rtcpssrcdemux (which different is in how the SSRC is extracted). If I keep the current violation of the usual pad-added contract, then I need to special case at least EOS, so EOS is forward to all pads, even if there was not stream-start yet. On this regard, I don't remember if EOS before stream-start is valid or not. I'd really like to get feedback. I am writing a unit test for that now, I have the forward case I was trying to fix working, and I am about to add a unit test to demontrate the regression it caused.
cc @slomo who was my reviewer