Support for Jibri legacy config file (config.json) going away soon-ish

We’ve had support for both config.json and the new jibri.conf for a while now, and I think I’ll be looking to officially deprecate the old config file soon. This is partly motivated by a big Jibri refactoring I did recently (PR here) where I just left out support for the old config.json. This won’t happen in the next couple weeks, but I hope to get that Jibri refactor merged sometime early next year, so wanted to put out a first warning.

When that Jibri PR is merged Jibri will move to version 9, but the debian package will still be the same, so upgrading would take this new version and break deployments who were still relying on the old config file. (I can probably at least check for the program argument being passed and log a bit warning if --config was still passed in).

Any thoughts?


Thanks for this update, @bbaldino.

Should we expect some performance improvements with this refractoring? I did a quick scan through the PR and it looks like most of the improvement centers around better debugging (I could be wrong). That, of course, is much appreciated too. Just wondering if we should expect to see some efficiencies built into this PR that could reduce the resource impact of Jibri and ultimately its performance. :thinking:

1 Like

I’m pretty sure selenium + ffmpeg account for the vast majority of resource usage on Jibri; the rest of the code doesn’t really do much, so I wouldn’t expect any performance improvements from that refactor.

Gotcha! :+1:t5:

@bbaldino how to add a finalized script that was working with uploading a video to Dropbox after the recording example

jibri.conf template

1 Like

if we will add multiple hosts

xmpp-server-hosts = [ “”, “” ]

then this Jibril can be available for two different Jitsi?


No idea


cool!! thank you for this new feature, @bbaldino I am curious to know are you guys working on multi-streaming to Facebook, Youtube, Twitch, etc at once, any future planning about this? I know currently Jibri support custom RTMP server and if we want to do multistreaming then we can use the RTMP relay server but we need to manage two services. that’s why I’m asking, does this feature is available in your roadmap?

No, sorry, that’s nowhere on the roadmap.

An update on this: I’ve decided not to merge that PR. It heavily leverages kotlin’s new coroutines which simplified a lot of code, but also brings with it a lot of non-intuitive “magic” and I worry about their debuggability. My plan is to port some of the changes done as part of that PR separately (kotlin version upgrade and logger improvements). Removing support for the old config will still come, but will enjoy a stay of execution for now :slight_smile: