fix(build): ship +rpt1 ffmpeg on pi3-64 so H.264 uses HW decode

[vpetersson]

Issues Fixed

Addresses the video-decode/performance half of #3084 (pi3-64 video black / stalling).

Description

pi3-64 was missing from the board gate in docker/_rpt1-ffmpeg-pin.j2, so it shipped stock Debian ffmpeg while its sibling pi4-64 got the Raspberry Pi–patched +rpt1 build (--enable-v4l2-request --enable-sand --enable-vout-drm). Without +rpt1, QtMultimedia can't engage the VideoCore IV bcm2835-codec H.264 decoder and silently falls back to software decode.

The gate was introduced in #2885 (pi4-64, pi5, arm64); the pi3-64 board was added later in #2985 and grouped with pi4-64 everywhere else (eglfs/Qt6, the video path, "shares this exact path") — this gate was just missed. One-line fix: add pi3-64 to the tuple.

Diagnosed live on a real Pi 3 Model B+ running the 2026.07.0 (latest-pi3-64) release:

decode path	throughput	CPU (utime, 4 s clip)
SW h264 (what ships today)	22 fps / 0.74× realtime	5.6 s
HW h264_v4l2m2m (hardware, standalone)	75 fps / 2.49× realtime	0.25 s

The hardware decodes H.264 fine; the viewer just never reaches it. During playback AnthiasViewer holds only /dev/dri/card0 — never /dev/video10 — with zero dmesg/CMA activity, confirming pure SW decode. SW can't sustain 1080p30 on the Pi 3, so frames drop (~25% at 1080p) and, under thermal + memory pressure, presentation stalls toward zero fps — the likely driver of the reporter's black/frozen video in issue #3084. Offloading to HW (near-zero CPU) removes that pressure.

Confirmed the fix and its blast radius on the rendered Dockerfiles:

board	+rpt1 pin after this change
pi3-64	✅ added (was ❌)
pi4-64 / pi5 / arm64	✅ unchanged
x86 / pi2 / pi3 (Qt5)	❌ unchanged (correctly stay on stock)

Note: this ships in freshly-flashed images only on the next release; latest-pi3-64 upgrade users get it on the next master build. The stale "Included by BOTH … Dockerfile.server.j2" comment in the template is a separate pre-existing matter (only the viewer template currently includes the pin) and is left untouched here.

Checklist

• I have performed a self-review of my own code.
• New and existing unit tests pass locally and on CI with my changes.
• I have done an end-to-end test for Raspberry Pi devices.
• I have tested my changes for x86 devices.
• I added a documentation for the changes I have made (when necessary).

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR updates the Docker build templating so the pi3-64 board receives the Raspberry Pi–patched +rpt1 ffmpeg/libav* packages, enabling QtMultimedia to use hardware H.264 decode instead of falling back to software decode.

Changes:

• Add pi3-64 to the _rpt1-ffmpeg-pin.j2 board gate so it pins to the Raspberry Pi +rpt1 ffmpeg build.
• Add explanatory in-file commentary documenting why pi3-64 needs this pin (performance / HW decode path context).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[vpetersson]

Validated on real Pi 3 Model B+ hardware ✅

Built this branch's anthias-viewer:pi3-64 image locally (arm64 cross-build via tools.image_builder, registry buildcache) and deployed it to a real Raspberry Pi 3 B+ (the pi3-64 / eglfs / Qt6 stream, HDMI connected), keeping server/redis/celery on the 2026.07.0 release. Confirmed the artifact carries the patched ffmpeg:

ffmpeg version 7.1.5-0+deb13u1+rpt1   (Installed from archive.raspberrypi.com)

Then played the same 1080p H.264 clip on the stock release image vs this fix:

	ffmpeg	/dev/video10 (HW decoder)	1080p decode
release (stock)	…+deb13u1	never opened	SW — dropped grows ~25%, can't sustain realtime
this PR (+rpt1)	…+deb13u1+rpt1	held by AnthiasViewer	HW — frames-delivered == expected, dropped=0 steady-state

playback-stats.log under the fix, steady state:

SAMPLE position-ms=9900  frames-delivered=295 expected=295 dropped=0
SAMPLE position-ms=10833 frames-delivered=326 expected=326 dropped=0
SAMPLE position-ms=11900 frames-delivered=355 expected=355 dropped=0

So H.264 decode moves off the CPU onto the VideoCore IV and now sustains 1080p30 at zero decode drops — which is the resource-pressure mechanism behind the #3084 blank/frozen video on hot, RAM-starved devices.

Out of scope / unchanged: the presented frame rate is still capped at ~10 fps by the separate Qt6 RHI presentation-pacing bottleneck (#2967-era) — that's a distinct issue from decode and not addressed here.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.