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

Описание и применение

Пошаговый процесс оценки пропускной способности для веб‑приложений с несколькими камерами, основанный на измерениях и ограничениях одновременного воспроизведения, который предотвращает перегрузку сети и помогает принимать обоснованные решения о закупке каналов.

Задача

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

Результат

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

Рабочий процесс

• 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).

Доказательства

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

Источник

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

Источник

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

Источник