{"id":530,"date":"2026-10-06T09:15:00","date_gmt":"2026-10-06T07:15:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/?page_id=530"},"modified":"2026-09-25T15:07:52","modified_gmt":"2026-09-25T13:07:52","slug":"zero-latency-local-media-server-jellyfin-on-raspberry-pi-5-with-hardware","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/en\/raspberry-pi\/tutorials-en-raspberry-pi\/zero-latency-local-media-server-jellyfin-on-raspberry-pi-5-with-hardware\/","title":{"rendered":"Zero-Latency Local Media Server: Jellyfin on Raspberry Pi 5 with Hardware Acceleration"},"content":{"rendered":"

Architectural Overview: Media Transcoding on the Raspberry Pi 5<\/h2>\n

Hosting a self-managed video streaming server on a Raspberry Pi traditionally faced severe performance bottlenecks when client devices required real-time transcoding. Unsupported codecs, incompatible audio streams, or bandwidth restrictions force the media server to decode and re-encode video frames on the fly. On general-purpose ARM processor cores, software-based transcoding of high-bitrate HEVC (H.265) or 4K media rapidly exhausts CPU resources, leading to thermal throttling and playback stuttering.<\/p>\n

The Raspberry Pi 5 (powered by the Broadcom BCM2712 SoC) decodes only HEVC in hardware, and that decoder is stateless: it is driven through the V4L2 request API, not through stateful V4L2-M2M decoders such as hevc_v4l2m2m<\/code>. Jellyfin<\/strong> does not use it: its \u201cVideo4Linux2\u201d option only employs V4L2 encoders such as h264_v4l2m2m<\/code>, and the Pi 5 has no encoder; the project has also deprecated V4L2 support for the Raspberry Pi. Run as a container on the Pi 5, Jellyfin therefore decodes and encodes in software on the four ARM Cortex-A76 cores; low power consumption applies to Direct Play, not to transcoding.<\/p>\n

\n\"Three-layer
On the Pi 5, Jellyfin transcodes in software: V4L2 is deprecated for the Pi, hardware acceleration is set to \u201cNone\u201d, and Jellyfin does not use the stateless HEVC decoder \u2014 only direct play stays fast and frugal.<\/figcaption><\/figure>\n

Step-by-Step Implementation Guide<\/h2>\n

Step 1: Host Operating System Preparation and DRM Device Verification<\/h3>\n

A 64-bit Raspberry Pi OS Lite installation is required to ensure compatibility with 64-bit FFmpeg hardware libraries; current images have been based on Debian 13 (Trixie) since October 2025, with Debian 12 (Bookworm) as the minimum version. Before initializing container runtimes, the presence of Direct Rendering Manager (DRM) devices must be verified via terminal:<\/p>\n

ls -l \/dev\/dri<\/code><\/pre>\n
A healthy system output displays the card and render nodes (card0<\/code>, card1<\/code>, renderD128<\/code>). To allow Docker containers access to these graphics nodes, the executing service group permissions must be confirmed:<\/p>\n
sudo usermod -aG video,render \"$USER\"<\/code><\/pre>\n
Step 2: Persistent NVMe Storage Architecture and Directory Layout<\/h3>\n
For zero-latency library scanning and smooth high-bitrate streaming, media archives should reside on an NVMe SSD connected via the PCIe 2.0\/3.0 interface or a UASP-compatible USB 3.0 storage array. A clean directory hierarchy is created under \/opt\/containers\/jellyfin\/<\/code>:<\/p>\n
mkdir -p \/opt\/containers\/jellyfin\/{config,cache}\nmkdir -p \/mnt\/media\/{movies,series}\nchmod -R 755 \/mnt\/media<\/code><\/pre>\n
Step 3: Designing the Declarative Docker Compose Stack<\/h3>\n
The container orchestration is defined inside \/opt\/containers\/jellyfin\/docker-compose.yml<\/code>. The host’s \/dev\/dri<\/code> directory, which hardware-accelerated transcoding would need, is mapped into the container, on the Pi 5 only as a precaution (see Step 4), and the container process must run under a fixed user ID set via user<\/code> while additionally joining the host’s render<\/code> and video<\/code> groups by their numerical GIDs via group_add<\/code>:<\/p>\n
services:\n  jellyfin:\n    image: jellyfin\/jellyfin:latest\n    container_name: jellyfin\n    restart: unless-stopped\n    user: \"1000:1000\"\n    group_add:\n      - \"44\"  # Replace with the host numerical GID of 'video'\n      - \"109\" # Replace with the host numerical GID of 'render'\n    network_mode: \"host\"\n    environment:\n      - JELLYFIN_PublishedServerUrl=http:\/\/jellyfin.lukaswojcik.com\n    volumes:\n      - \"\/opt\/containers\/jellyfin\/config:\/config\"\n      - \"\/opt\/containers\/jellyfin\/cache:\/cache\"\n      - \"\/mnt\/media:\/media:ro\"\n    devices:\n      - \"\/dev\/dri:\/dev\/dri\"\n    security_opt:\n      - no-new-privileges:true<\/code><\/pre>\n
Technical Note:<\/em> Using network_mode: \"host\"<\/code> maximizes network throughput and enables automatic DLNA\/UPnP local network discovery without complex bridge port-forwarding rules.<\/p>\n
Step 4: Transcoding Settings in the Jellyfin Dashboard<\/h3>\n
After launching the stack via docker compose up -d<\/code>, transcoding is set up within the Jellyfin administrative interface:<\/p>\n
    \n
  1. Access the web interface at http:\/\/<Raspberry-Pi-IP>:8096<\/code> and navigate to Dashboard → Playback → Transcoding<\/strong>.<\/li>\n
  2. In the Hardware acceleration<\/strong> dropdown menu, the setting stays at None<\/strong>. Video4Linux2 (V4L2)<\/strong> does nothing on the Pi 5: Jellyfin only uses V4L2 encoders through it, the BCM2712 has no video encoder at all, and the Jellyfin documentation lists V4L2 for the Raspberry Pi as deprecated. An OpenMAX\/OMX entry no longer exists: Jellyfin has removed it, and Raspberry Pi OS dropped the OMX interface with Bullseye.<\/li>\n
  3. There are therefore no hardware decoding boxes to check. Jellyfin does not address the SoC’s only hardware decoder, the one for HEVC<\/strong>, and the BCM2712 no longer contains the H.264, MPEG-2 and MPEG-4 decoder blocks of the Raspberry Pi 4; all formats are decoded in software on the Cortex-A76 cores.<\/li>\n
  4. Set the FFmpeg path<\/strong> to \/usr\/lib\/jellyfin-ffmpeg\/ffmpeg<\/code> and save the configuration.<\/li>\n<\/ol>\n
    Step 5: Quality Assurance and Real-Time Transcoding Verification<\/h3>\n
    How heavily transcoding loads the CPU, and whether Jellyfin re-encodes at all, is shown by a check during an active video stream:<\/p>\n
      \n
    1. Initiate a Transcoded Stream:<\/strong> Play an HEVC (H.265) 10-bit video file on a web browser client that lacks native H.265 support, forcing Jellyfin to transcode to H.264. Both decoding and encoding run in software here: Jellyfin does not use the Pi 5’s HEVC decoder, and the BCM2712 contains no video encoder at all, so the H.264 encoding is performed by libx264 on the CPU.<\/li>\n
    2. Inspect FFmpeg Process Architecture:<\/strong> In an SSH terminal on the Raspberry Pi, run htop<\/code> or top<\/code>. Because decoding and encoding stay in software, heavy load across all four cores is expected in this scenario and does not indicate a broken setup. Low CPU figures only appear when no re-encoding takes place, that is during Direct Play. Whether the HEVC decoder itself works is only shown by a decode-only test outside Jellyfin with the FFmpeg from Raspberry Pi OS on the host, such as ffmpeg -hwaccel drm -i file.mkv -f null -<\/code>.<\/li>\n
    3. Audit Transcoder Logs:<\/strong> Check the generated logs under \/opt\/containers\/jellyfin\/config\/log\/ffmpeg-transcode-*.txt<\/code>. A decoder such as hevc_v4l2m2m<\/code> does not appear there, because Jellyfin sets no decoder for V4L2. The telling entry is the one after -codec:v:0<\/code>: libx264<\/code> means the picture is re-encoded, copy<\/code> means it is only repackaged.<\/li>\n<\/ol>\n
      Summary and Measurable Added Value<\/h2>\n
      What is achieved:<\/strong> Deployment of a containerized, self-hosted Jellyfin media server on a Raspberry Pi 5 that serves video files via Direct Play and transcodes in software when needed.<\/p>\n
      Resulting added value:<\/strong><\/p>\n