WebRTCBin not receiving caps signal

[Pascal Jacquemart]

Hi Dominik,

I read your email a while ago and for some reason decided to implement
roughly the same thing. But I am having some trouble...
Sorry I could not help in the first place with your
'on-negociation-needed' message missing. It seems clearly a bug in the
webrtcbin as you described.

So in my case, I want to implement a one to one RTSP to WebRTC
transcoding. Seems rather simple but I never got it to work.
It seems that the RTSP connection takes few seconds to initialise and
the pipeline goes into many PLAY / PAUSE transitions before stabilising.
From this I understand that it is not possible to start with webrtcbin
in a static pipeline:

rtspsrc location=rtsp://whatever ! rtph264depay ! rtph264pay !
queue ! application/x-rtp,media=video,encoding-name=H264,payload=97 !
webrtcbin name=sendrecv bundle-policy=max-bundle

Then I tried your strategy to redirect the rtsp stream to fakesink and
only attach the webrtcbin later. In this case, I see the SDP exchange
but the other end never receive the video.

Have you seen this same problem before?

Thanks,             Pascal

On Sun, 10 Mar 2019 11:25:23 +0200
Dominik Röttsches <d-r at roettsches.de> wrote:

> Hi,
> 
> I am working on a python app that turns an rtsp stream from a
> networked camera into a stream that you can access through the
> browser via WebRTC.
> 
> For that, I am using a dynamic pipeline, the rtp audio and video
> streams go to a fakesink through a tee element. For each incoming
> websocket connection, I build an WebRTC connection: I am adding two
> queues, one for audio, one for video to the tee elements and connect
> them to a new WebRTC element. Then I exchange the SDP offer and
> response via websockets.
> 
> Now, in some situations, after quick reloads of the web page that
> brokers the connection, the newest added WebRTCBin element does not
> send the “on-negotiation-neeed” signal. I am assuming this is because
> it did not receive caps on the newly requested pad, thus the
> gst_webrtcbin_sink_event method did not get triggered and the
> WebRTCBin is not checking whether a negotiation is needed. 
> 
> A PDF of the pipeline is here:
> http://roettsch.es/debug_gst_webrtcbin.pdf and an image of the
> relevant portions is attached.
> 
> The WebRTCBin element sendrecv-2-772371 has blocked pads, as it
> hasn’t done any negotiation and unblocked its pads, but also the CAPS
> on the links to the queue elements only show “ANY”.
> 
> I have a few questions to further investigate this:
> 
> What could be the reason the caps event is not received by the
> GstWebRTCBin? When is the caps event usually sent downstream? Is it
> sent only once and could it be that the GstWebRTCBin somehow missed
> it through some race condition? When connecting queue and webrtcbin
> to the tee element, do I need to follow a certain order? Do I need to
> insert probes in order not to miss the caps event?
> 
> Thanks for your help,
> 
> Dominik
>