On this page
Recording in Jitsi Meet looks like a single button. Behind it are four services talking to each other and a full Chrome browser running on a server with no screen. Knowing how those pieces fit together is what turns "recording failed" from a mystery into a five-minute fix, and it explains most of Jibri's odd-looking requirements.
What Jibri is
Jibri stands for Jitsi Broadcasting Infrastructure. It records meetings to files and streams them to RTMP services such as YouTube. Its source and reference configuration live in the jitsi/jibri repository. It is separate from Jitsi Meet itself: you install it on its own machine, and a Jitsi deployment can work perfectly without it.
Jibri is not the only way to record. Local recording saves a meeting from a participant's browser with no server at all. Jibri is the option for recordings that must happen on the server, for every meeting, regardless of which device the host uses.
From record button to file
- A moderator presses record. The Jitsi Meet front end sends the request to Jicofo, the conference focus.
- Jicofo finds a free Jibri. Every Jibri waits in an XMPP room called the brewery, commonly
JibriBrewery, and reports whether it is idle or busy. Jicofo picks an idle one. - Jibri joins the meeting. It logs in with a dedicated recorder account on a hidden domain, so it doesn't appear in the participant list.
- It captures and encodes the meeting while it runs, as described below.
- Recording stops when the moderator stops it or the meeting ends. Jibri finishes the file and runs its finalize script, typically to upload the file to S3 or other storage and clean up.
- Jibri reports idle in the brewery again, ready for the next job.
Every failure maps to a step. "No recorder available" is step 2: no Jibri in the brewery, usually a login or brewery JID mismatch. A recording that starts and stops after about 30 seconds is step 3 or 4: Jibri couldn't join or couldn't capture. A finished recording that never appears in your bucket is step 5, the finalize script.
How the Jitsi Jibri capture works
This is the part that surprises people. Jibri doesn't receive the media streams and mix them. It watches the meeting like a person would:
- A virtual X display runs on the server, provided by Xorg with a dummy video driver, with a lightweight window manager on top. On a package install these are the
jibri-xorgandjibri-icewmservices. - Selenium drives Google Chrome to open the meeting URL on that display, full screen.
- ffmpeg captures the display and the audio, and encodes them to H.264 video in an MP4 file, or sends them to an RTMP URL.
- Audio is captured through an ALSA loopback device, a virtual sound card: Chrome plays the meeting audio into it and ffmpeg records from the other end.
That design is why Jibri needs Chrome, a matching ChromeDriver and the snd-aloop kernel module, and why it is sensitive to certificates: Chrome refuses the meeting page the same way your browser would. The practical install steps are in setting up Jibri on Ubuntu, and the certificate side on internal networks is covered in deploying Jibri in a private LAN.
Jibri Docker deployments
The docker-jitsi-meet project ships a Jibri service, and the pipeline inside the container is exactly the one above. Two pieces stay on the host: the snd-aloop kernel module, which a container cannot load for itself, and the recordings directory, which has to exist and be writable by the container user before Jibri starts. Miss either and recordings fail at the same step a package install would fail on.
Jitsi Jibri recording quality settings
Quality is controlled in the ffmpeg section of /etc/jitsi/jibri/jibri.conf. The defaults in Jibri's reference config:
| Setting | Default | What it changes |
|---|---|---|
resolution | 1920x1080 | Capture size of the virtual display |
framerate | 30 | Frames per second captured |
video-encode-preset-recording | ultrafast | Encoder speed for files; faster uses less CPU but makes bigger files |
video-encode-preset-streaming | veryfast | Encoder speed for live streams |
h264-constant-rate-factor | 25 | Quality target; lower is better quality and bigger files |
streaming-max-bitrate | 2976k | Upper bound for RTMP streams |
The defaults favour low CPU use: ultrafast makes encoding cheap at the cost of larger files. If recordings look soft, lower the CRF a few steps before touching anything else, and watch the Jibri machine's CPU while you test. An encoder that can't keep up drops frames, which looks worse than a slightly higher CRF.
jibri {
ffmpeg {
resolution = "1920x1080"
framerate = 30
video-encode-preset-recording = "veryfast"
h264-constant-rate-factor = 22
}
}A quality limit that no setting fixes: Jibri records what its Chrome participant receives. In a large meeting, Jitsi sends each participant only a subset of video streams, so the recording shows the standard layout, not every camera at full resolution.
Live streaming
Streaming uses the same pipeline, with ffmpeg sending to an RTMP URL instead of a file. The moderator pastes a stream key from YouTube or another RTMP service into Jitsi, and Jibri pushes the encoded meeting there.
By default Jibri streams to any RTMP destination. On a shared server, restrict it with rtmp-allow-list in the streaming section, a list of regular expressions, so a moderator can't send your meetings to an arbitrary server.
Streaming needs outbound internet
One Jibri, one recording
A Jibri runs one Chrome and one ffmpeg process, so it records exactly one meeting at a time. Ten simultaneous recordings need ten Jibri instances, all connected to the same brewery room so Jicofo can hand out work.
Keeping ten recorders running all day for occasional use is expensive. The usual pattern is a small pool of idle Jibris plus automation that starts another whenever one gets busy and removes spares when several sit idle. Auto scaling Jitsi Meet on AWS covers that pattern for both videobridges and Jibri.
For a small team that records now and then, a single Jibri next to the Jitsi server is enough. For everyone else, sizing the pool is the real design decision, and the default answer is: one more idle Jibri than the number of recordings you expect to start at the same moment.
Frequently Asked Questions
What is Jibri in Jitsi Meet?
Jibri, the Jitsi Broadcasting Infrastructure, is the service that records Jitsi meetings and streams them to RTMP services such as YouTube. It joins a meeting as a hidden participant in a real Chrome browser, captures the screen and audio with ffmpeg, and saves or streams the result.
How many meetings can one Jibri record at once?
One. Each Jibri runs a single Chrome session and a single ffmpeg encode, so it handles exactly one recording or one live stream at a time. To record several meetings in parallel, run several Jibri instances connected to the same brewery room.
How do I improve Jibri recording quality?
Jibri encodes H.264 with a constant rate factor of 25 and the ultrafast preset by default. Lowering the CRF (for example to 20) raises quality and file size; a slower preset improves compression at a higher CPU cost. These live in the ffmpeg section of jibri.conf.
Does Jibri record every participant's video?
It records what its own Chrome participant sees: the normal Jitsi layout, usually the active speaker plus thumbnails. In large meetings the server only sends a subset of video streams to each participant, and Jibri is no exception.
Can Jibri run in Docker?
Yes. The docker-jitsi-meet project includes a jibri compose file, and recordings are written to a host directory that must exist and be writable before Jibri starts. The host still needs the ALSA loopback kernel module loaded.
Jitsi Meet with Jibri Recording, Pre-Configured
Jitsi Meet with Jibri, the brewery room, recorder account and ALSA loopback already set up, so recording works on the first click.
Get Jitsi Meet with Recording on AWS Marketplace
