The first time I chased “the stream is slow,” I blamed the player

Description and use

Implemented a systematic latency measurement workflow that isolates each hop, reduces unnecessary player changes, and improves ticket clarity, leading to more efficient debugging and targeted optimizations.

Problem

Latency in IP camera streaming was attributed to the player, but the root cause lay elsewhere.

Outcome

Implemented a systematic latency measurement workflow that isolates each hop, reduces unnecessary player changes, and improves ticket clarity, leading to more efficient debugging and targeted optimizations.

Workflow

• 1. Capture glass‑to‑glass latency with a phone stopwatch during live view.
• 2. Log time‑to‑first‑frame (ttf_ms) via JavaScript performance.now().
• 3. Compare stopwatch and ttf_ms; trust stopwatch for operations, ttf for regressions.
• 4. Inspect hops: encode (GOP), ingest/site (LAN vs remote), process (transcoding), transport (segment duration, playlist size), player (buffer, decoders), client CPU (tile count).
• 5. Check network metrics: Wi‑Fi retries, RSSI, VPN path, cellular handoff, packet loss.
• 6. Run browser/player diagnostics checklist (instances alive, live mode, main/sub stream, hidden tab, extensions, hardware decode).
• 7. Teardown unused player instances in React useEffect cleanup to prevent leaks.
• 8. Decide when to stop optimization: casual grid with uplink latency acceptable; focus on operator‑centric streams (talk/PTZ).
• 9. Create detailed ticket with camera ID, firmware, network, tiles, profile, ttf_ms, stopwatch_s, players_alive_after_nav.
• 10. Separate “late first frame” from “late steady state” in analysis.
• 11. Prefer reconnect over buffer on mobile; show reconnecting chip to operators.
• 12. Adjust player settings only when necessary (muted start, destroy on unmount, buffer based on stall‑rate).
• 13. Avoid changing GOP via JS or setting zero buffer without evidence.
• 14. Log SDK exposed liveLatency or buffered ranges alongside stopwatch.
• 15. Use Imou Open Platform APIs/SDKs for playback, PTZ, etc., but gate advanced features to measured live tile.
• 16. Attach test matrix to any latency claim in PRs.
• 17. Review code to ensure no latency numbers without test matrix.
• 18. Iterate measurement when site reports worsening latency before reverting frontend commits.

Evidence

I put a phone stopwatch in the frame. I start live view. I subtract. That is glass-to-glass for this device, this Wi‑Fi, this browser, this tile count.

Source

I never write “we are under 500 ms” in a ticket. I write the five numbers from the last test matrix.

Source