The server is receiving 1 stream per participant, and forwarding that stream to all other participants. So for say 10 participants, that's 10 inbound and 90 outbound.
If you switched to p2p instead, then each participant would need to send 10 streams instead of 1, and most people's upload bandwidth is much lower than their download (at least in the US).
It's possible for the server to make decisions on which video streams to forward (e.g. last x talkers) to reduce the number of outbound streams, but switching streams takes a bit of time (you'll need to get a new iframe from the just-switched-on participant) which affects the interactivity of the session.
Modern video codecs also allow for layering of into progressive levels of enhancement, so lower detail versions of the stream can be forwarded to participants will lower bandwidth without the server needing to transcode anything. (Not sure if Jitsi has implemented anything like that.)
Couldn't the server compose the streams itself? Perhaps as simple as tiling them all together and the client can manage that stream, or request single high quality streams if needed.
There'd be a CPU/bandwidth tradeoff being made here, I wonder how the prices on standard cloud providers would compare.
Sure, but that adds a lot of CPU load server side (and cloud CPU is still fairly expensive), adds latency for the extra buffering, decoding, and re-encoding, and limits the display options available client-side.
WebRTC should be capable of multicast, so nobody should be having to send X-1 streams for X users. I say should because it's incredibly hard to find out which parts the the WebRTC spec browsers actually implement. I just found an article from Mozilla from 2018 that just blithely mentions in passing some nebulous future date "when WebRTC is (hopefully) enhanced to support multi-user conversations." WTF have I been doing with more than 2 people in a WebRTC session for the last 5 years? What the hell has been going on in WebRTC for the last 9!?
If you switched to p2p instead, then each participant would need to send 10 streams instead of 1, and most people's upload bandwidth is much lower than their download (at least in the US).
It's possible for the server to make decisions on which video streams to forward (e.g. last x talkers) to reduce the number of outbound streams, but switching streams takes a bit of time (you'll need to get a new iframe from the just-switched-on participant) which affects the interactivity of the session.
Modern video codecs also allow for layering of into progressive levels of enhancement, so lower detail versions of the stream can be forwarded to participants will lower bandwidth without the server needing to transcode anything. (Not sure if Jitsi has implemented anything like that.)