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.