First of all congratulation to the contributor for an amazing job, I’m really enjoying working with Jitsi/Jibri and a big thanks to the very active community for all the help.
I’ve got a question about Jibri and i couldn’t find anything related.
In a classic setup with 1 Jitsi meet server build to handle let’s say 5 concurrent conferences + 5 Jibri instances installed on 5 different VM to stream the potential 5 conferences.
Is there a way to know before the conference starts which Jibri instance will be chosen, and is there a way to make JMS choose one specific instance ?
Use case : conferences are planned in advance, we know when it is going to happen and the amount of participants (which can go from 2 to 10 depending on the conference). If we can somehow point JMS toward the right Jibri instance to use, we would be able to lower configuration on a few Jibri instances (no need of 8 core cpu for a 2 participants meeting).
Hope I made myself clear enough.
Are you sure the Jibri server size is related to the number of people in the call, it’s just recording the call in a headless browser. There could be a bit higher load in the client, but I don’t think this should be noticeable?
There’s currently no way to “know” the order in which Jibris will be selected so there’s not much you could do there without changes to the code Jicofo uses for selection. But like @yasen said, I’m not sure it’s worth worrying about the different instance sizes. Have you run into issues with that before?
Hi Guys, thanks for your answers.
I’ve run tests on a 2vcpu with 2 and 10 participants and I end up with a 55/60% cpu usage with 2 participants and a little above 80% with 10 participants.
Each added participant add a little cpu usage to the chrome process. 55/60% seemed to me acceptable but 80% seems a little risky…
Anyway, since there is no way to make sure which jibri will be selected, I think also that makes it too complicated for too little gain.
Thanks again guys for taking the time !
The more objects you have in the frame, the more complex the movements of the objects, the more work ffmpeg has to do to capture video. So yes, your observation makes sense. BUT generally, 2vCPUs is not advisable for Jibri at all - not for 2 participants or 200 participants. Even with 2 participants, if there are a lot of colors and there’s a lot of movement, or even if it’s just 2 cameras but several people showing on each camera, ffmpeg will need to do more work. To be safe, stick with 4vCPUs and 8GB RAM.