Home

Hardware HEVC decode for Moonlight on the Raspberry Pi 5

September 2026. Raspberry Pi OS Trixie, kernel 6.18, Pi 5.

The packaged moonlight-qt on a Pi 5 warns that no hardware decoder was found and streams in software H.264. For months I took that at face value: the Pi 5 dropped the H.264 block, HEVC needs the V4L2 request API, and ffmpeg upstream has never merged it. The conclusion was that 1080p60 software decode was the ceiling for this board.

That conclusion was true of the binary, not the hardware.

What is actually wrong

The Pi 5 has a real HEVC decoder (rpivid, exposed as /dev/media2 plus /dev/video19). Raspberry Pi ships a patched system ffmpeg that can drive it:

$ ffmpeg -version | head -1
ffmpeg version 7.1.5-0+deb13u1+rpt1
$ ffmpeg -buildconf | grep -o -- '--enable-v4l2-request\|--enable-sand'
--enable-v4l2-request
--enable-sand

But the moonlight-qt .deb from Moonlight's own repository statically links its own ffmpeg, and that vendored copy predates the kernel 6.12 change to how the decoder node is found. Upstream Moonlight has not cut a release since September 2024, so the bundle never picked up the fix. The system ffmpeg had it the whole time.

Proof, from the system ffmpeg decoding a HEVC sample:

Hwaccel V4L2 HEVC stateless V4; devices: /dev/media2,/dev/video19
buffers: src DMABuf, dst DMABuf; V4L2fmt Nc12
120 frames decoded; 0 decode errors

The fix

Build moonlight-qt from source. A source build links ffmpeg dynamically, so it picks up the Raspberry Pi system libraries. Install the result under ~/.local/bin, which shadows /usr/bin; the packaged version stays installed and one deleted symlink reverts.

sudo apt install -y qt6-base-dev qt6-declarative-dev qt6-wayland \
  libegl-dev libsdl2-dev libsdl2-ttf-dev libopus-dev libssl-dev \
  libavcodec-dev libavformat-dev libavutil-dev libswscale-dev \
  libva-dev libvdpau-dev libdrm-dev libplacebo-dev \
  libxkbcommon-dev wayland-protocols

mkdir -p ~/src && cd ~/src
git clone --recursive https://github.com/moonlight-stream/moonlight-qt.git
cd moonlight-qt          # built at 0eff3b9, 2026-08-30
qmake6 moonlight-qt.pro
make -j4

mkdir -p ~/.local/bin
ln -s ~/src/moonlight-qt/app/moonlight ~/.local/bin/moonlight-qt

Confirm the shadowing took: which moonlight-qt should print the ~/.local/bin path. Leave codec and decoder on auto. Moonlight only picks HEVC when the client can hardware-decode it, so on the old binary auto always landed on H.264. It now chooses HEVC by itself and Sunshine on the host follows with hevc_nvenc. Forcing either setting brings the on-screen warnings back.

Measured, same board, same evening

1440p120 is about 442 megapixels per second against rpivid's 4Kp60 rating of roughly 497, so that is near the decoder's ceiling and still under a tenth of one core. Bitrate went from 25 Mbps to 80 Mbps at the same time: the old cap was a software-decode constraint, since more bits meant more CABAC parsing on the CPU, and in hardware that cost is gone.

Where the ceiling moved

Decode is no longer the limit. Two other things are.

• HDMI 2.0. About 14.4 Gbps of payload. 1440p120 at 8-bit fits, 4K60 fits, 4K120 does not, and 10-bit or HDR at 1440p120 does not either. So --no-hdr stays.
• The host. Sunshine captures a 3440x1440 ultrawide whose EDID lists no 2560x1440 mode and tops out at 100 Hz, so asking for 1440p120 made it fall back to a 1080p desktop. Frame rate is capped by the capture side, not the Pi.

One more warning that never goes away

Moonlight still shows "No functioning hardware accelerated video decoder was detected" for a few seconds at launch. It raises this whenever it finds no decoder it recognizes by name, it is informational rather than blocking, and it dismisses itself when the session starts. There is no setting for it. Nothing needs to press OK, and on my box the script that used to press Return for it was landing keystrokes in Steam Big Picture instead.

Home