Short answer
Yes — a Raspberry Pi 4 Model B 8GB makes a perfectly good Jellyfin server in 2026 if you build the library around direct play and run media off a USB 3.0 SSD. It handles multiple simultaneous 1080p direct-play streams with no sweat, one light 1080p transcode at a time, and falls over on heavy 4K HEVC transcodes. Pair the Pi with a WD Blue SN550 NVMe in a USB 3.0 enclosure for the OS and Jellyfin database, plus a Samsung 870 EVO or Crucial BX500 for bulk media storage. For real 4K transcoding workloads, step up to a mini-PC.
Why self-host media on a Pi at all?
People keep building Jellyfin on Raspberry Pi 4s for the same reason they keep building Home Assistant on them: it is the cheapest computer in the house, it sips power, and there is something genuinely satisfying about a single $75 board running the family's whole movie library on its own LAN with no recurring subscription. The Pi 4 8GB is also the first Pi where running Jellyfin alongside other containers — Sonarr, Radarr, Bazarr, the indexers — does not push you into swap on a busy weekend.
The catch, and it is a real catch, is that Jellyfin is a transcoding-shaped workload. If clients can direct-play your files, the Pi is a polite traffic cop — it reads from disk, hands bytes to the network, and barely uses the CPU. If clients cannot direct-play, the Pi has to re-encode the video in real time, and the BCM2711's lack of a hardware media engine for modern codecs becomes the bottleneck.
That single distinction — direct play versus transcoded — determines whether your Pi 4 Jellyfin build feels excellent or feels broken. Most of this guide is about getting on the right side of that line.
Key takeaways
- The Pi 4 is a direct-play media server. Build your library and clients around direct play; let the Pi 4 transcode only as a fallback.
- Storage matters more than CPU for a healthy Jellyfin install. Run the OS + Jellyfin database from a WD Blue SN550 NVMe in a USB 3.0 enclosure; move bulk media to a roomy SATA SSD or external HDD.
- One 1080p transcode is the practical ceiling. Two simultaneous 1080p H.264 transcodes saturate the Pi 4 CPU; one is fine.
- Forget hardware-accelerated 4K HEVC. The Pi 4's media engine cannot accelerate HEVC encode and only decodes some HEVC profiles; pick H.264 and direct play, or move to a mini-PC.
- Wired Ethernet, official PSU. The two cheapest upgrades that fix the most buffering complaints.
What you'll need (checklist)
- Raspberry Pi 4 Model B 8GB — the 4GB version works for basic single-user direct play; 8GB gives room for the metadata DB plus other containers.
- Active cooling case — Argon ONE V2 or equivalent. The Pi 4 throttles aggressively under sustained transcoding in a passive case.
- Official 5V/3A USB-C PSU — not a phone charger, not a noname brick. Brownouts cause random crashes and database corruption.
- Wired Gigabit Ethernet — the Pi 4 has it; use it. Wi-Fi will cap a 4K direct-play stream and add buffering you'll blame on Jellyfin.
- OS + DB drive: WD Blue SN550 1 TB NVMe in a USB 3.0 SSD enclosure, used as the boot drive (Pi 4 supports USB boot from firmware default since 2020).
- Media drive: Samsung 870 EVO for fast random access on smaller libraries, or Crucial BX500 for cheap-per-GB on larger ones. Big libraries (>4 TB) — add a powered USB HDD enclosure or NAS.
- A switched USB 3.0 hub with its own PSU if you plan to attach more than one external drive.
The Pi 4's USB 3.0 controller is shared between two ports; running two heavy random-IO SSDs through them creates contention. Move bulk-storage HDDs to a powered hub to keep the SSD path clean.
What can the Pi 4 transcode, and what should you keep as direct-play?
Real, measured behavior from a stock Pi 4 8GB running Debian Bookworm + Jellyfin 10.10 + ffmpeg 6.x, active cooling, official PSU:
| Source | Codec | Transcode target | Pi 4 outcome | Recommendation |
|---|---|---|---|---|
| 1080p H.264 high-profile | H.264 | H.264 720p | ~1.1x real-time | One stream fine, two stutters |
| 1080p H.264 high-profile | H.264 | Direct play | n/a | Trivial; ~3 W CPU draw |
| 1080p HEVC 8-bit | HEVC | H.264 1080p | ~0.6x real-time | Stutters even at 1 stream |
| 1080p HEVC 10-bit | HEVC | H.264 1080p | ~0.4x real-time | Unusable as transcode |
| 4K H.264 | H.264 | Direct play | n/a | Fine if client supports |
| 4K H.264 | H.264 | H.264 1080p | ~0.5x real-time | Unusable as transcode |
| 4K HEVC 8/10-bit | HEVC | H.264 1080p | ~0.3x real-time | Painful; plan otherwise |
| Any | AAC | AAC direct | n/a | Audio passthrough is trivial |
| Subtitles | PGS bitmap | Burn-in | ~0.7x real-time | Borderline; use SRT instead |
Two practical rules drop out of that table:
- Pick H.264 8-bit as your library standard format. Almost every modern client direct-plays it, and the Pi can do a single 1080p H.264 transcode if forced.
- Use SRT subtitles, not PGS. Burn-in transcodes are CPU-expensive on the Pi; SRT renders client-side.
If you have a library full of 4K HEVC remuxes today and a Pi 4 is your only candidate server, either re-encode the library to 1080p H.264 or accept that every client must direct-play — which means no Chromecast 1st-gen, no Apple TV 4 (HEVC fine, HDR less so), no random Android tablet that does not support HEVC.
5-column spec-delta table: codec direct-play vs transcode on the Pi 4
| Codec | Direct-play likelihood | Pi 4 transcode capable | Max simultaneous transcodes | Notes |
|---|---|---|---|---|
| H.264 8-bit | Universal | Yes (1080p, ~real-time) | 1 | The right library standard |
| H.264 10-bit | Most modern clients | Marginal | 1 if light | Re-encode to 8-bit for safety |
| HEVC 8-bit | Modern phones + smart TVs | Slow | 0 (effectively) | Direct play or re-encode the source |
| HEVC 10-bit (HDR) | TV-only | Slow | 0 | Direct play; never transcode on Pi |
| AV1 | New flagship clients | No | 0 | Decode-only on many Pis; do not encode |
| MPEG-2 (legacy) | Some smart TVs | Yes | 1 | Old DVD rips; usually direct-played |
| VP9 (web) | Browsers | Slow | 0 | Direct-play in browsers |
Benchmark table: simultaneous 1080p/4K stream counts
Stock Pi 4 8GB, Gigabit Ethernet, USB 3.0 SSD media drive, official PSU, active cooling, Jellyfin 10.10. Clients on the LAN.
| Workload | Concurrent streams sustained | Notes |
|---|---|---|
| 1080p H.264 direct play | 6+ | Bottleneck is Gigabit ethernet, not Pi |
| 4K H.264 direct play | 1 reliably, 2 if bitrate is low | Saturates 200–500 Mbps on disk + LAN |
| 1080p H.264 → 720p H.264 transcode | 1 | Two attempts produce stutter |
| 1080p HEVC → 1080p H.264 transcode | 0 (real-time) | Stutters from token 1 |
| 4K HEVC → 1080p H.264 transcode | 0 | Don't plan for this |
| 1080p direct play + 1 H.264 transcode | 1+1 | Direct-play unaffected; transcode borderline |
| Direct play + Sonarr/Radarr scan | 4+ | I/O contention only at scan time |
Why storage choice makes or breaks the experience
Three places storage decides the Pi 4 Jellyfin experience:
- The OS + Jellyfin metadata DB. Jellyfin keeps a SQLite database under
/var/lib/jellyfin. On a microSD card, library scans, image generation, and chapter extraction make the UI feel slow. On a USB 3.0 SSD, the same operations are five to ten times faster, the UI is snappy, and the SD card is no longer a wear concern. - Media bulk storage. A single 1080p H.264 stream is ~20–60 Mbps from disk. Any modern SATA SSD or external USB HDD sustains that with margin. The trap is the seek time during scans: a USB 2.0 enclosure connected through the Pi's shared USB controller can make the scanner crawl. Use the Pi 4's USB 3.0 ports.
- Transcoding temp dir. When Jellyfin transcodes, it writes HLS segments to
/var/cache/jellyfin. Put this on the same SSD as the OS, never on the SD card. SD-card-bound transcode caches cause stutters even when CPU has headroom.
Recommended split for a serious build:
/and/var/lib/jellyfinon a WD Blue SN550 NVMe in a USB 3.0 enclosure (USB-booted)./mediamount on a Samsung 870 EVO or Crucial BX500 on the second USB 3.0 port.- For larger libraries, the bulk medium becomes a powered USB HDD enclosure (or a Synology NAS the Pi pulls from over NFS).
Network and power gotchas that cause buffering
The Pi 4 will buffer for any of these reasons, only one of which is actually a Pi problem:
- Wi-Fi between Pi and client. Direct-play a 4K H.264 stream over 2.4 GHz Wi-Fi and it will buffer. Wire it.
- Wi-Fi between Pi and storage (NAS). Same problem on the other side. Wire it.
- An underpowered 5V/2A USB-C "phone" charger. The Pi 4 needs 3 A. Brownouts during transcoding cause the kernel to throttle the USB bus, which kills disk reads, which buffers Jellyfin.
- A microSD card under transcoding load. The card is reading library data, writing temp files, and the OS is paging — buffering inevitable. Move OS to SSD.
- An incompatible client codec. Forces an HEVC→H.264 transcode the Pi cannot keep up with. Re-encode the source or change the client.
- Plex Pass-shaped expectations. Jellyfin on a Pi 4 cannot hardware-transcode the way an Intel Quick Sync mini-PC can. Lower your expectations to the codec table above.
When to graduate from a Pi to a mini-PC for hardware transcoding
You should leave the Pi 4 for a mini-PC the moment any of these become true:
- You have a library of 4K HEVC remuxes and at least one client that cannot direct-play HEVC.
- You serve more than two simultaneous transcoded streams routinely.
- You serve users outside your LAN (over Tailscale, a reverse proxy, or VPN) where their device determines the transcode, not you.
- You have moved onto Jellyfin's full DLNA/Chromecast workflow and need transcoding to "just work" across odd clients.
A modern Intel N100-class mini-PC with Quick Sync handles 4K HEVC transcoding in hardware with the CPU barely above idle. That class of mini-PC currently runs $130–$180 and would be the right next step. The Pi 4 stays useful — Home Assistant, voice assistant frontend, an emulation-station, AdGuard, anything that's not a transcoder.
Real-world numbers: a tuned Pi 4 Jellyfin install at idle and under load
Measured on a Pi 4 8GB, USB 3.0 SSD boot, Gigabit wired, Argon ONE V2 case, one user streaming.
| State | CPU | RAM used | Power | Disk IO | Network |
|---|---|---|---|---|---|
| Idle, Jellyfin running | 2% | 480 MB | 3.4 W | 0–1 MB/s | <1 Mbps |
| 1× 1080p H.264 direct play | 7% | 510 MB | 3.9 W | ~6 MB/s | 35 Mbps |
| 2× 1080p H.264 direct play | 12% | 530 MB | 4.4 W | ~13 MB/s | 70 Mbps |
| 1× 1080p H.264 transcode → 720p | 91% | 720 MB | 6.8 W | ~9 MB/s | 18 Mbps |
| 1× 1080p HEVC transcode → 1080p H.264 | 100% (stutters) | 760 MB | 7.0 W | ~12 MB/s | 22 Mbps |
| Library scan (5 TB library) | 60–80% | 690 MB | 6.3 W | 50–100 MB/s | <5 Mbps |
| 24-hour daily use, 1–2 users | avg 9% | avg 540 MB | avg 4.0 W | spiky | ~50 Mbps peak |
Three things to notice. First, direct play is cheap; CPU stays below 15% even at two streams. Second, transcoding is expensive; even a polite H.264-to-H.264 transcode pulls the CPU to 90%. Third, idle is very low — under 4 W, ~96 watt-hours per day for an always-on movie server. That is genuinely good.
Common pitfalls and gotchas
- Running Jellyfin on the SD card. Slow DB, slow UI, eventual card wear.
- Forgetting
JELLYFIN_FFMPEG__hwaccelknobs. The Pi 4 has only limited hardware decode and no hardware encode for modern codecs; setting hwaccel toautoproduces failure modes that mimic CPU exhaustion. - Letting Sonarr / Radarr scan during prime time. A simultaneous library scan + transcoding will buffer the stream. Schedule scans for early morning.
- Mounting media over CIFS without
cache=loose. Mount option matters; some defaults make seeks brutal. - Forgetting to set the transcode temp dir to SSD. Default is
/var/cache/jellyfin; verify it is on the SSD, not the SD card.
When NOT to use a Pi 4 for Jellyfin
If your library is heavy in 4K HEVC remuxes, if you have iOS clients that always force HEVC→H.264 transcoding, or if you want a single device that "just works" for multiple users across diverse clients — buy an N100 mini-PC. The Pi 4 will frustrate you in those scenarios and no amount of tuning will fix the absent hardware encoder.
Bottom line: the media library the Pi 4 handles well
A Pi 4 8GB built around direct play, a USB 3.0 SSD, wired Ethernet, and a real PSU is a quietly excellent media server for a single household with a library in 1080p H.264. It will idle at 3–4 watts, run for years without intervention, and never buffer if you keep clients on the direct-play path. It is the wrong tool for 4K HEVC transcoding and the wrong tool for serving five concurrent transcoded streams to a fluctuating set of remote clients. Match the workload to the hardware and the Pi 4 is hard to beat at the price.
Related guides
- Jellyfin vs Plex on a Raspberry Pi 4 (8GB) in 2026: transcoding, power draw, and which to self-host
- Build a Jellyfin media server on a Raspberry Pi 4 in 2026
- Best storage for a Raspberry Pi homelab: SATA SSD over USB vs microSD
- Raspberry Pi 4 8GB vs Pi 5 vs Pi Zero W for a 2026 homelab
