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.
Meeting audio to SIP device —> OK
SIP device audio in meeting ----> OK
SIP device video inside meeting tileview ------> OK
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:
#!/bin/bash
#
# 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"
else
# 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.
xdg_app_dir="${XDG_DATA_HOME:-$HOME/.local/share/applications}"
mkdir -p "$xdg_app_dir"
[ -f "$xdg_app_dir/mimeapps.list" ] || touch "$xdg_app_dir/mimeapps.list"
fi
# Always use our versions of ffmpeg libs.
# This also makes RPMs find the compatibly-named library symlinks.
if [[ -n "$LD_LIBRARY_PATH" ]]; then
LD_LIBRARY_PATH="$HERE:$HERE/lib:$LD_LIBRARY_PATH"
else
LD_LIBRARY_PATH="$HERE:$HERE/lib"
fi
export LD_LIBRARY_PATH
export CHROME_VERSION_EXTRA="stable"
# We don't want bug-buddy intercepting our crashes. http://crbug.com/24120
export GNOME_DISABLE_CRASH_DIALOG=SET_BY_GOOGLE_CHROME
# Sanitize std{in,out,err} because they'll be shared with untrusted child
# processes (http://crbug.com/376567).
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.
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.
