Levandor

Camwall Moved Off Birdseye to a 4-Substream 2×2 Composite

5 min read

With a second physical camera added (the new ÉSZAK Tapo TC47), the TV camwall was moved off Frigate’s birdseye onto an explicit 4-substream 2×2 composite built directly in mpv. Key finding: Frigate birdseye is unreliable as a fixed multi-cam wall source once you have more than two cameras — it flip-flops between showing 2 and 4 cameras depending on activity. See also TV wall (HDMI), 2026-07-18-birdseye-nvenc-blue-glare, SESSION-HANDOVER.

For Agents

What changed: /usr/local/bin/camwall-mpv.sh now composites the 4 go2rtc substreams directly into a grouped 2×2 (DÉL left column, ÉSZAK right column) via an mpv --vf lavfi filtergraph, instead of playing rtsp://127.0.0.1:8554/birdseye. Cameras: cam1_sub=DÉL-Fix, cam2_sub=DÉL-PTZ, cam3_sub=ÉSZAK-Fix, cam4_sub=ÉSZAK-PTZ. The new ÉSZAK camera is 192.168.30.139 (telep_cam3 fix + telep_cam4 ptz) added to Frigate alongside DÉL (cam1/cam2). Keep --hwdec=no. Backup: camwall-mpv.sh.bak-2x2.

Why: birdseye is unreliable for a fixed >2-cam layout

Frigate birdseye flip-flops between 2 and 4 cameras

Birdseye is a dynamic/activity-driven composite — it drops cameras depending on activity/state, so with 4 cameras it visibly flip-flops between showing 2 and 4. That is fine for its intended “show me what’s active” purpose but cannot be used as a stable fixed wall source once you have more than two cameras. The old 2-camera wall tolerated it; the 4-camera wall does not.

This is a different birdseye problem from the earlier NVENC “blue glare” corruption — that was encoder wedging; this is birdseye’s compositing logic dropping panes by design.

The new camwall composite

/usr/local/bin/camwall-mpv.sh was rewritten to:

  • Take cam1_sub as the primary mpv input, and pull cam2_sub / cam3_sub / cam4_sub in via libavfilter movie= sources.
  • Grouped 2×2 layout: DÉL in the left column (Fix top, PTZ bottom), ÉSZAK in the right column.
  • Four drawtext labels (one per pane).
  • Dropped the old “TOP KÉPEK” overlay (the static JPEG strip).
  • Kept the wifi-usage IPC osd-overlay strip — still fed via --input-ipc-server=/run/camwall.sock (see 2026-07-22-wifi-usage-strip).

Substream map (all via go2rtc on rtsp://127.0.0.1:8554/):

PaneSubstreamCamera
top-leftcam1_subDÉL – Fix
bottom-leftcam2_subDÉL – PTZ
top-rightcam3_subÉSZAK – Fix
bottom-rightcam4_subÉSZAK – PTZ

Gotchas

mpv movie= rtsp URLs need the colons escaped

libavfilter parses : as an option separator, so an rtsp URL inside a movie= source must be written rtsp\://127.0.0.1\:8554/... (escape every colon) or the filtergraph fails to parse. Also: movie= can’t take rtsp_transport, so it emits a benign 461 Unsupported transport and falls back UDP→TCP on its own. Harmless — do not chase it.

A movie= pane can freeze on its last frame if go2rtc restarts

The mpv watchdog only covers the primary input (cam1_sub). If go2rtc restarts, the three movie=-sourced panes can freeze on their last frame until camwall is restarted. Tradeoff accepted vs birdseye’s flip-flopping. If a pane looks stuck, systemctl restart camwall.

Keep --hwdec=no — NVDEC corrupts these feeds (magenta)

Same established rig philosophy as before: software decode on the 12900K. The RTX 3080’s NVDEC corrupts these feeds into magenta under GPU contention with Frigate. Do not “optimize” the wall back onto hardware decode.

Latency fix (2026-07-29) — 4 tiled single-input mpv instances

The 2×2 composite worked but the TV wall ran ~10–13 s behind live. Isolated to mpv’s single-composite movie= lavfi buffering — the camera and go2rtc were each only ~1 s, so the multi-input filtergraph was the whole delay.

Fix: one low-latency mpv per quadrant, not one mpv compositing four inputs

Rearchitected /usr/local/bin/camwall-mpv.sh into 4 tiled single-input low-latency mpv instances — one per quadrant via per-instance --geometry, each with --profile=low-latency --cache=no and a per-pane drawtext label. Result: ~1–2 s per pane, stable (down from ~10–13 s). Backup camwall-mpv.sh.bak-latency. The single-composite movie= filtergraph is what buffered; single-input panes don’t.

SUPERSEDED (2026-07-31): the residual multi-second lag is 2.4 GHz WiFi bufferbloat, not mpv

The tiled rearchitecture helped, but it was not the whole story. The wandering per-pane lag that persisted — up to ~12 s, worst on DÉL — even after a full rebuild to a go2rtc MSE/chromium wall, is 2.4 GHz camera-WiFi saturation (99% channel-busy → bufferbloat), a capacity problem upstream of both mpv and go2rtc that no player-side fix can resolve. Full evidence chain + ranked fixes: 2026-07-31-camwall-lag-24ghz-wifi-bufferbloat.

Two known regressions from the tiled rearchitecture (open follow-ups)

  • (a) WiFi strip now confined to the BL pane — it was full-width under the old single-mpv composite; with 4 separate mpv processes the /run/camwall.sock IPC osd-overlay only lives on the one socket-owning pane. Cosmetic.
  • (b) Watchdog freeze-detection now only covers the one IPC-socket-owning pane (cam2 / BL), not all 4. Security-relevant — a frozen ÉSZAK/DÉL pane could go unnoticed. Fix direction: per-pane IPC sockets or framebuffer-based per-quadrant staleness detection.

Backups

  • camwall-mpv.sh.bak-latency (2026-07-29 tiled low-latency rearchitecture)
  • camwall-mpv.sh.bak-2x2 (the 2×2 lavfi composite)
  • earlier: camwall-mpv.sh.bak-quad, camwall-mpv.sh.bak-relabel

Graph View

Backlinks