WebRTCBin not receiving caps signal

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

WebRTCBin not receiving caps signal

Dominik Röttsches
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


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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
>

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel