Levandor

Camwall Lag Root Cause — Saturated 2.4 GHz Camera WiFi (Bufferbloat), Not a Player Problem

6 min read

The camera wall’s persistent “insanely delayed and laggy” panes are caused by a saturated 2.4 GHz camera WiFi channel (99% busy → bufferbloat), not by mpv, go2rtc, or the player pipeline. This is an RF/bandwidth capacity problem upstream of every player-side fix. It supersedes the earlier assumption — see Latency fix (2026-07-29) — 4 tiled single-input mpv instances — that camwall lag was an mpv movie= buffering / player-tuning issue. Verified 2026-07-31 on telep-mainframe and the OpenWrt router (telep-router, root@100.115.194.51).

For Agents

Verdict: camwall per-pane latency drift (up to ~12 s, worst on the DÉL/South left column) = bufferbloat on the 2.4 GHz telep-cc camera radio (phy1-ap1, ch 1, 20 MHz), which is 98.9% channel-busy, saturated by the cameras’ own uplink — 4 continuous full-HD Frigate record streams. No player-side change (mpv restart, go2rtc MSE/chromium rebuild) can fix this. The fixes are all upstream: get the cameras off 2.4 GHz WiFi (wire via Ethernet/PoE, or 5 GHz), or cut recording bandwidth. Changing WiFi channel will NOT help — it is self-congestion, noise floor is clean (-106 dBm).

Symptom

  • Camera-wall panes “insanely delayed and laggy” — worst on the DÉL/South camera (left column). Per-pane latency drift up to ~12 s.
  • Restarting mpv did not fix it. A full rebuild to a go2rtc MSE / chromium wall did not fix it either. That the delay survives a complete player swap is the tell: the bottleneck is upstream of the player.

Evidence chain

1. Ping — high latency, zero loss = bufferbloat (queueing), not a lossy link

From telep-mainframe to both cameras on the telep-cc camera WiFi (bridge br-cams):

CameraIPMACPing AVG RTTPeakJitter (mdev)Loss
DÉL / South (dual-lens Tapo)192.168.30.11918:69:45:a9:01:25350–420 msup to ~700 ms130–190 ms0%
ÉSZAK / North (dual-lens Tapo)192.168.30.139c0:3a:55:5c:8b:33350–420 msup to ~700 ms130–190 ms0%

A local camera on the same site should ping < 5 ms. High latency + huge jitter + 0% packet loss is the textbook signature of bufferbloat — packets are being queued under sustained load, not dropped on a bad link.

2. Channel survey — the 2.4 GHz camera radio is 98.9% busy, and it’s self-inflicted

On telep-router the camera SSID telep-cc is phy1-ap1 on 2.4 GHz channel 1, 20 MHz width (radio1 — consistent with WiFi).

iw ... survey dump on the in-use channel:

MetricValue
Channel busy time / active time26,960,546 / 27,263,522 = 98.9% busy
Channel receive time86% of active (AP receiving station uplink)
Noise floor-106 dBm (clean)

The saturation is the cameras' OWN uplink — not external interference

Noise floor is a clean -106 dBm and 86% of active time is the AP receiving. So the 99% busy channel is not some neighbouring network stomping on channel 1 — it is the two cameras’ own upstream video filling the air. Therefore changing the WiFi channel will NOT help — there is nothing to move away from; the congestion follows the cameras.

Station signal / link quality:

StationSignalNote
.119 (DÉL)-45 dBmgood signal
.139 (ÉSZAK)-68 dBmweak — plus tx retries present

Note the weak ÉSZAK link (-68 dBm) drives retransmits, which further eats airtime on the shared channel and drags both cameras’ latency down together.

3. Frigate stream roles — where the bandwidth comes from

/home/levander/nvr/frigate/config.yml: each of the 4 lens-streams runs:

  • sub → detect (5 fps, low bitrate), and
  • main → record (full HD, continuous 24/7).

So the air carries 4 continuous full-HD record streams + 4 sub detect streams, all over the one saturated 2.4 GHz channel. That sustained HD-record bandwidth is what pins the channel at 99% busy.

This contradicts the recording config documented in Recording

telep-mainframe still states record.retain.days: 0 — “events only, no 24/7 continuous recording”. The verified 2026-07-31 config shows main → record continuous 24/7 on all 4 streams. The recording posture changed; this note is the authoritative reading for the bandwidth analysis. (Update the mainframe doc’s Recording section when the intended posture is confirmed.)

Root cause

4 continuous HD record streams (Tapo main)
        │  all uplinking over ONE 2.4 GHz WiFi channel
        ▼
2.4 GHz telep-cc radio (phy1-ap1, ch1, 20 MHz) → 98.9% channel-busy
        │  no airtime left → packets queue instead of dropping
        ▼
Bufferbloat: 350–420 ms RTT, ~700 ms peaks, 0% loss
        │  arrives at go2rtc already hundreds of ms late & jittery
        ▼
Laggy / delayed camera-wall panes (up to ~12 s drift, worst on DÉL)

The delay is injected before the RTSP stream ever reaches go2rtc. go2rtc and mpv are downstream victims — which is exactly why swapping the player (mpv → go2rtc MSE/chromium) changed nothing.

Fix options (ranked)

  1. Get the cameras off 2.4 GHz WiFi. Best — eliminates the bottleneck.
    • Wire via Ethernet/PoE if the Tapo units have an RJ45 jack. Removes the shared-air contention entirely.
    • Or move the camera radio to 5 GHz if the cameras support it and range allows (5 GHz has far more airtime, but shorter range through walls).
  2. Reduce recording bandwidth. Record a lower-res / lower-bitrate stream instead of full-HD main, or lower the Tapo main-stream bitrate.
    • ⚠️ Camera-side changes are hard remotely on these units: the telep-cc VLAN has no internet and client isolation is on, so the Tapo app can’t reach them (Camera network). pytapo has no encoder/GOP setter, and ONVIF was flaky / only partially authing on these cameras. Budget for temporarily reopening the VLAN before planning this.
  3. Change the WiFi channel — WON’T help. Self-congestion; the noise floor is clean (-106 dBm). There is no interferer to move away from. Do not spend time here.

Separate, additive latency floor: the ~2 s substream keyframe/GOP interval

Independent of the bufferbloat, an earlier finding established the go2rtc substreams carry a ~2 s keyframe/GOP interval, which imposes an inherent ~2 s latency floor of its own. Even after the 2.4 GHz saturation is fixed, expect that ~2 s floor to remain until the GOP is shortened. The bufferbloat is what turns that ~2 s floor into ~12 s of drift.

Supersedes

This replaces the "camwall lag is an mpv/go2rtc tuning problem" assumption

The 2026-07-29 work (Latency fix (2026-07-29) — 4 tiled single-input mpv instances) correctly found that mpv’s single-composite movie= lavfi filtergraph was buffering, and splitting into 4 tiled single-input mpv instances did help. But that was not the whole story. The residual, wandering, multi-second per-pane lag that survived even a full player rebuild is the 2.4 GHz WiFi bufferbloat documented here — a capacity problem no player-side tuning can resolve.

Graph View

Backlinks