Given a complex environment where Jellyfin is to be installed alongside other servers, and in particular, PVRs, then it becomes necessary to ensure that rffmpeg
remains exclusively available to Jellyfin instead of replacing the default ffmpeg
or ffprobe
. Furthermore, due to various security models, rffmpeg
must be present along with the symlinks ffmpeg
and ffprobe
within an executable path. However, querying the PATH
variable places, as one would expect, local binaries before system-wide binaries, such that if one were to create the symlinks as per the official instructions, the ffmpeg
and ffprobe
symlinks corresponding to rffmpeg
will be available before the system ffmpeg
and ffprobe
binaries.
In order to work around the issue, the rffmpeg
binary can be copied separately to ffmpeg
and ffprobe
, instead of creating symlinks:
cp rffmpeg ffmpeg cp rffmpeg ffprobe
Then, the binary copies ffmpeg
and ffprobe
will have to be edited in order to knock out the checks that verify whether rffmpeg
is the command name and to run directly either ffmpeg
or ffprobe
. This can be accomplished using the following patch:
--- ffmpeg 2023-10-08 14:24:44.058993570 +0000 +++ ffmpeg 2023-10-08 19:25:43.934045248 +0000 @@ -1012,9 +1012,5 @@ # Load the config config = load_config() - if "rffmpeg" in cmd_name: - run_control(config) - - else: - ffmpeg_args = all_args[1:] - run_ffmpeg(config, ffmpeg_args) + ffmpeg_args = all_args[1:] + run_ffmpeg(config, ffmpeg_args)
and applying it to both ffmpeg
and ffprobe
binary.
With this accomplished, Jellyfin can be convinced to accept a path such as /opt/rffmpeg/ffmpeg
where the suffix ffmpeg
is in fact a patched copy of the rffmpeg
script, as a valid path to access the ffmpeg
binary.
In doing this, other PVRs and system tools will not end up confused due to ffmpeg
and ffprobe
corresponding to rffmpeg
which is really designed to be used only in conjunction with Jellyfin.