Jellyfin transcoding explained: direct play, hardware acceleration and what to buy for your home server

If your Jellyfin server copes with one stream and chokes on two, the culprit is nearly always transcoding: the server converting video on the fly because a device cannot play the original file. Understanding it will save you money, because the right answer is often not a faster processor. This guide is based on Jellyfin's own documentation (see also Jellyfin 12 and Plex or Jellyfin).

Four ways a file can be played

Jellyfin lists them from lightest to heaviest on the server:

1. Direct play: the file is sent unchanged. Almost no load.
2. Remux: only the container changes; audio and video streams are untouched.
3. Direct stream: the audio is transcoded and the video kept.
4. Transcode: the video itself is converted. This is the expensive one.

The dashboard shows which type is in use for each stream. Check it before blaming the hardware.

Why transcoding happens

The client tells the server what it can play: codecs, resolution, bitrate and so on. If the file does not fit, the server picks the best settings it can manage. Jellyfin states that you cannot manually override the output resolution. Practically, the best fix is a client that plays your files directly, which is why the choice of player matters (our Android 2.7 article covers one of them).

HDR is the hidden cost

When an HDR film is transcoded it has to be tone-mapped to SDR, because Jellyfin does not currently support HDR-to-HDR tone mapping or passthrough of HDR metadata. Doing this in software is very slow and some modern consumer processors cannot keep up in real time. Jellyfin recommends using a GPU, and says a basic Intel integrated GPU can handle the job about as well as a Ryzen 5800X.

Hardware acceleration: what works where

Jellyfin uses its own build of FFmpeg, "jellyfin-ffmpeg", which ships with the official Debian package, the Docker images and the Windows installers. FFmpeg builds from other sources cause partial acceleration, which raises CPU use and slows transcoding. Hardware tone mapping of HDR10 and HLG to SDR is supported, and Dolby Vision profiles 5 and 8 need Jellyfin 10.8 or later (Rockchip needs 10.11 or later).

Tips that make a difference

• Use dual-channel memory with integrated GPUs, which share system memory; it roughly doubles the bandwidth and helps with tone mapping.
• Put the transcode cache on an SSD or RAM disk if disk speed is the bottleneck.
• Leave the thread count alone unless the server is dedicated to Jellyfin.
• 10-bit H.264 is a trap: no Intel, NVIDIA or AMD GPU decodes it in hardware (only Apple Silicon and Rockchip do), so it falls back to software. Jellyfin suggests converting such files to 10-bit HEVC.
• No GPU in the server? The rffmpeg tool can hand transcoding to another machine, but it is Linux-only and needs SSH and shared storage.

What about a Raspberry Pi?

Not a good choice for transcoding. Jellyfin notes that the Raspberry Pi 5 has no hardware encoders, and that support for the Pi's older V4L2 route is deprecated: it may still work, but updates could break it and issues may go unfixed. A Pi is fine as a direct-play server for devices that need no conversion; for anything more, a small PC with a recent Intel integrated GPU is the usual sweet spot. If your NAS has a weak CPU, the same logic applies.

A quick checklist

1. Open the dashboard during playback and see which streams transcode.
2. Switch the offending clients to a player that supports your formats.
3. If you must transcode, enable hardware acceleration with a supported GPU and the official FFmpeg build.
4. Re-encode awkward files (10-bit H.264) once, rather than on every viewing.

Source: Jellyfin documentation on transcoding and hardware acceleration. Check the vendor pages for your GPU generation before buying hardware.