Rotated video is ~2 fps on Pi 1/2/3 (linuxfb): fix 180 in the ISP, 90/270 have no HW path #3198

Summary

On the linuxfb boards (Pi 1 / 2 / 3, Qt5), playing a rotated 1080p video (screen_rotation = 90/180/270) drops to ~1 fps. Unrotated playback on the same board is fine (~26–30 fps). The rotation itself is visually correct — it's the frame rate that collapses.

Measurements (real Pi 2, 1 GB)

Delivered framebuffer fps measured by sampling /dev/fb0 (distinct frames/sec), with a full-frame-motion source (ffmpeg -f lavfi -i mandelbrot, 1080p30):

At rotation 90 the gst_fbdev_player.py process sits at 100 % of a single core.

Root cause

Decode is hardware (v4l2h264dec). The bottleneck is the software videoflip element in src/anthias_viewer/gst_fbdev_player.py:

videorate ! videoflip method=<...> ! v4l2convert (aspect-fit) ! fbdevsink

videoflip rotates the full-resolution decoded frame in software (single-threaded) before the fit-scale, which a Cortex-A7/A53 can only sustain at ~1 fps for 1080p.

Scope / not a regression

Pre-existing — the videoflip rotation path was introduced in the aspect-fit/30fps-cap change (commit 9863d8c, 2026-06). Not related to the still-image / web-page linuxfb rotation work, which adds no per-frame CPU cost.

Possible directions

• Scale before flip — rotate the small fitted frame instead of the full 1080p one (~3× cheaper, likely still short of 30 fps).
• Offload rotation to hardware — check whether the bcm2835 ISP (v4l2convert) exposes a rotate control so the flip can run in the ISP instead of the CPU.
• If neither is feasible, document rotated video as unsupported on Pi 1/2/3 (use Pi 4/5).

🤖 Generated with Claude Code