A fast broadband plan can still leave a reviewer waiting for a clip. Start with the stream the service actually receives and the other work sharing the upload link.
Use your own assumptions · No signup
CCTV bandwidth calculator
Estimate simultaneous video traffic across the path you are sizing. Count only streams that cross it together.
Enter a stream count and bitrate to calculate. No site measurement has been supplied.
Video subtotal (Mb/s) = simultaneous streams × bitrate per stream. Planned rate = subtotal × (1 + allowance ÷ 100).
Inputs stay in this page; they are not sent or saved. This is planning arithmetic, not a connection test, drive recommendation or retention decision. Variable bitrate, overhead, reserved space, redundancy, competing traffic and system behavior need separate assessment. Calculator input limits are not equipment specifications.
The idea in view · Planning diagram
Size the traffic that actually leaves the site
- Crossing streams
- Bitrate and units
- Concurrent use
- Other upload traffic
- Representative measurement
- Task acceptance
Find the relevant stream
Ask whether the provider uses continuous streams, event clips or on-demand views. Record the configured bitrate, codec and frame rate for that path. A recorder’s local main stream may differ from the remote substream, and variable bitrate can rise with scene activity.
Calculate a transparent scenario
For simultaneous streams, add their measured megabits per second. For example, four assumed 2 Mbps streams total 8 Mbps before overhead and other site use. This is arithmetic for a fictional scenario, not a minimum NightMarshal requirement. Agree the headroom with the network team.
Test real contention
Observe upload use during busy operations and approved remote review. Check stalls, packet loss and clip arrival as well as speed. If uploads are event driven, test overlapping events rather than a single quiet clip.
Keep the calculation honest
Write down whether the bitrate is configured, measured or assumed. Four assumed 2 Mbps streams add to 8 Mbps before overhead; that arithmetic does not establish a safe line speed. Variable-rate video, protocol overhead and other traffic can change the demand. Keep any headroom decision with the network owner and provider rather than presenting a universal percentage.
For event-driven delivery, ask how the system handles bursts and retries. A single successful clip during a quiet afternoon says little about several views reporting at once. Use an authorized test and record the received result. Also identify the fallback if a stream cannot be delivered: local recording may continue, but remote review of that interval may still be unavailable.
Count the streams that cross the connection
Bandwidth planning starts with the service path. Identify which streams leave the site, their configured or observed bitrates, when they are active and which other transfers use the same connection. Local recording traffic may stay inside the site, while remote viewing, event clips and exports use the uplink. Do not add every camera's maximum bitrate to the internet requirement unless every stream actually crosses that connection in the scenario being assessed.
Separate normal operation from bursts. An event-based arrangement may send a different pattern of traffic from several simultaneous live views or a large evidence export. Record the assumptions and confirm them with the responsible system owner or provider. A connection that handles an empty-site demonstration may behave differently when ordinary business traffic and relevant camera activity occur together. The planning number is a starting point for measurement, not proof of service quality.
Use consistent units and an explicit margin
Network bitrates are commonly expressed in megabits per second, while file sizes may be expressed in megabytes or gigabytes. Eight bits make one byte, so confusing the units changes the calculation substantially. Keep the units beside each input. If four simultaneous streams are each configured at 2 Mb/s, their stated aggregate is 8 Mb/s before protocol overhead and other traffic. That example does not establish the required subscription for a particular site.
Choose any planning margin with the system owner and explain its purpose. Overhead, bitrate variation, other traffic and the desired operating headroom depend on the actual design. Avoid presenting one percentage as a universal camera requirement. Where bitrate is variable, inspect the behavior under representative movement and lighting rather than using one quiet snapshot as the upper bound. Keep the measured and configured values separate in the worksheet.
Test the upload path at the relevant time
Check the available upload and the camera service during the periods that matter to the duty. A download speed test or the broadband package name does not establish usable upload. If the site shares connectivity with backups or other business systems, include those conditions in the assessment. Record when and where a measurement was made so another person can interpret it later.
If remote video is poor, compare local playback, the site uplink and the remote receiving path. Changing camera settings may reduce demand, but it can also reduce useful detail or affect recording. Test the intended task after a change. Where the provider requires a particular integration or transport, confirm the supported design with it and the administrator rather than opening access paths or disabling protections as a troubleshooting shortcut.
Separate sustained viewing from a short clip transfer
A continuous stream is a rate over time; a clip is a quantity that must be transferred through the available path. For a simple fictional baseline, a 20 MB file contains 160 megabits. At a steady 4 Mb/s of usable transfer capacity, the arithmetic alone gives 40 seconds. That does not include setup, competing traffic, protocol behavior or other delays and is not a promised clip-delivery time.
The distinction helps explain why a connection can support an occasional live view yet take longer than expected to retrieve several event clips together. It also shows why a package's maximum advertised speed does not settle the review experience. Ask which transfers occur at the same time, what capacity is actually available and whether the provider's workflow needs the whole clip before a decision can be made.
Keep these scenarios separate in the sheet. Record sustained stream demand, representative bursts and the observed service result under relevant load. If a design depends on changing stream quality or transfer behavior, retest useful detail and event context as well as traffic. The arithmetic supplies a transparent assumption; the task test establishes what the site can rely on.
A fictional four-camera planning exercise
A warehouse proposes four simultaneous remote views at 2 Mb/s each. The worksheet records 8 Mb/s of stated video traffic and marks overhead, competing traffic and burst behavior for review. During an evening test, a business backup overlaps the viewing period and remote playback buffers. The camera total alone has not explained the connection's full workload.
The team compares the same views locally, measures the relevant uplink period and checks the service path with IT. It might schedule unrelated transfers differently, assess a different supported stream or revise the network design. Each change needs a video-task retest; the cheapest bitrate is not useful if movement becomes unreadable. The final acceptance record identifies the tested configuration and dependencies. It does not claim that every connection with an advertised speed above 8 Mb/s will work.
Make the call
Which load are you estimating?
| Situation | Decision to make | What to ask for |
|---|---|---|
| Continuous remote streams | How many run simultaneously | Configured or measured bitrate per stream |
| Event clips sent on activity | What happens when events overlap | Clip arrival tests under a stated concurrency |
| Backups share the uplink | Whether capacity is available when needed | Busy-period monitoring and IT review |
Before you move on
- Confirm the delivery model and stream settings.
- Calculate simultaneous upload demand in Mbps.
- Test under ordinary business load and record the outcome.
A worksheet you can actually use
Start with the blank sheet. Add one row per item, assign an owner and mark anything unresolved as pending. The completed example shows the level of detail to aim for.
Keep completed security plans private. Use aliases; keep passwords, access codes, personal contacts and footage links in your approved systems.
How to fill the worksheet
- View group
- Group only streams that share the relevant path and operating assumptions, keeping local-only traffic distinguishable.
- Simultaneous streams
- Record how many streams actually cross the connection together in the stated scenario, not simply the total camera count.
- Assumed Mbps each
- Keep megabits per second explicit and distinguish configured assumptions from measurements under representative activity.
- Subtotal Mbps
- Calculate the stated aggregate and retain the inputs. The video subtotal does not include every overhead or other dependency.
- Other load
- Identify business uploads, exports and other relevant concurrent traffic without guessing their demand as a fixed universal percentage.
- Test result
- Record the period, observed service behavior and accepted configuration. A subscription headline is not a performance test.
A worked example
Fictional network: four 2 Mbps streams require 8 Mbps before overhead. A nominally faster connection still stalls when backups run, so IT schedules and retests competing uploads.
| View group | Simultaneous streams | Assumed Mbps each | Subtotal Mbps | Other load | Test result |
|---|---|---|---|---|---|
| Gate group | 4 | 2 | 8 | To measure | Pending |
Questions readers bring to this task
What else should you know?
Can we lower the bitrate to make the connection work?
Possibly, with the installer’s guidance. Verify that the resulting view still supports the required task and that the provider receives usable detail. If reducing bitrate removes the detail needed for review, the connection problem has merely become a coverage problem.
Link to this answer ↗Is download speed the main number for remote cameras?
For video leaving a site, upload is a relevant constraint, but the full path also includes local networking, receiving systems and the supported integration. Do not diagnose from one headline speed. Compare the actual traffic path and measure under representative conditions.
Link to this answer ↗Can reducing bitrate solve buffering?
It may reduce traffic, but the fault may be elsewhere and lower bitrate can change useful image detail. Locate the bottleneck, make a controlled supported change and retest the monitoring task. Keep a record of the prior setting and the observed result.
Link to this answer ↗Does every camera stream need to leave the site continuously?
That depends on the accepted architecture and review model. Some arrangements send selected streams or event material; others require scheduled live viewing. Confirm the actual path with the provider and system owner before sizing the connection or assuming a saving.
Link to this answer ↗Notes & sources
Bitrate and overhead vary by equipment, scene and design. Confirm requirements during technical assessment; this is not a guaranteed connection specification.
Reviewed October 27, 2026. The examples and worksheets are planning aids, not customer results or a statement of contracted service.
- SCW: professional camera monitoring
Provider description of alert review and scoped response. Its offer is not a NightMarshal commitment.
- GOV.UK: police requirements for CCTV systems
Purpose, quality, storage, export and playback considerations; not a promise of police response.