Meeting side video getting freeze in SIP client device for Jibri Sip gateway

Hi. We’ve installed Jibri sip gateway, we have followed this installer.
jitsi-videosipgw and also many points and config taken from jibri sip guide. Thanks to @emrah , @slider.xtm (y).
Our current system now almost works aside from the meeting side video is not showing perfectly in another SIP client device.

  1. Meeting audio to SIP device —> OK
  2. SIP device audio in meeting ----> OK
  3. SIP device video inside meeting tileview ------> OK
  4. meeting video to SIP device ------> video is shown for like 3-10 seconds, then it freezes or gets stuck.

A screenshot is attached, here in the device after a couple of seconds, jitsi video is getting frozen up.
Please anyone could help on this , do jibri/vm need any kind of ram/ video resolution specification or where should we check on this.

You need at least 8 cores and ~4 GB RAM on jibri for each session. Your issue looks like a resource issue.

Normally it should work without an additional modification if you install it by using jitsi-videogateway installer. One of this modification may also cause an issue.

Ok. let us check our jibri session RAM .
Please note our vm RAM size is 32GB.
yes haven’t changed too much from the installer. One change is like this:
In /etc/alternatives replaced google-chrome with replaced version.

and in /usr/bin google-chrome:

# Copyright 2011 The Chromium Authors
# Use of this source code is governed by a BSD-style license that can be
# found in the LICENSE file.

# Let the wrapped binary know that it has been run through the wrapper.
export CHROME_WRAPPER="`readlink -f "$0"`"

HERE="`dirname "$CHROME_WRAPPER"`"

# We include some xdg utilities next to the binary, and we want to prefer them
# over the system versions when we know the system versions are very old. We
# detect whether the system xdg utilities are sufficiently new to be likely to
# work for us by looking for xdg-settings. If we find it, we leave $PATH alone,
# so that the system xdg utilities (including any distro patches) will be used.
if ! command -v xdg-settings &> /dev/null; then
  # Old xdg utilities. Prepend $HERE to $PATH to use ours instead.
  export PATH="$HERE:$PATH"
  # Use system xdg utilities. But first create mimeapps.list if it doesn't
  # exist; some systems have bugs in xdg-mime that make it fail without it.
  mkdir -p "$xdg_app_dir"
  [ -f "$xdg_app_dir/mimeapps.list" ] || touch "$xdg_app_dir/mimeapps.list"

# Always use our versions of ffmpeg libs.
# This also makes RPMs find the compatibly-named library symlinks.
if [[ -n "$LD_LIBRARY_PATH" ]]; then

export CHROME_VERSION_EXTRA="stable"

# We don't want bug-buddy intercepting our crashes.

# Sanitize std{in,out,err} because they'll be shared with untrusted child
# processes (
exec < /dev/null
exec > >(exec cat)
exec 2> >(exec cat >&2)

# Note: exec -a below is a bashism.
exec -a "$0" "$HERE/chrome" "$@"

# start google-chrome
exec /etc/alternatives/google-chrome $@

@emrah , One point to note, that If we don’t replace google-chrome in etc/alternatives with replace then video not shown at all, but after replacing video is sent at least but for couple of seconds.

Where is your ffmpeg command for display :1?
And what are the arguments for this one?

In there is:
ffmpeg -f x11grab -r 30 -i :0.0 -pix_fmt yuv420p -f v4l2 /dev/video1 &
sleep 0.8

Inside google-chrome.replace there is:

# start ffmpeg cross capturing X displays to video devices
ffmpeg_run() {
  nohup ffmpeg -re -f x11grab -r 60 -s 1920x1080 -i :0 -f x11grab -r 60 -s 1280x720 -i :1 \
  -map 0 -vcodec rawvideo -pix_fmt yuv420p -threads 0 -f v4l2 /dev/video1 \
  -map 1 -vcodec rawvideo -pix_fmt yuv420p -threads 0 -f v4l2 /dev/video0 &>/dev/null &

# durty hack for no cursor on display 0/1
cursor_hide() {
  DISPLAY=:0 exec unclutter &>/dev/null &
  DISPLAY=:1 exec unclutter &>/dev/null &

In /usr/local/bin google-chrome :

# push display :1 view to virtual camera 0
ffmpeg -f x11grab -r 30 -i :1.0 -pix_fmt yuv420p -f v4l2 /dev/video0 &
sleep 0.8

I didn’t understand what you do. The command in your last post and ffmpeg_run try to write the same device. If both are active at the same time, it will fail.

And using multiple exec is meaningless because the codes after the first exec will not be run.

currently, the whole setup is after the jibri manual installation. no change is done. as for now video is showing for 30-60 seconds in device.

@emrah .
This is the vm CPU details.

Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
Address sizes: 46 bits physical, 48 bits virtual
CPU(s): 12
On-line CPU(s) list: 0-11
Thread(s) per core: 1
Core(s) per socket: 1
Socket(s): 12
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 85
Model name: Intel(R) Xeon(R) Gold 6148 CPU @ 2.40GHz
Stepping: 4

Can you monitor the resources of jibri during the SIP session? For example by using htop
Is the used RAM constantly increasing…?

ok. let me check and provide here

looks like memory not increasing that much.
Before a meeting call : 2.3 GB and during call 2.7 GB, and then suddenly video hung

Then there may be a problem with SIP session.

By the way our implementation is publicly available now. You may want to try it.

It also contains jitsi-component-selector which allows to control jibri or sip-jibri session programmatically through API.

1 Like