I am working on configuring Jibri on K8s. I have a quick question related to selection of loopback devices (aloop). When I configure my k8s to have, let say 5 replicas, how to let my containers know about which loopback device to use. for e.g.) pod1 - loopback_0 and loopback_1, pod2 - loopback_1 and loopback_2.
I am looking for a way where in case, I need to scale-up or scale-down my replicas, they should be able to determine which loopback device to use (while doing so). Any idea how can I achieve it?
If you use The Jibri images >= 7439 that is no longer necessary because we switched to PulseAudio which allows us to do the loopback inside the container.
Great to know that. Thanks Saghul. In that case, is there any limitation on how many recordings can be active on a server (at a time) with the latest Jibri (>=7439) using PulseAudio?
Anything here ^^^^ @saghul ?
It depends on the number of CPUs, resolution, framerate, etc.
The is no explicit limitation other than your own hardware.
Make sense. Thank you both for the response.
Is there any fundamental/known stat that could be used to determine estimated
no. of docker containers to run on
a server with xyz resource?
1 more thing, I just tried upgrading to latest jibri stable-7439-2 version and seeing below error in logs:
E: [pulseaudio] core-util.c: Failed to connect to system bus: Failed to connect to socket /run/dbus/system_bus_socket: No such file or directory
E: [pulseaudio] module-rescue-streams.c: module-rescue-stream is obsolete and should no longer be loaded. Please remove it from your configuration.
Are we suppose to do anything as pre-requisites for upgrading to this version?
You should be able to ignore those, they should be harmless.
I removed the module in the last error.
Any idea or numbers that can be helpful to determine total replicas/docker instances to run on a node?
I mostly reserve 4 cores for each 1024p recording.
Wow. Isn’t that too much @emrah ?
One 1024p recording reserving 4 cores
That means let say, if need 15 recordings at a time, I would need to reserve 60 cores? :o
The way I see it, if you consider that what Jibri does is – launches Chrome in a GUI, joins a meeting which involves decoding lots of video/audio streams, records everything and encodes in to a file using ffmpeg all at the same time – then 4 cores doesn’t seem that surprising.
If you are on the cloud, you may use an auto-scaling system