jellyfin-ffmpeg: the FFmpeg fork that ships with the Jellyfin media server

The readme is upstream FFmpeg's, not the fork's

The first thing to understand is that the documentation you are reading is FFmpeg's own. The readme describes FFmpeg as a collection of libraries and tools to process multimedia content such as audio, video, subtitles and related metadata, and it goes on to list the libraries: libavcodec for codec implementations, libavformat for streaming protocols, container formats and basic I/O access, libavutil for hashers, decompressors and utility functions, libavfilter for altering decoded audio and video through a directed graph of connected filters, libavdevice as an abstraction over capture and playback devices, libswresample for audio mixing and resampling, and libswscale for color conversion and scaling. The tools are the ffmpeg command line toolbox, ffplay as a minimalistic player and ffprobe as a simple analysis tool, plus smaller ones such as aviocat, ismindex and qt-faststart. None of that is specific to Jellyfin. The fork's own documentation is elsewhere, so the readme is the wrong place to look for what the fork changes, and the changes are the whole reason the fork exists.

A separate release line, on a branch named for the project

The release history is the clearest evidence that this is a maintained fork rather than a snapshot. The recent releases are v8.1.3-1 in September 2026, v8.1.2-5 in mid September and v8.1.2-4 at the start of that month, which is a patch-level stream with a distribution-style suffix, not the calendar versioning upstream FFmpeg uses. The default branch is named jellyfin rather than master, so the fork's work lives on a branch of its own and the upstream line is the base it is built from. The last push was on 2026-10-14. The practical consequence for an operator is that a Jellyfin release pins a particular fork version, and the fork version is not the same number as the upstream FFmpeg release it descends from, so you cannot read the Jellyfin package manifest and infer the FFmpeg feature set from the version string alone.

The build targets the platforms a server runs on

The repository layout is where the fork's real work is visible. There are three prepared build directories, build-linux-amd64, build-linux-arm64 and build-windows-win64, which is a clear statement about the deployment targets, since a media server runs on a home server on x86, a Raspberry Pi or another arm board, or a Windows box, and the fork ships configuration for all three. There is also an msys2 directory for the Windows build environment, a debian directory for packaging, a presets directory holding the preset files the build installs, a compat directory for platform compatibility shims, and a builder directory. The Docker story is explicit too, with a Dockerfile.in and a Dockerfile.make pair for the Linux container and a Dockerfile.win64.in and Dockerfile.win64.make pair for the Windows one, and the scripts docker-build.sh and docker-build-win64.sh to drive them. The cross compilation files are there in both forms, with cross-arm64.meson and cross-win64.meson for the meson build and toolchain-arm64.cmake and toolchain-win64.cmake for the CMake one, so both build systems are supported.

Both build systems are maintained in parallel

The presence of both configure and meson cross files tells you that the fork still supports the classic configure script and the meson build, and the top level carries a Makefile, a configure script and a build.yaml for the CI. The Makefile itself is the upstream one, and it is worth reading because it shows the test infrastructure the fork inherits. The test tools are built first, the list being audiogen, videogen, rotozoom, tiny_psnr, tiny_ssim, base64 and audiomatch, and the HOSTPROGS line adds the documentation print options program. The library list mirrors the seven libraries above, and the comment in the makefile notes that the order matters because the $(FFLIBS-yes) entries need to be in linking order. There are also fuzzer link rules for the target decoders and encoders, so the project keeps the fuzzing targets buildable, which is the part of upstream's hardening that a fork is most likely to break.

Patches come by mail, not by pull request

The contributing section is inherited from upstream and it is worth reading as a constraint rather than as advice. Patches should be submitted to the ffmpeg-devel mailing list using git format-patch or git send-email, and GitHub pull requests should be avoided because they are not part of the review process and will be ignored. That is a real difference from what most people expect of a repository with an issues tab and pull requests enabled, and it means a fork of this project inherits a workflow where a GitHub pull request goes nowhere. The repository does carry a .github directory and a .forgejo directory, and a MAINTAINERS file and a CREDITS file, so there is still a GitHub presence, but the review path for a code change is the mailing list.

Licensing, and what the fork inherits

The licence is the upstream arrangement, and the readme states it plainly: the FFmpeg codebase is mainly LGPL-licensed with optional components licensed under GPL, and the LICENSE file has the details. The repository root carries the full set of licence texts, COPYING.GPLv2, COPYING.GPLv3, COPYING.LGPLv2.1 and COPYING.LGPLv3, which is what makes the optional GPL components possible, and the LICENCE field on the repository is one GitHub cannot classify, with the terms in the LICENSE.md file. For a media server, that matters in a specific way, because the licence of the binary you ship determines what you owe anyone you distribute it to. A fork does not change the licensing position of the code it forks, so the LGPL with optional GPL components arrangement carries over exactly, and any Jellyfin-specific additions to the code would be covered by whatever terms that project applies to its own contributions.

What the fork is for, and where the documentation actually is

The practical case for a fork like this is that a media server needs transcoding behaviour the upstream project will not take, such as hardware acceleration paths, subtitle handling rules and container workarounds that the server depends on. The alternative is to run upstream FFmpeg and lose those fixes, or to patch upstream and maintain the patch set yourself. What the readme cannot tell you is which of those it is, because the readme is upstream's. The places to look instead are the release notes file in the repository, the Changelog, and the project documentation, and for a fork the useful question is always what changed relative to the upstream version it is based on. The README points to the offline documentation in the doc directory, to the online documentation on the FFmpeg website and the wiki, and to coding examples in doc/examples, and the docs directory in this repository is the upstream one, so it will describe upstream behaviour rather than the fork's.

Editorial conclusion

jellyfin-ffmpeg suits a Jellyfin operator who wants the media server and the transcoder from the same project, and who is willing to build or track a separate binary. It does not suit someone who wants upstream FFmpeg features exactly, since a fork lags and diverges, and the readme is upstream documentation, so it will not tell you what Jellyfin actually changed. Before you rely on it, read the release notes for the version you are considering, check which fork your Jellyfin package expects, and remember that the project takes patches by mail to the ffmpeg-devel list rather than by GitHub pull request.

Frequently asked questions

Official sources

1. Issues
2. jellyfin/jellyfin-ffmpeg on GitHub
3. Project website
4. README
5. Releases