Any participant can affect availableOutgoingBitrate for all other participants when using VP9

[bukharin]

Description

I found strange behavior: estimated bandwidth is affected when remote participants join or leave

All tests run in Chrome 116, but I think this problem exists in all chromium based browsers, including Electron.

On meet.jit.si you have 2 bitrate limits for VP9 video codec:

• 1200 kbps for camera tracks
• 2500 kbps for screen share track (default config value)

Steps to reproduce

• Open same conference in two tabs (as Participant A and Participant B) with disabled P2P, like https://meet.jit.si/blabla#config.p2p.enabled=false. (disabling p2p does not matter but allows to minimize reproduction path)
• You will see that estimated bandwidth for participants will be limited to 1200 kbps (camera track limit). It strange but no real problems expected yet
• Start screen share from Participant A. After that you will see 2500 kbps as estimated bandwidth. Now it may cause a problems, because Pariticpant A may need 3700 kbsp of bandwidth for two tracks (2500 + 1200)
• During screen sharing, join as third Participant C. Now estimated bandwidth for Participant A will be reduced to 1200 kbps and it may be a reason of quality limitations.
• Next, Participant C leaves the conference. After that Participant A bandwidth limit will be gone
  
• Join with Participant C again - bandwidth of Participant A will be reduced to 1200 kbps again...

Summary

• When any participant joins a conference, estimated bandwidth for all participants on VP9 video codec can be limited by configured video bitrates.
• When any participant leaves a conference, the estimated bandwidth limits reset.
• When any participant joins a conference, screen share video quality for all participants may be reduced 😒

[bgrozev]

I can not reproduce this. Can you try again with the latest meet-jit-si? I see 2500 before and after I add a 3rd participant.

Estimated bandwidth is affected by the network conditions as well as what we have available to send. It could be reset to one of the round numbers (1200, 2500) after constraints are applied, but it should go up if we send closer to the limit or down if the it detects congestion. Your 2nd and 3rd screenshots don't necessarily indicate a problem because we have sendMax=180p, so we'd be sending up to ~1350Kbps (1200 ss + 150 camera). If the screensharing stream has stayed at a low rate this could explain the 3rd screen shot, but if the encoder produces a higher bitrate it should ramp back up.

Do you have a case where actual sending bitrate is affected by the presence of a third participant (note the "sendMax" option which may change, that's expected)? Or am I misunderstanding something?

[bukharin]

@bgrozev yes it reproducible on meet.jit.si. May be in your test p2p<-->jvb switch affects.

I did another following test:

• Join 1 and 2 participants
• Start sharing for participant 1
• Join 3d participant
• Join 4th participant
• Place camera from participant 1 on stage in participant 2 tab to increase outgoing bitrate request.
• I see the following stats from partcipant 1. As you see my bitrate is very closer to estimated bandwidth and I send only 360p from my camera
• In webrtc-internals I see bandwidth quality limitation reason for camera and desktop tracks
• Leave by 4th participant
• Stats from participant 1 looks good now and start sending 720p

Also if bandwidth calculated by network conditions it cannot be equal to round digit like 1200 or 2500 kbps

[bukharin]

No more reproducable