Is the architecture of the the WebRTC-based solution explained somewhere? In particular, I'm seeking an overview of when it's p2p (how does it scale to large meetings), when it uses a central server, when call quality can degrade (eg: will one low-bandwidth user or an overloaded server wreck the call for everyone), and which links are encrypted. I'd like a reasonable understanding of these aspects before I recommend Jitsi to less tech-savvy friends and family.
Improving Scale and Media Quality with Cascading SFUs
https://webrtchacks.com/sfu-cascading/ (November 2018)
Edit: Based on another Jitsi dev's comment in this thread: SFU stands for "Selective Forwarding Unit", which was extracted to a standalone project, Jisti Videobridge.
https://github.com/jitsi/jitsi-meet/blob/master/doc/api.md
I've done this and created a UI for adding rooms, which is in my control.
At one point in time it gained the hability to do multi-party video conferencing, where one participant would become the "focus" and forward everyone's video to everyone else.
This was the inception of the concept of an SFU or Selective Forwarding Unit.
Then, in order to scale this up the SFU was extrated to a standalone project: Jitsi Videobridge.
Roughly around then, WebRTC became a thing and Jitsi was already doing many of the required things to bring the experience to the web, so work continued with Jitsi Meet, a WebRTC compatible video conferencing system.
Jitsi Meet is our present and future, but Jitsi (desktop) lives on both as pieces of the puzzle (Jitsi Videobriidge, Jigasi and Jicofo use parts of it) and as a community project, where people interested in keeping it alive ssubmit fixes / improvements.
Source: I've developed OSGi applications professionally for nearly 9 years.
btw I <3 Jitsi Meet
"Jitsi Desktop is a xmpp, sip desktop client which has audio video capabilities, but cannot interconnect with jitsi-meet."
[1] - https://community.jitsi.org/t/jitsi-desktop-for-use-with-jit...
My use case is elderly in-laws who can use a laptop, but are incapable of installing anything other than malware. Installing Zoom would be too complicated for them and would probably discourage them from participating in a family video chat.
With Jitsi, I send them a link by email and text them to check their email. They click on the link, browser opens and voila! - they're able to chat with their family, with zero fuss.
Costs me €2.49 per month for a Hetzner cloud instance.
Just a modern browser on a device with a camera and microphone. This is how this type of software should work.
It passed the grandma test.
Quality was acceptable with 4 family members participating from 2 countries, including elderly folks on French rural ADSL.
https://github.com/jitsi/docker-jitsi-meet
Put nginx in front of it with Let's Encrypt and it shouldn't take more than half an hour to set up. After that you basically get a clone of meet.jit.si.
I'm using it with the low level JS library in order to build a product that contains video chat. There was a bit more messing about for me, but only a bit.
Installation on Ubuntu is a breeze using an install script. It's important to complete the installation with some letsencrypt SSL certs and then you're good to go.
I created a subdomain (new A record pointing at ip address of my Jitsi server) on my business domain to make it easy for family members to go to the server themselves and create their own meeting rooms.
I saw many tweets about it today...
Edit: Seems like Jitsi Meet is the current contender.
Jitsi Meet uses a "SFU" which means the A/V stream of each participant is sent to all the others. That basically does not scale in terms of network bandwidth.
Zoom seems to use a central server that kind of "mix" streams and send them to all participants. Or something hybrid.
Jitsi could be able to connect to an "MCU" like OpenMCU for this kind of architecture, but I have no clue if it is easy or not to deploy.
I am working in a full-remote company with ~15 people. Jitsi is ok for meetings with 2-4 people. With more people, it just does not work reliably. Zoom does.
Jitsi Videobridge does this by receiving simulcast streams from each participant. This server individually picks out streams and qualities that will fit in each recipient's downstream pipe based on measured bandwidth and configured priorities (e.g. you could choose to give more bandwidth to those who are actively speaking, or shut down all but the last N speakers video streams).
Yes, the available network bandwith on a Jitsi Videobridge could be a bottleneck. Each meeting need to fit on a single bridge instance. However, using common servers connected at 1 Gbps or 10 Gbps, it shouldn't be any problem to have meetings with substantially more than 2-4 people. Say a HD stream from most webcameras outputs 3 Mbps at full blast, with 50% overhead due to the simulcasting. That's over 2000 participants on a single server connected at 10 Gbps, all receiving all video streams in full quality.
For meetings with 2 participants the streams run peer to peer, so here you get the best possible latency and quality.
We've set up Jitsi on a VPS instance at a nearby provider, and have not seen any problems with meetings of 10-15 people. Stability and performance also outperforms all the other solutions I've tried. There's currently a bug in Firefox's simulcast implementation, so if you have any participant using this browser, this feature gets disabled for everyone. Even with this issue, I haven't noticed anything but excellent performance with this few number of participants.
The following article might also be interesting.
Half-OT, but couldn't this be solved somehow by relaying?
1. how to share screen?
2. How to schedule meet for future?
Maybe I am dumb. I will meanwhile stick to Zoom.
Some people even like the fact, that they have their scheduling info in the same place!
Isn't the technology wonderful? /s
My colleagues loved the Youtube playback ability (I put on some elevator muzak waiting for the rest to join), although I had to do a bit of hunting to get rid of the video again. :)
Doesn't this make jitsi meet _effectively_ chrome only until they better support firefox/safari/etc[2].
[1]: I get "It looks like you're using a browser we don't fully support....We recommend to try with the latest version of Chrome or Chromium" when trying to use it.
[2]: Sounds like webrtc isn't well supported and fairly buggy for some browsers, apparently?
Jitsi is open source, has an option for me to host my own server (avid self-hoster for privacy), and appears to work on just about any platform. So I should be able to get most of the family to adopt it.
So now I suppose my question is how do I get Jitsi running on my TV? Or can someone offer some other solution that might fit my use case? I really would like to be able to just go to my TV, turn it on, and have instant ability to video chat from my living room to family members on nearly any device.
My first thought was to get it running on an Raspberry Pi but it seems that’s not really something that works from all of my searching. Does anyone have any experience there?
If that’s the case is there a cheap Android device that could achieve this with some sort of decent camera? Or am I stuck running an x86 system attached to my TV?
Does anyone else have Jitsi setup in a conference room like setting with a TV?
I'm curious why you're opposed to this.
Screen grabbed from their excellent tutorial videos: https://jitsi.org/news/tag/tutorial/
One thing we’ve found in deploying Jitsi several times is that good performance is difficult to achieve across parties who are across the globe.
We have some of our team in Armenia, Belarus and London and not all of then get consistent performance.
I know you can do geographic sharding so all EU or US guests get connected to their closest server but is there a way to ensure cross country participants all get good performance?
- have the SFU (videobridge) in a more "central" location
- have multiple videobridge installations (cascaded bridges) where required with a low latency interconnect (its effectively a smart relay).
- you could use geographically distributed forced TURN servers with low latency interconnect to the SFU, but it would be more bandwidth intensive, and not really useful unless you truly have a REALLY low latency interconnect.
----------
Reducing the quality of the streams may also help, if it is bandwidth that is the constraining factor.
https://www.8x8.com/products/video-conferencing
It looks pretty similar from the description and screenshots. But with more of an enterprisey-focus and integration with their existing software.
Great content, too.
