JVB how to video quality is determined

Hi everyone!

We recently installed the Jitsi meet latest release (Oct 7th 2021 jitsi-meet 2.0.6433-1, JVB 2.1-570-gb802be83-1) on Ubuntu 18.04.6.

Previously we have a installation of (Jan 2021 version Jitsi-meet 2.0.5390-3, JVB 2.1-416-g2f43d1b4-1) on Ubuntu 18.04.5

We used Jitsi internally and through the lib-jitsi-meet so the bandwidth is not an issue (all through LAN) We notice that compared to the Jan version (JVB 2.1-416) , this new JVB 2.1-570 has more intelligence( more improvement) sometimes it seems delivering a rather mediocre quality.

To make things comparable, on this new server, we played with different version of the JVB and found that Jun 10 version (JVB 2.1-508) seems on-par with older one so Please find below the screenshot for the video quality from the client side (everything was equal, just the JVB version different, Oct 7th 2.1-570 vs Jun 10th 2.1-508)

First one is Latest Oct 2.1-570 and Second one is Jun 2.1-508.

You would notice that the good one(508) did a quick dive and then promptly back to HD again… the latest one (570) did more slowly and sometime dive deeper(180P). From the user’s visual perspective, one is super sharp and the other is acceptable.

One interesting thing is that when the quality is bad (say 180P), if we refresh the page again… (restart the session), we will then get the 720P again! for about 1 or 2 minutes and then dive to 360P or 180P again…

I am new to the JVB and I would like to understand more about it. As bandwidth is not an issue and I would like to know if there is option saying “no matter what, just always push the HP(720P) to the client”. Or there are some parameters or threshold I can tweak. I can even dive into the code if someone give me a help to show me where this decision is made in the JVB code.

Again. Jitsi is awesome and thanks for the best open-source video conference solution and such a useful and positive community around it!

1 Like

this problem has been so beaten to death on this forum, I can’t remember everything. Most important is that JVB has been enhanced to allow better taking in account of bandwidth indicators coming from clients, unfortunatly these indicators are not always truthful. It’s probably best to use Chrome at latest stable version. It has been suggested to remove this bandwidth handling altogether by setting

 cc {
    trust-bwe=false
}

in jvb.conf as stated here, but by itself it’s not a great workaround. Read the linked post to understand more. Good reading.

1 Like

@gpatel-fr Thanks for the good advice! It works like a charm.

A beautiful straight line represents the sharp clear picture on the client side. No more blurry and mediocre. very nice!

I also tried to play with other parameters, nothing works. (see jvb config for more )

    cc {
      #bwe-change-threshold=0.32
      #max-time-between-calculations = 5 seconds
      trust-bwe=false
    }

I will dive more later but I think that maybe the client side (I am using latest Chrome 94) send wrong bwe. The ‘FrameDrops’ is not critical as long as the ‘FrameDecoded’ maintains the slope and don’t dive it should be fine.

More readings

  1. BWE is on the Sender side now ( tcc vs old remb )
  2. RTCP for CC ( rfc8888 )

The root cause might be (my guess) the downside of the TCC ( 2 downsides ) the Sender (JVB) does not know if the packet lost is due to really the packet is lost (due to congestion) or the feedback from the client is lost (due to the async link property for the client, i.e Download is way better than Upload so the packet is received (download) but the feedback is lost(upload) ).

I don’t think your tests are correct, you need to update the whole suite when testing, with jicofo and ljm and jitsi-meet. Since January there are changes in the communication between the client and jvb …

@damencho Thanks for the reply. We learned a lot from your replies in the past posts.

For our setup, we did do a whole suite

rc  jitsi-meet                             2.0.6433-1                                      all          WebRTC JavaScript video conferences
ii  jitsi-meet-prosody                     1.0.5415-1                                      all          Prosody configuration for Jitsi Meet
ii  jitsi-meet-web                         1.0.5415-1                                      all          WebRTC JavaScript video conferences
ii  jitsi-meet-web-config                  1.0.5415-1                                      all          Configuration for web serving of Jitsi Meet
ii  jitsi-videobridge2                     2.1-570-gb802be83-1                             all          WebRTC compatible Selective Forwarding Unit (SFU

)

As JVB was relatively an independent module and we were doing the upgrade/downgrade only for JVB. So we have old server that was in January whole suite version and we have this new server in October whole suite version and we only downgrade the JVB on this new server to September, August, July and June and finally we found the June seems more reliable in our case.

For this new October version , we later did find the following configuration seems improve the quality a lot and we don’t understand why? If you could share some insight that would be very helpful!

    cc {
      bwe-change-threshold=0.05
      padding-period=100ms
      #max-time-between-calculations = 15 seconds
      #trust-bwe=false
    }
1 Like

You need to update jvb, jicofo and lib-jitsi-meet together, this was and will be always the assumption with the projects.

There are changes on all fronts, for example, there is a new message for selecting what to be sent as HD sent from lib-jitsi-meet …

@damencho Thanks for the detailed reply and we will do proper test and come back later. Have a great weekend!