Long video stream recovery on receiving side

Hi!

We are building a video conference solution on the top of the Jitsi. Our code interacts with jicofo and establishes direct connection with videobridge using webrtc. During testing, we noticed that after a network issue (packet loss or corruption) video frames stopped to render for significant time (30-60 seconds). And even frequent keyframe encoding does not help with frames receiving recovery.

Are any configuration settings for VB that speed up recovery process? Or using keyframes for recovery?

You can try it out on meet.jit.si and see what sdp look like when establishing PeerConnection to the bridge and compare it with your sdp. chrome://webrtc-internals
There are many things in play like nacks, plis, firs and that is already handled when using lib-jitsi-meet with jicofo and the bridge.

Thank you for a quick reply, Damian.

I tried to reproduce SDP as close as possible to jitsi web interface during negotiations. Part of SDP offer for sending video stream looks like below:

SDP
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=fmtp:100 x-google-start-bitrate=800
a=rtcp-mux
a=ssrc:2101984102 msid:25ca3df8-video-1 video
a=ssrc:518076561 msid:25ca3df8-video-1 video
a=ssrc-group:FID 2101984102 518076561

Could these settings affect recovery? Also, connection is not using (and not negotiating) an audio stream. Does it matter?

Did anyone see the similar issue? Please help.

You can take a look how this project handles that GitHub - avstack/gst-meet: Connect GStreamer pipelines to Jitsi Meet conferences

Hi @damencho,

This project is used as reference for our solution. Unfortunately it is built with Rust thus it is hard to use it directly in the project.

Anyway, could you help with troubleshooting these connectivity issues? Could you PM, please?

We keep the questions in the public part of the forum.
And nope, sorry, I’m not so familiar with those mechanisms to be able to help you. I was just giving you some resources as guidance if those can help you figure that out.
And debugging custom implementations is not our goal here, if there is a problem on jicofo or jvb side, sure we can check, but when it is working with jitsi-meet doesn’t seem to be any problem there, sorry.
You can also check with avstack guys, whether they had experienced something similar when doing their custom implementation.