Jitsi Meet – Improving Scale and Media Quality with Cascading SFUs (2018)
webrtchacks.com
webrtchacks.com
Obviously as we stopped using Zoom we have to manually upload all our personal data to Facebook now.
I feel like there is a joke that's going over my head or I simply don't understand. Why you have to manually signup/login/auth/whatever with Facebook because you're using Jitsi now, especially on your own host?
It's a bit ironic that somewhere, someone is switching from Firefox to Chrome because of data concerns with Zoom.
Jitsi works fine with small groups. But if we have >10 Firefox users in a room it doesn't for us. Maybe if you have much better internet than we have or otherwise better resources it works for you?
We were using a WebRTC based tool before Corona (DFN), and had deprecated Zoom, unfortunately the people running that didn't manage to scale it up sufficiently in the crisis, hence we had to fallback to Zoom.
On osx using chrome, it was flawless.
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
Traffic only goes through the server for users behind NAT, triggering the TURN path.
Source: https://github.com/jitsi/jitsi-meet/blob/master/doc/manual-i...
That said, it is worth pointing out that this thread is specifically about videobridge (i.e. scaling beyond a full mesh).
Video shenanigans can be a dark art, but not that magical ;-)
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.
I'm starting an ISP again, we will charge around $0,25 per TB
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.
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?
Hope that helps!
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?
[1] http://webrtchacks.staging.wpengine.com/chrome-vp9-svc/
[2] https://github.com/jitsi/jitsi-videobridge/blob/master/doc/s...
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 ?
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.
Even then, code is in a repo. Go learn.
I'm kind of fearing trying to deploy it in my company. This has nothing to do with Jitsi Meet and everything to do with the shitshow that is WebRTC in browsers.
I can't find any desktop browsers that use the available GPU for hardware accelerated video encoding. Chromium (Google and Edge) says it's "only available on Chrome OS and Android". Firefox has a flag with no scare-provisos, but I've been unable to tell if it's had any effect.
By default, every browser on my system was setup to prefer the Intel UHD GPU. I've got an NVidia GeForce RTX 2080 in this laptop. Why not use that?
One of the reasons is that all the browsers have a software-rendering blacklist for certain combos of OS/hardware/drivers. There are rare cases where errant WebGL code can cause a full system crash on (checks notes) Android. So if you're one of the unlucky many who have these combos, but also an operating system smart enough to put graphics drivers into userland, you're taking the fast-train to turning your laptop into a blow-dryer. So they tend to take the Intel GPU over the NVidia GPU because apparently Intel's hardware+drivers isn't as buggy.
You can override it in the hidden settings, which means nobody overrides it.
All of this is to say, you could have a very powerful computer and still have very poor WebRTC performance.
hint: it's not nvidia.
Considering that i can play Full-HD H.264 videos with minimal load then this seems ridiculous.
I suspect you are hitting on the exact issue I'm having. I have a Thinkpad with just the Intel 5500 GPU, nothing superb. So, how do I figure out if at least that is being used or not?
I'm on GNU/Linux here.
But anyway, yes, I see specifically an uptick in the CPU dramatically with meetings, distinct from other browsing.
The Jitsi team gave some specific numbers on room capacity in the forums. Each room should reliably handle 20-35 Chrome users (Firefox uses roughly double the resources), and has a cap at 75. Apparently if you're only using audio, then rooms of 70+ people will work fine.
They're working on upping this number to 500 for configurations that have multiple bridges, as well as improving the UI to account for larger meetings.
https://www.reddit.com/r/firefox/comments/fsz3rk/implementat...
Super easy, + SSL!
Billions of users who aren't using linux distros with aptitude have an excuse. This isn't remotely close to the "just works" that you need to get wide adoption.
Of course if you don't selfhost anything it's not option for you.
There's a weird interaction between the NOFILE security limit (`ulimit -n`), Java 8, and Linux-based containers (noted on both LXC and Docker). If NOFILE is too high, Java 8 will paradoxically run out of memory as it tries to allocate some huge number of file descriptors. That took a while to figure out, since generally when you get an error about exhaustion of file descriptors, you expect the opposite!
So just set a lower security limit, right? It doesn't seem to work, I'm assuming because something in the Jitsi install process decides it needs to set them really high for the install session. I haven't debugged what component specifically is doing this yet. This results in the install scripts crashing when the installer tries to initialize the Java CA store.
In theory one could wait for that crash, reset the file limit, and then resume the install process. This works to a certain point, but every time I tried it, the crash in the CA store initialization would leave the dpkg database in a badly broken state that `apt-get --fix-broken install`, `aptitude`, and some manual dpkg futzing wasn't able to fix in the course of the 3-ish hours I spent working on it (complains on libc6-linux-dev package install that /usr/include/linux/something-something.dpkg-new doesn't exist; that folder structure isn't present on disk).
Technically Jitsi is set up by this point because the crash occurs as part of the certbot bootstrap, but I was working on getting Janus to work anyway and just tried out jitsi-meet because they had an autoinstaller that would set up Prosody, JVB, and all that good stuff anyway, so it wasn't really worth plugging through the rest of the way or dealing with the broken half-installed Jitsi, especially since there are many warnings about how you must configure the SSL bits properly in the install documentation.
But it'd be great if someone wanted to fix all that and make my life easier. :)
OpenVidu is one such service, it builds _upon_ Kurento, and itself can be used to make videoconference rooms very easily. Otherwise, Kurento is just a media server that handles media but doesn't have the concept of "rooms", "publishers", "consumers", escalability, reliability, etc. so you would have to develop all those things on your own.
One-on-one calls through Riot _are_ encrypted, but only if made in a one-on-one direct chat.
Recently we added the option for people to use their own self hosted Jitsi instances, if they prefer.
(1:1 calls at the moment are normal WebRTC, directly over Matrix)
Included: "Fix the order of the simulcast streams for Firefox."
Subscribe to this issue to keep track of things: https://github.com/jitsi/jitsi-meet/issues/4758
From the latest comments you can see that Firefox upstream is also improving things.
Edit: got it, it's that particular feature still missing.
100% support for Firefox (and other non-Chrome browsers)
I figured using anycast IPs, and having server to server communication across regions before then sending back down to the client would be ideal. Each offer and answer signaling would be done via distributed pubsub (e.g. embedded nats) and general persistence also distributed (e.g. something simple like dqlite). Has anyone had success with distributing WebRTC channels like this? Are there any concerns with redistributing, say, raw h.264 and opus as is without special concern for buffering or transcoding? How do slower consumers handle a fast set of UDP packets?
Also, I doubt there's a way, but anyone familiar with an end to end encrypted approach with WebRTC and DTLS when a server is in the middle? I figure not since offer/answer is for a single peer instead of broadcast and I see no approach in the browser to doubly encrypt media streams.
0 - https://github.com/pion/webrtc/tree/master/examples/broadcas...
Using TURN servers instead would not have the benefit of SFU (i.e. clients will have to upload to each peer) - i.e. its still a full mesh network.
Using TURN servers with SFU would work similar to your pion solution, however it would also use more bandwidth, as it would be forwarding the same streams multiple times for each peer routed through that TURN server (instead of once per stream with SFU)
As for e2e encryption over webrtc via an SFU - yes, this is possible, but its currently very messy (wasm video encoding and encryption streamed over an SFU-bound datachannel with full mesh distribution of the encryption key). There are plans to implement "Insertable Streams" which you will be able to transform (e.g. encrypt) which will allow this to work without the hacks.
So currently Jitsi meet the one on the web site is NOT e2e encrypted?
I haven't checked, but its possible for 1-to-1 or small meetings they may go full mesh, which would be e2e encrypted - a few platforms do this.
edit: just checked and jitsi is "full mesh" for 2 participants - if you have 3 or more (video) participants, it switches over to SFU.
For creating a room, you need an account on Zoom and it's generally complicated to get to from the homepage. With Jitsi, right on meet.jit.si, you simply pick your url name and you're in.
For joining, Zoom kept trying to push me to download the app, and had to press two tiny buttons to get it to open in the browser. But by default you have no audio or video, so I had to spend 10m teaching my parents how to enable theirs. With Jitsi, it opens right in the browser, and video/audio work with no issue once they accept browser permissions.
At every step, zoom tried getting me to sign up or download their app, whereas Jitsi works fully in the browser with no account. Creating the room is a single click and I get to pick the url too.
For now, it seems the best audio/video quality can be achieved by all participants using a Chromium-based browser such as Chrome and Edge.
---
¹ 100% support for Firefox (and other non-Chrome browsers) - https://github.com/jitsi/jitsi-meet/issues/4758
² Bugzilla keyword jitsi-meet - https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_t...
EDIT: Thanks!
> Selective Forwarding Units (SFU)
SFU stands for Selective Forwarding Unit.
At times, the term is used to describe a type of video routing device, while at other times it will be used to indicate the support of routing technology and not a specific device.
An SFU is capable of receiving multiple media streams and then decide which of these media streams should be sent to which participants.
and