WebRTC calls are failing regularly

Application Development
1

Hello,

I’m using GStreamer to do my webRTC implementation in the desktop frontend of my XMPP client (on Linux), so XMPP is used for signaling. The code is in Python.

It’s working as expected from time to time, but often (ca. 1 call on 3), it’s blocked and I have no video, or nothing at all. I have a web frontend with browser’s WebRTC implementation which is working, so I don’t think that signaling is the problem.

Note that I’m new to GStreamer.

Here is my pipeline:

        self.gst_pipe_desc = f"""
        webrtcbin latency=100 name=sendrecv bundle-policy=max-compat

        v4l2src name=video_src
        ! videorate
        ! video/x-raw,framerate=30/1
        ! tee name=t

        t.
        ! queue max-size-buffers=5 max-size-time=0 max-size-bytes=0 leaky=downstream
        ! videoconvert
        ! vp8enc deadline=1 keyframe-max-dist=60
        ! rtpvp8pay picture-id-mode=15-bit
        ! application/x-rtp,media=video,encoding-name=VP8,payload={video_pt}
        ! sendrecv.

        t.
        ! queue max-size-buffers=5 max-size-time=0 max-size-bytes=0
        ! videoconvert
        ! appsink name=local_video_sink emit-signals=true drop=true max-buffers=1 sync=True

        pulsesrc name=audio_src
        ! queue max-size-buffers=10 max-size-time=0 max-size-bytes=0
        ! audioconvert
        ! audioresample
        ! opusenc audio-type=voice
        ! rtpopuspay
        ! application/x-rtp,media=audio,encoding-name=OPUS,payload={audio_pt}
        ! sendrecv.
        """

You can see it in the whole source at libervia-desktop: 4d45bed01183 libervia/desktop_kivy/plugins/plugin_wid_calls.py

The log with export GST_DEBUG='3,*webrtc*:4' is available at Debian Pastezone

I have those obvious issues when pad are dynamically added:

====> NAME START: audio/x-raw
===> Audio OK
0:03:46.049997933 23677 0x7f8674001c70 WARN          v4l2bufferpool gstv4l2bufferpool.c:483:gst_v4l2_buffer_pool_alloc_buffer:<video_src:pool0:src> newly allocated buffer 4 is not free
0:03:46.052448305 23677 0x7f8668016820 WARN                audiosrc gstaudiosrc.c:227:audioringbuffer_thread_func:<audio_src> error reading data -1 (reason: Success), skipping segment
0:03:46.076209248 23677 0x7f8674001650 WARN         audio-resampler audio-resampler.c:274:convert_taps_gint16_c: can't find exact taps
0:03:46.101186835 23677 0x7f8674001090 INFO    webrtctransportsendbin transportsendbin.c:454:gst_transport_send_bin_element_query:<transportsendbin3> configured latency of 0:00:00.000000000
0:03:46.191914100 23677 0x7f8674002c00 INFO               webrtcbin gstwebrtcbin.c:7573:on_rtpbin_new_ssrc:<sendrecv> session 0 ssrc 3012442576 new ssrc

and

====> NAME START: video/x-raw
===> VIDEO OK
Original video size: 352x640
0:03:47.607957238 23677 0x7f8668016820 WARN                audiosrc gstaudiosrc.c:227:audioringbuffer_thread_func:<audio_src> error reading data -1 (reason: Success), skipping segment
0:03:47.608131265 23677 0x7f8674001c70 WARN          v4l2bufferpool gstv4l2bufferpool.c:483:gst_v4l2_buffer_pool_alloc_buffer:<video_src:pool0:src> newly allocated buffer 6 is not free
0:03:47.611359561 23677 0x7f8674002ee0 INFO    webrtctransportsendbin transportsendbin.c:454:gst_transport_send_bin_element_query:<transportsendbin3> configured latency of 0:00:00.000000000
0:03:47.614018791 23677 0x7f8674002c00 WARN         rtpjitterbuffer rtpjitterbuffer.c:575:calculate_skew: delta - skew: 115219:03:38.743758001 too big, reset skew

What am I doing wrong?

Thanks!

2

I have generated dot files when it’s working or not:
working: https://partage.jabberfr.org/F74Tpch5DAh9T9GUtIQ-jGGz/pipeline_working.png

Not working: https://partage.jabberfr.org/Kf8QI6_0wHUcQOTVcb7MS4MT/pipeline_not_working.png

In the later, we can see that the source pad is not created in the rtpptdemux element handling the sending of the video stream, but I don’t understand why. Rest of the pipeline looks really similar.

3

The rtpptdemux difference is possibly the cause. The pad is created when the first RTP packet is received. Try adding async=false to the appsink and see if that works better.

4

Thanks for your answer. async=false doesn’t change anything unfortunately.

I realize that I’ve posted the dot files with only the webrtcbin part, here are the full pipelines (in this case I’m using autovideosink and not appsink):

working:

not working: