I stopped answering “how many Mbps do we need?” with a number

Description and use

A step‑by‑step bandwidth estimation process for multi‑camera web apps, based on measurements and concurrency limits, that prevents network overload and informs circuit procurement decisions.

Problem

Estimating bandwidth for multi‑camera web apps is hard; naive Mbps SLAs mislead and can cause outages.

Outcome

A systematic, data‑driven bandwidth estimation workflow that prevents over‑provisioning, avoids outages, and informs circuit procurement and design decisions.

Workflow

• 1. Define two budgets: downlink and uplink, using measured B_tile and B_encode values. 2. Write helper functions (e.g., estimateDownlink) that compute required bandwidth from N_play, B_main, B_sub, overhead, and headroom. 3. Implement a concurrency model with requestLive/releaseLive to enforce a maximum number of live streams. 4. Create test matrices in staging: varying N_play, recording, talk, concurrent users, and mobile throttling. 5. Capture and log bytesReceived, firmware, profile, fps, and site uplink usage. 6. Review results, adjust caps, and document in a spreadsheet. 7. Communicate findings in architecture reviews, refusing “play all” if caps are exceeded or metrics unknown. 8. Use query flags to drive automated page loads and log metrics. 9. Reject PRs that add live tiles without passing through requestLive or that set hardcoded bitrate defaults. 10. Map platform APIs (Imou Open Platform) to understand additional bandwidth contributors (playback, PTZ, recording, talk).

Evidence

I keep overhead and headroom as named placeholders in the PR until we replace them with a capture from the target network.

Source

I refuse “play all” if requestLive would exceed the cap or if B_main was never measured.

Source

I drive one page with query flags: ?tiles=1&profile=sub, ?tiles=4&main=1, ?talk=1.

Source