3 ms·

> Jibri is essentially a Chromium which views the Jitsi webapp, running in a headless X server whose framebuffer and ALSA audio is hooked up to an ffmpeg proces

> Jibri is essentially a Chromium which views the Jitsi webapp, running in a headless X server whose framebuffer and ALSA audio is hooked up to an ffmpeg process which livestreams to the appropriate destination So if I’m understanding this right, you have “private video conference -> web browser -> desktop capture -> ffmpeg -> public video stream"… why not “private conference -> ffmpeg -> public stream”? Having a web browser in the middle of your livestream setup feels very weird :P

Arathorn 6y ago
The reason is that the Jitsi Meet conferencing UI exists only as a webapp. In other words, you have to render the "private conference" somehow - which means compositing together the various WebRTC streams, switching to the active talker, highlighting them, showing their names etc, rendering screenshares etc. Jitsi is an SFU (Stream Forwarding Unit), which means that the compositing is done clientside in the webapp with a bunch of HTML+JS+CSS and WebRTC video streams - so if you want to livestream a conference, you need to have a client somewhere to do that rendering. Which means needing headless chromium + ffmpeg to capture it. The alternative would be to use a system where the conference is rendered serverside in the first place - a so called MCU (Multipoint Conferencing Unit) like FreeSWITCH. But this has a different set of tradeoffs, and having integrated both with Matrix we currently default to Jitsi. Totally agreed that it feels unintuitive to spin up a farm of 50 headless chromiums in order to livestream a conference though!
kabes 6y ago
It's not uncommon to do some webrtc video compositing (MCU) in a headless chrome, since it's usually the easiest solution and you can add some decorations with html on top. But it's definitely not very efficient. Especially since this is mostly ran on linux and chrome has almost no hardware video decode/encode capabilities on linux (starting to change).

Arathorn 6y ago

The reason is that the Jitsi Meet conferencing UI exists only as a webapp. In other words, you have to render the "private conference" somehow - which means compositing together the various WebRTC streams, switching to the active talker, highlighting them, showing their names etc, rendering screenshares etc. Jitsi is an SFU (Stream Forwarding Unit), which means that the compositing is done clientside in the webapp with a bunch of HTML+JS+CSS and WebRTC video streams - so if you want to livestream a conference, you need to have a client somewhere to do that rendering. Which means needing headless chromium + ffmpeg to capture it. The alternative would be to use a system where the conference is rendered serverside in the first place - a so called MCU (Multipoint Conferencing Unit) like FreeSWITCH. But this has a different set of tradeoffs, and having integrated both with Matrix we currently default to Jitsi. Totally agreed that it feels unintuitive to spin up a farm of 50 headless chromiums in order to livestream a conference though!

kabes 6y ago

It's not uncommon to do some webrtc video compositing (MCU) in a headless chrome, since it's usually the easiest solution and you can add some decorations with html on top. But it's definitely not very efficient. Especially since this is mostly ran on linux and chrome has almost no hardware video decode/encode capabilities on linux (starting to change).