Server routed video quality issues? (but p2p and other MCU's are great)


#1

Hi there,

We are building an Electron app using the Jisti library pointing to our Jitsi video bridge.

The good news is p2p call quality is fantastic which is great.

But server routed calls I consistently see poor video quality on the network (home network) I am testing multiple machines.

The quality looks worst in our electron app on server calls. But also found almost as bad quality on standard jisti meet calls to our server and even standard jisti meet calls to meet.jit.si.

However other desktop and Webrtc MCU calls dont suffer, such as Cisco Meeting Server (CMS) webrtc h264, Webex Webrtc h264, Zoom on Zoom app.

Speed test isnt the problem… http://www.speedtest.net/result/7823471220

See the images here. Did tests will all bridges for both 2 participants and 3 participants so you can see the issue…

https://drive.google.com/drive/folders/1XcagNd-SGVBYop-9evyrafyO0hhCnyH1?usp=sharing

Is this a known bug?

Is this because they are on the same network and the algorithms are having a hard time determining available bandwidth??

Thanks
Daryl


#2

Any news on this one please? Thanks


#3

Hi Daryl,

Apologies for the late reply, things have been pretty hectic in the past weeks. We did however manage to push a fix that addresses some “quality” issues with the bridge.

This is the commit with the fix: https://github.com/jitsi/jitsi-videobridge/commit/4940a70ade6bf55240cac052d9b16e3503b2f8dc

Yes, it’s just one line; and it’s enough to screw things up.

Could you please try to upgrade your bridge to the latest version (1093) and run your tests again?

Cheers,

George


#4

Thanks for the reply George, I believe we already are on that version…

itsi-meet/now 1.0.3393-1 all [installed,local]
jitsi-meet-prosody/now 1.0.3089-1 all [installed,local]
jitsi-meet-web/now 1.0.3089-1 all [installed,local]
jitsi-meet-web-config/now 1.0.3089-1 all [installed,local]
jitsi-videobridge/stable,now 1093-1 amd64 [installed,automatic]

Is that correct?

If so our specific problem still exists


#5

Hi Daryl,

Yes, apparently you’re on the latest version of the JVB; and so the problem still exists there and, from your description, I agree with your guess that something is wrong with the bandwidth estimations.

It’s something that’s been brought up in the past and we’re actively working on improving that part of the system.

I can spend some time trying to understand your measurements and see if there’s any immediate steps we can take in order to improve the situation.

Could you please make the measurements public or grant me with access to the folder and/or document that contains them?

Many thanks for performing the tests and documenting and reporting your findings.

Cheers,

George


#6

Thanks George.

Not exactly sure what you mean by “measurements”?

I get my Mac back on Tuesday (damn the new Macbook Pro keyboards) and can replicate all of these symptoms.

Would it be easier to jump on a live call and show you?

My previous observations of this issue appear that the upload speed is pretty much always consistently good on all machines. But the download speed drops to a really bad level on some of the machines on the same home network. Obviously strange given higher internet download speeds and per my screenshots I dont see this issue on other meeting platforms.

I’ve not had the chance to test the same devices on other networks yet.

Thanks
Daryl


#7

Not exactly sure what you mean by “measurements”?

For some reason I thought you had captured some sort of measurements in the shared G drive folder that you shared with us, but upon re-reading your initial message, it looks like you have screenshots.

Would it be easier to jump on a live call and show you?

Let’s try first to gather some debugging data.

My previous observations of this issue appear that the upload speed is pretty much always consistently good on all machines. But the download speed drops to a really bad level on some of the machines on the same home network. Obviously strange given higher internet download speeds and per my screenshots I dont see this issue on other meeting platforms.

You mentioned you’re running your tests on your home lan. I would assume this is a WiFi setup, right? It would be helpful to run the test for a while, say 1 minute, with Chrome browsers only and then download the webrtc-internals here are some instructions how to do that). You can share your results here.


#8

Thanks George.

Yes Wifi with Google Wifi pods (happens on ethernet too).

Will send the WebRTC internals on Monday. With more screenshots and speedtest too.

I’ll do the test just to meet.jit.si.

Have a good weekend!


#9

Hi Daryl,

Sounds good. So we’ll have the following four scenarios:

ethernet+meet.jit.si
wifi+meet.jit.si
ethernet+own deployment
wifi+own deployment

This should allow us to draw some conclusions and hopefully better understand the issue.

Have a smashing weekend!

Cheers,
George


#10

Hi George,

Have completed these webrtc internals tests as requested. Some of the file names are off because of when you click the “create dump” dropdown, but made sure they are all in the correct folder.

https://drive.google.com/drive/folders/1XcagNd-SGVBYop-9evyrafyO0hhCnyH1

Is there anything else you need here?

Thanks
Daryl


#11

Hopefully you have everything you need here?


#12

Just requested access to the logs. There must be something wrong with the bridge, so I’ll definitely take a look.


#13

access granted on Google drive. thanks


#14

Hi Daryl, I started looking at the meet.jit.si/ethernet stats. It’d be helpful if you could confirm some of my observations.

  • It looks like that the Mac has somewhat reasonable download/upload speeds 1-1.5Mbps upload and 1.5-2Mbps download speeds.
  • PC1 has issues, both the download/upload speeds suffer. Most of the time the upload speed is bellow 1Mbps and the download speed is much really low. Something to keep in mind here is 1st that the download speed is determined by the bridge and the upload speed is determined by Chrome and 2nd Chrome has an improved version of the congestion control algorithm employed by the bridge.
  • PC2 has the best upload speed, it’s pretty stable and it’s sustained above 2Mbps. The download speed suffers but it could be because it focuses on PC1 that achieves low upload speeds and also because our bandwidth estimation algorithm is “inferior” (in the sense that I previously described) that the Chrome algorithm.

I will keep looking into those graphs, let me know if you have any comments on my remarks.