Low video resolution when with VP8 codec

We have two Jitsi instances on AWS Paris, one of them is t3a.medium (4GB RAM) and another one t3a.small (2GB RAM).

When the smaller instance switches to VP8 (for example when a third participant joins the call), the video resolution is still aceptable (for example 640x360).

However, for the larger instance, in spite of having more memory and CPU and being on the same AWS data center, when the call switches to VP8, the video resolution does never exceed 320x180 for any of the participants.

Both instances have no other calls than the test calls we are doing.

Both instances have essentially the same settings under /etc/jitsi

Both instances are at the latest stable code:

ii  jitsi-meet                       2.0.4966-1                          all          WebRTC JavaScript video conferences
ii  jitsi-meet-prosody               1.0.4370-1                          all          Prosody configuration for Jitsi Meet
ii  jitsi-meet-turnserver            1.0.4370-1                          all          Configures coturn to be used with Jitsi Meet
ii  jitsi-meet-web                   1.0.4370-1                          all          WebRTC JavaScript video conferences
ii  jitsi-meet-web-config            1.0.4370-1                          all          Configuration for web serving of Jitsi Meet
ii  jitsi-videobridge2               2.1-304-g8488f77d-1                 all          WebRTC compatible Selective Forwarding Unit (SFU)

Can the video resolution be tweaked somehow to increase its minimum value?

We have further troubleshooted this issue and it seems that it is not related with VP( but with Simulcast.

If we force disable H264 in p2p section of conig.js file, the p2p call uses VP8 and video resolution is adequate with until a 3rd participant joins the call and then video resolution drops for all.

Any ideas? How is calculated video resolution in a Simulcast call?

For the time being, we ended up disabling Simulcast to work around the resolution calculation issues.

Possibly there is something wrong in the algorithm that determines resolutions in Simulcast that for some reason affects only one of our instances.

The downside is that now the setup with the workaround consumes a lot more CPU.