The server (jitsi videobridge) DOES have the keys to decrypt the traffic - i.e. its not e2e encrypted. This is par for the course with webrtc SFUs (there are some "workarounds" to support e2e encryption over webrtc I mentioned in another thread).
The Jistsi team says the server needs roughly 5.5Mbps per Chrome user. Firefox uses a lot more bandwidth, system resources, and degrades the room capacity.
Just something to keep in mind, and after some testing I saw the same results.
My AWS bill was projected to be over $1k/month, so I put it on Linode where it'll cost between $100-200/month. Just about any decent VPS provider would be good options compared to AWS due to bandwidth.
> The Jistsi team says the server needs roughly 5.5Mbps per Chrome user.
That sounds like a lot! I wonder why an almost still image can use that much bandwidth, I guess it has to do with the low-latency requirement but I would love more details on that.
We use a technique called simulcast. It consists on making every participant "work a bit harder" for the good of the bunch.
That is, every participant sends 3 separate video resolutions to the server: 720p, 480p and 180p (this may change due to bandwidth constraints). Then the server will only forward the approopriate layer to each other participant. So, if you are only seeing me in a thumbnail it will only forward the 180p layer. If I become the active speaker (or you choose to pin me to the large view) the server will immediately switch to forwarding the 720p layer.
In addtion, we use SVC with temporal layers, so thumbnails may be given at just 15fps or even less.
We do have a trick up our sleeve (but IIRC it haad to be disabled for the time being) which involves disabling the ssimulcast layers that nobody is requesting. That is, if nobody iss seeing me in the large view, why send the 720p layer at all?
SVC spatial and quality layers [1] sound like a really good solution to the bandwidth issue. From my (extremely limited) understanding, basically if you skip certain packets you get a lower resolution/quality stream. A client sends a single stream at the best quality it can tolerate, and then the SFU can forward whichever layers to each client depending on what resolution that client wants.
What's the state of this in jitsi? I can only find limited info about SVC [2] and that is only on temporal layer. How much bandwidth does it even save in practice - maybe it's not worth the complexity trade-off?
Thanks for your interesting answer. It doesn't really address my question though, so I will rephrase it:
If I take a 720p video of a webcam and encode it to be delivered as progressive live streaming, the resulting stream is going to be less than one Mbps : because the image doesn't move much, I don't need many key-frame, one every 4 seconds is more than enough, and I've seen streams with no more than one every 30s (live streaming of harbours' CCTV cameras, don't ask me why). But of course it won't be realtime either, and you're gonna have a few seconds of latency. While this is OK for live streaming, it is certainly not for a video chat room.
What I'd like to know is why the latency requirement reduces that much the encoding efficiency. Do you have an idea ?
Naive (and perhaps stupid) question here, why don't you request just the 720p feed from each participant and then rescale the streams as clients need them?
The server would have to downscale the received stream. That's at least one round of downscaling for each participant, possibly more if you want to send different quality versions of the same stream down to different participants.
And while your device is quite capable of rescaling your stream -- even a lowest-tier smartphone will do it with no strain on its GPU -- its much more of a strain on the server to rescale 100's/1000's of stream simultaneously.
Additionally: AFAIK you can't easily rescale an encoded stream: you need to decode it, rescale it and then re-encode it. For every single stream! That would be horribly computationally expensive.
Almost still image is a weird way of saying “numerous still images regardless of amount of motion, that have to be stitched together in precise time sorted batches to provide a smooth experience for the viewer.”
Thinking about the use case it’s obvious this isn’t a simple calendar app amount of data.
I bet if you create some images in various resolutions these services support and what looks good to your eye, then fill folders with sequences of them, you’ll see why it’s a lot of bandwidth.
Better to over communicate and let the client deal with the organization as it’s designed to and not let some network admin nickle and dime over bits.
Financial economy doesn’t really say much about the literal economy of building all these toxic gadgets.
Given the big picture, not sure why such a trivial concern as bandwidths ephemeral money cost would foster such strong curiosity.
If you had 4 people the video was going trhough the JVB for sure. Since a Jitsi Meet installation uses multiple components, maybe you didn't shut them all?
Video shenanigans can be a dark art, but not that magical ;-)
Very possible the docs are wrong - im not a jitsi dev, so I wouldnt be able to confirm or deny without poking around. BUt they do specifically state that (as linked).
That said, it is worth pointing out that this thread is specifically about videobridge (i.e. scaling beyond a full mesh).
It is to note that traffic does go through the server, hence need decent bandwidth. the server afaik does have the keys to decrypt traffic