4 ms·
Also easy to skin and deploy - we setup a custom branded instance for our customers to use during the pandemic within a couple of days: https://meet.brring.com/
by leonroy 7y ago
Also easy to skin and deploy - we setup a custom branded instance for our customers to use during the pandemic within a couple of days:
https://meet.brring.com/ https://meet.brring.com/
It’s rather incredible what it can do:
* SIP gateway to support inbound telephony dial in
* Meeting recording
* Auto scaling of the video bridges to dynamically handle load
* Native iOS, Android and even Apple Watch clients
All free, all open source. The install videos are also really good indeed:
https://jitsi.org/news/tag/tutorial/ https://jitsi.org/news/tag/tutorial/
- jdiez17 7y agoI also deployed a Jitsi instance and was surprised how easy it was. I have two questions for you: 1. Do you see high CPU usage when there are multiple conferences with a few participants happening simultaneously? 2. How did you set up conference recording? I know Jibri exists but the installation instructions are quite confusing. It seems you need a VM per conference you want to record. Is that the case?
- leonroy 7y ago1. Yes, it has pretty high CPU usage unfortunately and that’s despite the attempts of Jitsi to offload h264 encoding onto the clients. You could in theory lock it to standard definition video though which would reduce CPU usage a lot. 2. We did not on this instance but we did using their Docker instance which was very straightforward to setup: https://github.com/jitsi/docker-jitsi-meet#jitsi-broadcasting-infrastructure-configuration https://github.com/jitsi/docker-jitsi-meet#jitsi-broadcastin... I don’t believe it needs a VM per conference - maybe a ffmpeg process per instance? Here's the Jitsi architecture which best I can tell shows JIBRI (recording part) as a separate, single container: https://i.imgur.com/oDSRzF4.png https://i.imgur.com/oDSRzF4.png