> 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?
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.
I've been playing with a custom install of Jitsi Meet for the last few days. It was very easy to setup.
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.
I also had very bad experience with WebRTC in browsers. Just several days ago i tried videoconference with Jitsi Meet. Although it was receive only (no camera or mic), so no encoding, and received video was pretty low-res, it generated enough load on all my cores that after a while it triggered thermal throttling.
Considering that i can play Full-HD H.264 videos with minimal load then this seems ridiculous.
Does this explain why I get poor Jitsi experience on my laptop and better using the Android app on my phone??
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?
Something that isn't mentioned in the docs is room (and server) capacity, or at least rough estimates.
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.
Jitsi-meet is very easy to install and to setup.
"apt install jitsi-meet" and you have almost all done.
The documentation is very good.
It works great and it is super userfriendly.
You have no excuses.
Alternatives to Jitsi are Janus (mentioned in this thread) but also OpenVidu (formerly Kurento) and Mediasoup which provide building blocks to roll your own. All of these also have demos that you can use out of the box for our own conferences.
Just a nitpick: Kurento still exists on its own, and provides a generalist framework of components to build a service that can handle media.
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.
Riot isn't an alternative to Jitsi so much as a complement to it. Matrix is for text chat, and Riot uses Jitsi for calls; while you can embed a Jitsi client into Riot rooms, and it auto-shares the URL, AFAIK group calls are not E2EE even if the room is.
One-on-one calls through Riot _are_ encrypted, but only if made in a one-on-one direct chat.
I have been considering developing a simple video conferencing solution using this approach with WebRTC. Basically, I was planning on doing something like this example [0] of server-side peers or just a set of forced TURN servers, whichever approach being deployed on servers at the edge.
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.
I like Jitsi because it doesn't require any signups and it's simple to create a channel/room. But the quality of video and audio seems a bit lacking. Does anyone have suggestions on how to improve Jitsi Meet's video and audio quality when working with the official smartphone apps and platform (not self-hosted)? Sometimes (on a broadband connection), for some participants, the video from a broadcaster freezes once in a while, and worse, the audio is many a times not clear even when the video seems fine. This is with just three or four people in the call with one person turning on the video and audio (like a presenter), and the rest of them with no video and with their mics muted.
Are any of the participants using Firefox by chance? There are known issues being worked out ¹, some in collaboration with Firefox itself ², to improve performance and compatibility.
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.
Depends on the bandwidth charges of the SFU host, mostly that means computing the volume (5.5Mb/s * participants * duration) though some hosts aren't volume billed in which case it might then be a matter of whether sufficient data rate available (drop the duration) or paying for the peak consumed. That's just the A/V conferencing not file sharing or other incidentals one often finds useful.
I wanted to evaluate it but was very put off when trying to connect to my google calendar they asked for full access to my Youtube profile. I get there is some youtube integration they have but binding those things together without any mention of why was enough for me to click cancel. Sucks because I really want to ditch Zoom.
Jitsi has really been kicking it at my school lately; I wrote a chat bot for out Nextcloud that creates meetings and now up to 150 people can easily join into one conversation!
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.
I tried installing this on two different Ubuntu machines using their Ubuntu repo and it did not work. Worked fine on both Android and Ios. This is about what I expect from a java application - the java ecosystem is co convoluted and fragile that the only real options are Android, Ios, and Docker. I wish someone would write something like this in Go or Rust.
[+] [-] steveharman|6 years ago|reply
Obviously as we stopped using Zoom we have to manually upload all our personal data to Facebook now.
[+] [-] Certhas|6 years ago|reply
It's a bit ironic that somewhere, someone is switching from Firefox to Chrome because of data concerns with Zoom.
[+] [-] capableweb|6 years ago|reply
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?
[+] [-] chronicler|6 years ago|reply
[+] [-] hirako2000|6 years ago|reply
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
[+] [-] supermatt|6 years ago|reply
[+] [-] SparkyMcUnicorn|6 years ago|reply
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.
[+] [-] moron4hire|6 years ago|reply
Traffic only goes through the server for users behind NAT, triggering the TURN path.
[+] [-] moron4hire|6 years ago|reply
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.
[+] [-] zajio1am|6 years ago|reply
Considering that i can play Full-HD H.264 videos with minimal load then this seems ridiculous.
[+] [-] quadrangle|6 years ago|reply
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?
[+] [-] oever|6 years ago|reply
[+] [-] zapttt|6 years ago|reply
hint: it's not nvidia.
[+] [-] SparkyMcUnicorn|6 years ago|reply
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.
[+] [-] toohotatopic|6 years ago|reply
[+] [-] woah|6 years ago|reply
[+] [-] gidam|6 years ago|reply
[+] [-] ofrzeta|6 years ago|reply
[+] [-] j1elo|6 years ago|reply
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.
[+] [-] cf|6 years ago|reply
[+] [-] jteppinette|6 years ago|reply
[+] [-] overthelake|6 years ago|reply
One-on-one calls through Riot _are_ encrypted, but only if made in a one-on-one direct chat.
[+] [-] enriquto|6 years ago|reply
[+] [-] buovjaga|6 years ago|reply
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.
[+] [-] lioeters|6 years ago|reply
100% support for Firefox (and other non-Chrome browsers)
https://github.com/jitsi/jitsi-meet/issues/4758
[+] [-] cpncrunch|6 years ago|reply
https://github.com/meetecho/janus-gateway
[+] [-] m-p-3|6 years ago|reply
[+] [-] hirako2000|6 years ago|reply
Edit: got it, it's that particular feature still missing.
[+] [-] PudgePacket|6 years ago|reply
[+] [-] kodablah|6 years ago|reply
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...
[+] [-] dergachev|6 years ago|reply
[+] [-] AnonC|6 years ago|reply
[+] [-] lioeters|6 years ago|reply
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...
[+] [-] GuqLyr|6 years ago|reply
[+] [-] dvduval|6 years ago|reply
[+] [-] U8dcN7vx|6 years ago|reply
[+] [-] habi|6 years ago|reply
[+] [-] eagsalazar2|6 years ago|reply
[+] [-] pojntfx|6 years ago|reply
[+] [-] cryptonector|6 years ago|reply
EDIT: Thanks!
[+] [-] ianmcgowan|6 years ago|reply
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.
[+] [-] detaro|6 years ago|reply
> Selective Forwarding Units (SFU)
[+] [-] rebataur|6 years ago|reply
[+] [-] corwin7|6 years ago|reply
[+] [-] mwcampbell|6 years ago|reply
[+] [-] elagost|6 years ago|reply
[+] [-] hyperluz|6 years ago|reply