mirror of
https://github.com/Screenly/Anthias.git
synced 2026-07-30 09:15:51 -04:00
d8ecf545de
Rotated video on the Qt5 linuxfb boards (Pi 1/2/3) collapses to ~2 fps because the software `videoflip` rotates every full-resolution frame on a single core. Issue #3198 only measured 90, but 180 is just as broken (measured 2.3 fps on a Pi 2 at 1080p30, vs 27 fps unrotated). 180 does not need the CPU at all: a horizontal flip plus a vertical flip composes to a 180 rotation, and the bcm2835 ISP exposes both as v4l2 controls on the same `v4l2convert` pass that already does the aspect-fit scale. Driving them via `extra-controls` keeps the pipeline fully hardware and restores the full frame rate. Measured on a Pi 2 (1080p30, HW decode ceiling 43.7 fps), by fpsdisplaysink: rotation 0 (all hardware) 27.2 fps rotation 180 (videoflip, before) 2.3 fps rotation 180 (ISP flip, after) 26.9 fps The ISP output is pixel-identical to the software rotation (mean absolute difference 0.00 against rot180 of the unflipped frame), and the integrated viewer stack on a Pi 2 reproduces the same result end to end: 0.5 -> 7.7 delivered fps at rotation 180, matching the unrotated reference, with the screen visibly rotated. 90/270 keep the software videoflip and stay slow: they need a transpose, and no bcm2835 device exposes a rotate control (`v4l2-ctl -l` on the ISP lists only hflip/vflip) — the same limit the pi3-64 vc4 DRM plane hits, which offers 0/180 + reflect only. Reordering to scale-before-flip does not rescue them either: the case that matters, portrait content on a portrait panel, rotates to exactly fill the framebuffer, so there is no downscale to exploit ahead of the flip (measured 1.9 vs 2.1 fps, i.e. slightly worse). Documented as unsupported instead of pretending otherwise. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Documentation
This page has moved to https://anthias.screenly.io/docs/.
The Anthias documentation now lives at https://anthias.screenly.io/docs/.