1738504 - [jitsi] Using simulcast and RTX on non ideal networks results in bad call quality

Status: RESOLVED INCOMPLETE

(Core :: WebRTC: Audio/Video, defect)

Description

[Nils Ohlmeier [:drno]]

Jitsi is using simulcast to be able to save bandwidth on the receiver side, depending on how the senders video is rendered locally on the receivers screen.
It turn out that if simulcast and RTX are both negotiated the call experience gets pretty bad if the network conditions are not ideal.

I tested this with a 2% artificial packet loss added through Apple's Network Link Conditioner. With that 2% loss I see lots of RTX packets. Sometimes these RTX packets are bandwidth probing packets AKA empty packets with padding only (it looked like the bandwidth probing packets were always send right after an actual retransmission, but I haven't verified that). But sometimes there isn't a single RTX packet with padding in it at all. In these cases the receiver turned off rendering the video of the sender, probably because the SFU doesn't get any bandwidth estimates from that client.

• If I test with the same 2% packet loss, with simulcast but no RTX everything works as expected.
• If I test with the same 2% packet loss, RTX on but no simulcast everything works as expected.

We are hoping that this gets improved by the libwebrtc update tracked in bug 1654112, but to be sure that this doesn't fall through the cracks and in case the libwebrtc update doesn't improve this I'm filing this unfortunately rather vague bug report.

Comment 1

[Michael Froman [:mjf]]

Nils, we just merged the libwebrtc update today, so it should be in Nightly over the next day or so (possibly tomorrow morning). Would you mind rechecking?