Jellyfin on a Raspberry Pi 4 8GB: What It Can and Can't Transcode

Jellyfin on a Raspberry Pi 4 8GB: What It Can and Can't Transcode

Yes, a Raspberry Pi 4 Model B 8GB runs Jellyfin well as of 2026, but only inside a narrow lane. It direct-plays 1080p H.264 to one or two clients without breaking a sweat, and per the Jellyfin hardware acceleration docs its VideoCore VI GPU offers H.264 decode with no encode path. Ask it to software-transcode HEVC or 4K and it falls over. Match your library to the hardware and it is one of the best per-watt media servers you can build.

Step 0: diagnose your library before buying anything

The mistake almost every first-time Pi media-server builder makes is buying the parts before auditing what actually needs to play. Before you order a single component, spend an hour listing the following:

• Codec audit. Walk the largest ten directories in your library and count HEVC (H.265) files, AV1 files, and remaining H.264. If HEVC represents more than a small minority, the Pi 4 is already the wrong tool. HEVC has no hardware acceleration on the Pi 4 per Raspberry Pi's Pi 4 specification sheet, and its four Cortex-A72 cores cannot software-transcode 1080p HEVC to H.264 in real time.
• Client list. LG WebOS, modern Roku, Apple TV 4K, and current Android TV boxes direct-play the widest range of containers and codecs. Older Chromecasts, first-gen Fire TV sticks, and web browsers on Safari force more transcoding. If your household lives on the second list, plan around transcoding pain.
• Remote-vs-LAN split. Local gigabit clients rarely need bitrate adaptation. Anyone streaming over a saturated cellular link forces the server to cut bitrate, which is a transcoding operation. If half your usage is remote, you probably want a mini-PC.

Getting this right up front is the single largest determinant of whether a Pi build will feel great or feel painful six months in.

Who a Pi media server is actually for

The honest answer is that a Pi 4 media server suits the household that controls its own library and is willing to trade a little flexibility for a lot of efficiency. If you rip your own discs or curate your own downloads, you already choose the container and the codec, and choosing well means the Pi never has to touch the bitstream. Direct play is the design goal, not a bonus. When it works, a Pi 4 pulls under ten watts at the wall while serving several concurrent streams, and it sits silently on a shelf for years without maintenance.

The wrong audience is the person who wants Plex-style universal compatibility with any legacy client. Public benchmarks reported by community members on the r/jellyfin and r/selfhosted forums consistently show a single 1080p software transcode saturating three of four Cortex-A72 cores at 1.5 GHz. That leaves no headroom for a second concurrent transcode, for artwork refresh, or for the small housekeeping tasks Jellyfin runs in the background. If your library forces even one client into transcoding, the illusion breaks.

The other wrong audience is anyone who plans to run heavy adjacent workloads. Jellyfin itself is lightweight, but the "arr" stack (Sonarr, Radarr, Bazarr), a torrent client, Home Assistant, and a Postgres database all on one Pi will contend for RAM and I/O in ways that make everything worse. The Pi 4 8GB earns its extra cost only when it hosts several small services that never spike simultaneously.

Key takeaways

• The Pi 4 8GB is a legitimate Jellyfin host for H.264 direct-play libraries as of 2026, but not a transcoding workhorse.
• Its VideoCore VI GPU decodes H.264 in hardware and does not encode any codec, so every transcode is CPU-bound.
• HEVC (H.265), AV1, and 4K video have no hardware path on this board; treat them as unsupported for transcoding.
• Storage should be a SATA SSD over USB 3.0, not microSD, to protect card life and speed library operations.
• Airflow is mandatory. Public benchmarks consistently show a bare Pi 4 throttling under sustained load within minutes.
• If your household needs universal transcoding, buy a mini-PC. The Pi is not the right shape of tool.

What you will need

A working Pi 4 Jellyfin build is a small kit. Buy once, do not skimp on cooling or storage.

• Board. The Raspberry Pi 4 Model B 8GB is the only Pi 4 variant worth choosing for a media server if you intend to also run adjacent services. If Jellyfin is genuinely the only load, a 4GB board is fine, but the price gap is small.
• Storage. A 1 TB Crucial BX500 1TB SATA SSD plus a USB 3.0 adapter is the standard build. It survives Jellyfin's small-random-write pattern, and it scans large libraries several times faster than a microSD card.
• SATA-to-USB adapter. The Unitek SATA/IDE to USB 3.0 Adapter is a reliable, well-supported choice that also handles legacy IDE drives if you are pulling media off an older archive. Any UASP-capable USB 3.0 SATA bridge works; avoid unbranded USB 2.0 dongles.
• Cooling. The AC Infinity AIRCOM S7 is overkill for a bare Pi but perfect if the board lives in an AV cabinet next to other warm gear. For a naked Pi on a shelf, a case with a 30 mm fan and a heatsink block is enough; the important thing is that airflow exists.
• Network. Gigabit Ethernet, wired. The Pi 4 has a real gigabit MAC on a dedicated bus, and Wi-Fi will bottleneck direct-play of high-bitrate remuxes.
• Power. The official 5.1 V, 3 A USB-C power supply. Under-spec supplies cause undervoltage warnings that manifest as random performance issues nobody thinks to attribute to the wall wart.

You do not need a Pi Zero W for this build. The Raspberry Pi Zero W Basic Starter Kit is a useful sidecar for a remote sensor, a bedside player, or a network probe, but it is not a Jellyfin server. Its single-core ARM11 has none of the media capability the Pi 4 offers, and mentioning it here is only to steer you away from confusion when the two boards appear on the same wish list.

Which codecs the Pi 4 handles in hardware

The Pi 4's VideoCore VI block has a specific set of capabilities, and Jellyfin can only use what the block exposes. Per the Jellyfin hardware acceleration docs and Raspberry Pi's Pi 4 specification sheet, the practical capability map looks like this.

The pattern to remember: H.264 decode is the only hardware acceleration you get. Every encode is software. Every non-H.264 decode is software. That single sentence explains almost every performance surprise Pi 4 Jellyfin operators run into.

Transcode capability table

The following table maps common source-to-target conversions to observed CPU load and whether the conversion is viable as a sustained real-time operation on a well-cooled Pi 4 8GB. Numbers reflect community measurements reported on the r/jellyfin and r/selfhosted forums and general trends visible on Phoronix for Cortex-A72 media workloads.

Read the "Viable?" column as the operative summary. If the row says no, do not build a library that relies on that conversion.

Why direct play beats every transcoding optimisation

The single most effective performance improvement you can make on a Pi Jellyfin server is one you make in your library, not on the server. Ensure every file is a codec your clients natively play, in a container they accept, and Jellyfin will pass the bytes through untouched.

Direct play uses roughly the CPU cost of a file server, which is small. Direct stream (repackaging container without touching codecs) costs slightly more but still uses hardware decode. Only full transcoding invokes software encode, and software encode is where the Pi 4 hits its wall. Every hour spent normalising a library to H.264 + AAC + MP4 or MKV pays back many times over in server headroom.

Practical implication: if you rip discs, target 1080p H.264 High Profile at a sensible bitrate (8-12 Mbps for most content). If you download, prefer 1080p H.264 groups over the trendy HEVC releases. If you must keep HEVC for storage efficiency, know that every player in the house has to handle it natively or you will be transcoding on a machine that cannot.

Measured expectations

Three concrete numbers give you the shape of what to expect. Community measurements report a Pi 4 8GB at 1.8 GHz overclock, with 5 V/3 A power and passive-plus-fan cooling, behaves roughly as follows on Jellyfin 10.10:

• 1080p H.264 direct play, single client: 5-10% CPU, 6-8 W at the wall, indistinguishable from an idle server.
• 4K HEVC remux, single client, HEVC-capable TV: 8-15% CPU, 7-9 W at the wall, network becomes the constraint.
• 1080p H.264 software transcode to 720p, single client: 75-95% CPU on three of four cores, 12-14 W at the wall, fan audible.

Trends observed on Phoronix for the Cortex-A72 core family across other workloads are consistent with the pattern: this CPU is not a video encoder. Push it into software encoding of anything above SD and it either barely keeps up or falls behind.

Spec-delta table: Pi 4 8GB vs Pi Zero W vs a low-power mini-PC

The mini-PC column is why the honest recommendation for a mixed-codec household is to skip the Pi. The N100 class of machines emerged in 2024-2025 and by 2026 dominates the "small always-on server" bracket because they hardware-accelerate everything the Pi cannot.

Storage layout: SATA SSD over USB 3.0 beats microSD

microSD cards do two things badly for a media server. First, they fail. Jellyfin writes metadata, thumbnails, watch state, and logs continually, and the write-amplification factor on a small card wears it out faster than most people expect. Second, they are slow at the pattern Jellyfin actually generates: many small random reads across an artwork cache and metadata database.

A SATA SSD behind a USB 3.0 UASP bridge fixes both problems at low cost. The Crucial BX500 1TB SATA SSD is a reasonable value pick; a UASP-capable Unitek SATA/IDE to USB 3.0 Adapter exposes it at real SATA speeds. Boot from the SSD too if you can (modern Pi 4 firmware supports USB boot cleanly). Keep the microSD only as an emergency recovery drive.

Library files can sit on the same SSD if the library is small, or on a spinning disk in a USB 3.0 enclosure for larger collections. Do not run the media library on microSD; you will regret it.

Thermals and throttling: airflow is not optional

A bare Pi 4 under sustained load thermal-throttles within minutes. It does not turn off; it silently drops clock speed, and the user-visible symptom is stuttering, longer library scans, and mysterious transcode slowdowns. Anyone who has spent a weekend chasing a "Jellyfin bug" that turned out to be a hot SoC will tell you the same thing: cool the board first.

The cheapest fix is a case with a small fan and a heatsink pad on the SoC. A step up is the AC Infinity AIRCOM S7 if the Pi sits in a warm AV cabinet. Any configuration that keeps the SoC below 70 C under sustained load is fine. Monitor with vcgencmd measure_temp and set an alert if you like to be told.

Undervoltage is the sibling problem. A cheap USB-C brick that sags under load triggers the Pi's undervoltage flag, which also cuts performance. Use the official 5.1 V/3 A supply, or a known-good third-party equivalent, and check the kernel log for undervoltage warnings after your first heavy transcode.

Perf-per-watt math against an always-on desktop

A Pi 4 media server pulls roughly 3 W idle and 10-12 W under load. Over a year of 24/7 operation at a mixed 5 W average, that is about 44 kWh. At typical US residential electricity rates in 2026, that is somewhere in the neighborhood of 6-8 dollars per year.

A repurposed desktop PC as a Jellyfin host easily draws 40-60 W idle. Over the same year, that is 350-525 kWh, or roughly 50-80 dollars in electricity. Even a small N100 mini-PC averaging 10-12 W is only slightly worse than the Pi and dramatically better than a full desktop.

The perf-per-watt argument for the Pi is real, but only if it can actually do the job. A Pi that transcodes badly and gets bypassed by frustrated users is 0 W per useful stream, which is not the win it appears to be.

Common pitfalls

Five recurring failure modes account for most of the "Jellyfin on Pi is broken" complaints on r/jellyfin:

1. Assuming HEVC will transcode. It will not. There is no hardware path and software encode of 1080p HEVC does not run in real time on four A72 cores. Convert HEVC media to H.264 offline, or accept direct-play-only.
2. Running on microSD without a plan. The card wears out, library scans crawl, and one day the system will not boot. A 1 TB SATA SSD costs little; use it from day one.
3. Ignoring thermals. A bare Pi 4 throttles under sustained load. Public benchmarks routinely show SoC temperatures crossing 80 C within ten minutes of a software transcode. Add a fan or a heatsink case.
4. Cheap USB power supplies. Undervoltage flags cause performance loss that is invisible in Jellyfin's own logs. Use the official supply.
5. Forgetting the encoder gap. The Pi 4's VideoCore VI has H.264 decode but no encode. Anything Jellyfin has to convert to send to a client is a pure software operation, and this is the ceiling.

When NOT to use a Pi for Jellyfin

There are five clear situations where the Pi 4 is the wrong tool and a small x86 mini-PC is the right one. Do not force it in these cases.

• Multi-user 4K. Two or more concurrent 4K streams, any codec, imply eventual transcoding for at least one client. The Pi cannot service that load.
• HDR tone-mapping. Every current HDR-to-SDR tone-map path Jellyfin supports needs GPU acceleration the Pi 4 lacks. Software tone-mapping is not realistic on Cortex-A72.
• Predominantly HEVC library. If more than a fraction of your files are HEVC and any of your clients do not natively play HEVC, you are one bad client away from a transcoding failure.
• Remote streaming to bandwidth-constrained clients. Remote clients on cellular or slow home connections routinely force bitrate downconversion, which is a transcoding operation.
• Live TV with real-time recording and transcoding. DVR workloads add write-amplification and encode load simultaneously, which no Pi 4 configuration handles gracefully.

In every one of these scenarios, a small N100 or similar x86 board with modern integrated graphics is the honest recommendation. Buy the Pi when transcoding is optional; buy the mini-PC when it is not.

Worked scenarios

Single-user 1080p direct-play. You rip your Blu-rays to H.264 MP4 at 10 Mbps. You watch on an LG WebOS TV over gigabit Ethernet. This is the ideal Pi 4 scenario: passthrough only, under 10 W at the wall, silent in a corner. Build it and forget about it.

Family of four, 720p transcode. Two of the four clients are older tablets that force 720p H.264 conversion, and the family often watches two streams at once. This is the failure mode. One software transcode saturates the Pi; two overwhelm it. Either upgrade the tablets, normalise the library so direct play works everywhere, or swap the Pi for a mini-PC. Do not add users to a Pi build that already transcodes one stream reluctantly.

4K H.264 direct-play only. You have a 4K H.264 (not HEVC) library and only 4K-capable direct-play clients. The Pi 4 passes the bytes through as a file server; the network is the constraint, not the CPU. Perfectly viable, but note that 4K H.264 files are large and gigabit is the practical minimum.

Verdict matrix

• Build the Pi server if: your library is mostly 1080p H.264, your clients all support the codecs you feed them, you value low idle power more than transcoding flexibility, and you enjoy the tinkering.
• Buy a mini-PC if: your library includes HEVC or 4K that some clients cannot play natively, you have multiple concurrent users, or you need HDR tone-mapping or DVR.
• Stay on the desktop if: the machine is already on 24/7 for other reasons, you cannot commit to a normalised library, and the electricity cost does not bother you.

Bottom line

A Pi 4 8GB with a SATA SSD, real airflow, and a normalised H.264 library is one of the most satisfying small servers you can build in 2026. It sips power, stays quiet, and does exactly what it should for a single-household media library under your control. Try to make it a universal transcoder and it will disappoint. The rule is simple: match the workload to the hardware, and this little board earns its shelf space for years.

Citations and sources

• Raspberry Pi 4 Model B specifications
• Jellyfin hardware acceleration documentation
• Phoronix

This piece is editorial synthesis based on publicly available information. No independent first-party benchmarking is reported.