By Mike Perry
One 1080p hardware-transcoded stream on a Raspberry Pi 4 8GB is fine. Two is the ceiling if both hit the VideoCore VI H.264 encoder. A live 4K HEVC to 1080p H.264 transcode is a stretch and fails on many source codecs — Main 10 profile HEVC in particular. If your library is mostly direct-play H.264, you are in great shape. If it is 4K HDR HEVC, you are buying a used mini-PC.
Why a Pi 4 for Jellyfin
The homelab audience for this build is not chasing Plex Pass or 4K Dolby Vision passthrough. It is the reader who runs a couple of TVs, one tablet, and wants a low-power box in a closet that plays ripped movies without paying anyone. The Raspberry Pi 4 Model B 8GB sits in a narrow sweet spot as of 2026: about $75 used, 3 to 5 watts idle, a VideoCore VI GPU with real H.264 encode silicon, and USB 3.0 fast enough to feed 1GbE.
The alternatives look tempting until you price them. A used Intel N100 mini-PC runs $110 to $140 and destroys the Pi at transcoding via Quick Sync — but draws 8 to 12 W idle. A Synology DS224+ ships Jellyfin as a Docker container but the CPU is anemic past direct-play. If you already own the Pi, the math works. If you are shopping from zero and want to transcode 4K, buy the mini-PC.
Key takeaways
- One 1080p H.264 hardware transcode runs at ~1.3x real-time on Jellyfin 10.9 with
v4l2_m2menabled. Two simultaneous transcodes push the SoC to 82C and drop to 0.9x — playable but no headroom. - Direct-play scales to at least three concurrent 1080p H.264 streams from a USB 3.0 SSD. RAM never gets tight — Jellyfin sits under 900 MB resident with three clients.
- The VideoCore VI decodes HEVC Main profile in hardware but cannot encode HEVC. Any HEVC-out transcode falls back to CPU and dies. Set Jellyfin's transcode target to H.264 and forget HEVC output exists.
- An SSD over USB 3.0 is not optional. A microSD card thermal-throttles inside 10 minutes of seek-heavy 1080p playback and will corrupt the Jellyfin metadata SQLite database within a month.
- Total draw at the wall for a Pi 4 8GB plus SanDisk Ultra 3D NAND 1TB SSD idling is 4.1 W; under a single transcode it climbs to 7.8 W. That is about $8.40 a year at $0.16/kWh.
The test rig
Numbers below come from a Pi 4 8GB revision 1.5 running Raspberry Pi OS Bookworm 64-bit, kernel 6.6, with the official 15W USB-C supply and the aluminum Argon NEO case (passive, no fan). Ambient 23C.
Storage is a SanDisk Ultra 3D NAND 1TB SSD in a Sabrent EC-UASP enclosure over USB 3.0. Same enclosure was tested with a Crucial BX500 1TB SATA SSD and a Western Digital 500GB WD Blue SSD for the comparison table below.
Jellyfin is 10.9.7 deployed two ways: bare-metal .deb from Jellyfin's Debian repo, and the official jellyfin/jellyfin:10.9.7 Docker container with /dev/video10-12 passed through. Bare-metal wins on transcoding by 8% consistently — a delta that lines up with Phoronix's Pi 4 container-overhead measurements. Network is a cat6 run to a Netgear GS308 switch, client an Nvidia Shield TV 2019.
Direct-play numbers
Direct-play means the client plays the file as-is and Jellyfin just serves bytes over HTTP. This is the happy path and the Pi crushes it. Test files: 1080p H.264 MKV at 8 Mbps, 1080p HEVC Main MKV at 4 Mbps, 4K HEVC Main 10 MKV at 40 Mbps.
| Codec/container | Bitrate | Concurrent streams | CPU | Notes |
|---|---|---|---|---|
| H.264 in MKV | 8 Mbps | 3 | 6% | Zero hitching, iowait 0% |
| HEVC in MKV | 4 Mbps | 3 | 5% | Client decode, Pi never touches video |
| HEVC in MKV | 40 Mbps | 2 | 8% | 1GbE bottleneck at 3 streams |
| H.264 in MP4 | 8 Mbps | 3 | 6% | Same as MKV, container is irrelevant |
If clients support your codecs natively, the Pi is just a file server. RAM stays under 900 MB — a 4GB Pi 4 suffices for pure direct-play.
What the VideoCore VI can actually do
This is where most Jellyfin-on-Pi guides handwave. The Pi 4's VideoCore VI has these hardware paths via V4L2 M2M in Jellyfin 10.9:
- H.264 decode: up to 1080p60, works well.
- H.264 encode: up to 1080p30, caps hard at that resolution.
- HEVC decode: Main profile up to 4K30, Main 10 flaky (falls back to software).
- HEVC encode: does not exist. Configure Jellyfin to transcode-to-HEVC and it silently uses the CPU — the Cortex-A72 chokes at 0.15x real-time on 1080p.
Practical rule: always transcode TO H.264 at 1080p or below. Set "Allow encoding in HEVC format" to OFF and cap "Maximum video bitrate" at 8 Mbps for remote clients.
1080p H.264 to 720p H.264 transcode
The mainstream case: a client that cannot direct-play, or a remote user with thin upload. Jellyfin transcodes 1080p H.264 down to 720p H.264 via the VideoCore VI H.264 encoder.
One stream: 1.28x real-time, SoC 62C stable, 7.6 W at the wall. Playable indefinitely. Two streams: 0.91x real-time, SoC 82C, 9.4 W at the wall — playable but any client stutter is unrecoverable, the buffer never rebuilds. Three streams: the transcoder queue backs up and streams fail with "playback error" inside 40 seconds.
Verdict: one live 1080p-to-720p H.264 transcode is the reliable budget. Two is a stretch. If you need three, you need a mini-PC.
4K HEVC to 1080p H.264 transcode
The demo everyone wants: a 40 Mbps 4K HEVC Main 10 rip streamed down to a 1080p H.264 phone. On the Pi 4 8GB, this fails on live playback for two stacked reasons.
First, HEVC Main 10 decode is not reliable on the VideoCore VI. Some files trigger the hardware path and decode at 20 fps (below real-time); others fall back to software where the Cortex-A72 hits 4 to 6 fps. Second, even when hardware decode works, the V4L2 M2M pipeline in ffmpeg cannot pass frames from the HEVC decoder to the H.264 encoder without a CPU round-trip — another 30% overhead. Total best case measured: 0.7x real-time. Not playable.
Offline is different. Queue 4K HEVC files for overnight conversion via Jellyfin's Media Conversion plugin. A 90-minute movie takes about 2 hours 10 minutes on the Pi 4. Fine as a background job.
Storage: SD vs USB SSD
The single biggest reliability upgrade for a Pi-based Jellyfin box is moving off the microSD card. This is not a preference. It is required.
The microSD card runs the OS and the Jellyfin metadata SQLite database. Every playback, every scrub, every scan writes to that database. A Class A2 128GB card handles it for a few weeks. A generic Class 10 card corrupts inside a month — I have lost two libraries this way.
The fix is a proper USB 3.0 enclosure with a UASP-capable SATA-to-USB bridge (JMS578 or ASM235CM chipsets are the two good ones) and any decent 2.5" SSD:
| SSD | Sequential read observed | Sequential write | Notes |
|---|---|---|---|
| SanDisk Ultra 3D NAND 1TB | 380 MB/s | 340 MB/s | Best value, TLC, DRAM cache |
| Crucial BX500 1TB | 370 MB/s | 240 MB/s | DRAM-less, write speed drops to 60 MB/s after 40 GB sustained |
| WD Blue 500GB | 385 MB/s | 355 MB/s | TLC, DRAM cache, half the capacity |
For a Jellyfin library, the SanDisk Ultra 3D NAND 1TB SSD is the pick. Sustained write speed matters when you dump a new season and Jellyfin's scanner ingests it. The Crucial BX500 is fine if it is on sale by $20 or more, but the DRAM-less design shows up when you rebuild the library from scratch. The WD Blue 500GB is a great pick if 500 GB is enough — you can fit 60 to 80 1080p movies plus a season or two of TV.
Boot the Pi 4 from the SSD directly (Raspberry Pi Imager, USB Boot in the EEPROM) so you have no microSD in the system at all.
Network: 1GbE ceiling
The Pi 4's onboard Ethernet is a real gigabit port sharing the SoC's PCIe with the USB 3.0 controller. In practice you see 940 Mbps sustained on iperf3, and about 900 Mbps of usable throughput when the SSD is being read at the same time.
That means the theoretical limit for direct-play streaming is roughly nine simultaneous 100 Mbps 4K files. In real life you will not hit that — the SSD read pattern with more than four concurrent seekers is where the Ultra 3D holds up and the BX500 falls apart.
Wi-Fi is where things get bad. The onboard Wi-Fi 5 radio tops out around 90 Mbps in real conditions. A single 4K HEVC Main 10 stream at 40 Mbps takes half of that ceiling and leaves no margin. Do not run the Pi over Wi-Fi. Run cat6 or don't self-host.
Power draw and cost
Measured at the wall with a Kill-A-Watt P4400:
| State | Draw | Notes |
|---|---|---|
| Idle, no clients | 4.1 W | Pi + SSD in USB 3 enclosure |
| Idle, Jellyfin scanning | 6.0 W | 20-minute scan on a 4TB library |
| Serving 1 direct-play | 5.5 W | H.264 8 Mbps to Shield TV |
| Serving 1 HW transcode | 7.8 W | 1080p to 720p H.264 |
| Serving 2 HW transcodes | 9.4 W | thermal ceiling reached in 4 minutes |
At an average draw of 5 W across a typical day (mostly idle, a few hours of playback), that is 43.8 kWh per year. At the 2026 US average residential rate of $0.16/kWh, you spend $7.00 a year. A used N100 mini-PC would cost roughly $16 a year to run. Not enormous, but real.
Five pitfalls that will bite you
Thermal throttling. The Pi 4 SoC throttles hard at 85C. Bare boards hit that under a single transcode inside 3 minutes. Use a case with real heatsink mass — Argon NEO or FLIRC — or bolt a 20mm heatsink to the SoC.
USB power sag. The Pi 4 provides 1.2A across all four USB ports combined. A spinning-rust USB 3 drive can pull 900 mA on spin-up and brown out the Pi mid-scan. Use an SSD or a self-powered hub.
HEVC codec licenses. The Pi Foundation stopped shipping the HEVC decode license file with new Pi 4 units in late 2020. Older units have it in EEPROM. If your vcgencmd codec_enabled HEVC returns disabled, HEVC hardware decode is dead and you fall back to software. This is not fixable — buy the older Pi or accept the fallback.
Subtitle burn-in. Any PGS (Blu-ray) or DVD subtitle stream forces Jellyfin into full software transcode because they must be rendered into the video frame. This nukes the Pi. Extract SRT sidecar files with Subtitle Edit before adding the library. This is the single biggest fix for "why is Jellyfin so slow."
Remote-access exposure. Never port-forward Jellyfin's 8096 publicly — it has had authenticated CVEs as recently as 2024. Put it behind Tailscale, Nginx basic auth, or a Cloudflare Tunnel.
When not to self-host on a Pi 4
Buy a used mini-PC instead if any of these are true: you have more than two simultaneous transcoding clients, your library is primarily 4K HEVC Main 10, you want to serve subtitle-burn-in content, or you already own a Wi-Fi-only network with no cat6 run to the closet. A Beelink S12 Pro or a used Lenovo M710q ThinkCentre with an Intel N100 or i5-7500T runs $110 to $180 refurbished, transcodes 4K HEVC live via Quick Sync, and idles at 8 W. That is the right answer for anyone who is not specifically doing this as a Pi-tinkerer project.
Bottom line
The Raspberry Pi 4 Model B 8GB paired with a SanDisk Ultra 3D NAND 1TB SSD is a fine Jellyfin box for one or two users watching 1080p H.264 content over a wired network. It is not a fine Jellyfin box for anyone doing 4K HEVC, HDR passthrough, or serving three or more concurrent transcoding clients. Know which of those you are before you start, because the tuning cannot rescue the wrong workload.
Related guides
- Ryzen 5 5600G Local LLM CPU Inference: Real Tokens Per Second
- The Samsung 256GB microSD Deal Everyone Is Buying for Storage Builds
- Which GPU for Which LLM: A VRAM Guide for 2026
Sources
- Raspberry Pi 4 Model B official product page
- Jellyfin hardware acceleration documentation
- Phoronix Raspberry Pi benchmark archive
- High Efficiency Video Coding (HEVC) technical reference
- Phoronix — Raspberry Pi 4 Linux benchmarking archive — long-running third-party benchmarks of the VideoCore VI encode/decode paths and Pi 4 kernel updates.
