Any participant can affect availableOutgoingBitrate for all other participants when using VP9 about lib-jitsi-meet

[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