Bandwidth Calculator: How Much Do You Need?

Why Bandwidth Planning Matters

The most common reason IP surveillance systems underperform has nothing to do with the cameras. It has everything to do with the network. Inadequate bandwidth causes dropped frames, degraded video quality, recording gaps, and the kind of pixelated footage that is useless in an investigation. Yet bandwidth planning is routinely overlooked or treated as an afterthought by installers who focus on camera specs and ignore the pipe those cameras have to push data through.

This guide provides a systematic approach to calculating the bandwidth requirements for any IP camera deployment. Whether you are designing a 16-camera retail system or a 500-camera enterprise campus, the principles are the same. We will walk through the formula, break down the variables, compare codec efficiencies, and work through a complete real-world example. By the end of this article, you will be able to size your network infrastructure with confidence.

The Core Formula

Bandwidth calculation for IP surveillance boils down to a straightforward equation with four primary variables:

In practice, it is rarely this simple because most deployments have cameras at different resolutions, frame rates, and compression settings. The correct approach is to calculate the bandwidth for each group of identically-configured cameras, then sum them. This guide will walk through each variable in detail.

Resolution Breakdown

Resolution is the single largest determinant of bandwidth. Higher resolution means more pixels per frame, which means more data per frame, which means more bandwidth. The relationship is roughly linear: doubling the pixel count roughly doubles the bitrate, though compression algorithms introduce some non-linearity.

Here is a breakdown of the most common surveillance resolutions and their typical bitrates at standard settings (15fps, medium complexity scene, H.264 compression):

These figures assume a moderately complex scene (typical indoor or outdoor environment with some movement). Scenes with heavy motion (busy intersections, factory floors) will generate higher bitrates, while static scenes (stairwells, storage rooms) will generate lower bitrates, especially when variable bitrate (VBR) encoding is used.

Frame Rate Considerations

Frame rate has a nearly linear relationship with bandwidth. Doubling the frame rate roughly doubles the bandwidth. However, not every camera needs to run at the same frame rate. Smart frame rate allocation can dramatically reduce your overall bandwidth without meaningfully impacting security coverage.

A common optimization strategy is to configure cameras with dual streams. The primary stream records at full resolution and moderate frame rate (e.g., 4MP at 15fps) while the secondary (sub-stream) runs at lower resolution and frame rate (e.g., CIF at 5fps). The sub-stream is used for live monitoring on video walls and mobile clients, dramatically reducing the bandwidth consumed by operators viewing multiple cameras simultaneously. Only the primary stream is recorded to disk.

H.264 vs H.265: Compression Comparison

The choice of video compression codec is the second most impactful variable in bandwidth planning, after resolution. H.265 (also known as HEVC, High Efficiency Video Coding) is the successor to H.264 (AVC) and delivers approximately 30-50% better compression efficiency at equivalent visual quality.

In practical terms, this means a camera producing 8 Mbps with H.264 will produce approximately 4-5 Mbps with H.265 at the same resolution, frame rate, and perceived image quality. The savings are real and significant at scale. In a 100-camera system, switching from H.264 to H.265 can save 300-500 Mbps of aggregate bandwidth and reduce storage requirements by a corresponding 30-50%.

Continuous vs Motion-Based Recording

Recording mode has a significant impact on storage consumption but a more nuanced effect on bandwidth. With continuous recording, the camera streams at a constant bitrate 24/7, and the network must be designed to handle the full aggregate throughput at all times. With motion-based recording, the camera may stream a lower-quality sub-stream or even stop streaming entirely when no motion is detected, but will ramp up to full quality when triggered.

The critical design consideration is this: you must size your network for the worst-case scenario, not the average. If 64 cameras are configured for motion-based recording and a fire alarm causes everyone to evacuate simultaneously, all 64 cameras will trigger simultaneously and generate peak bandwidth. Your network must handle this scenario without packet loss. For this reason, Zimy recommends sizing the network as if all cameras are recording continuously, regardless of recording mode, and treating any motion-based savings as a bonus for storage, not a reduction in network capacity.

Bandwidth Per Camera: Comprehensive Reference Table

The following table provides bandwidth estimates per camera at various combinations of resolution, frame rate, and codec. These values represent typical bitrates for medium-complexity scenes using variable bitrate (VBR) encoding. Actual values will vary by manufacturer, scene content, and specific camera settings.

All values in Mbps. Green values indicate H.265 bitrates. Based on medium scene complexity with VBR encoding.

PoE Budget Calculation

Bandwidth is not the only network resource you need to plan for. Power over Ethernet (PoE) budget is equally critical, especially in large deployments where the aggregate power draw can exceed switch capacity. Every IP camera draws power from the network switch through the Ethernet cable. If your switch runs out of PoE budget, cameras will go offline regardless of how much bandwidth is available.

The IEEE 802.3af standard (PoE) provides up to 15.4W per port, with 12.95W available to the device after cable losses. The 802.3at standard (PoE+) provides up to 30W per port, with 25.5W available. The newer 802.3bt standard (PoE++) provides up to 60W (Type 3) or 100W (Type 4) per port for power-hungry devices like PTZ cameras and outdoor housings with heaters.

Switch Port Density Planning

Beyond bandwidth and PoE, you need to plan for physical port density. Each camera requires one Ethernet port on an access switch. Here is a simple planning methodology.

Start with your camera count per closet or IDF location. A standard 48-port PoE switch can serve up to 48 cameras, but in practice you should reserve 10-15% of ports for future expansion, spare connections, and access control devices (readers, controllers, intercoms). This means a 48-port switch effectively serves about 40 cameras.

For the uplink from each access switch to the aggregation or core switch, plan for at least a 1G uplink per 24 cameras at 1080p, or a 10G uplink per 24 cameras at 4K. In larger deployments, use 10G SFP+ uplinks throughout to avoid bottlenecks and future-proof the infrastructure. The cost difference between 1G and 10G SFP+ modules has dropped to the point where 10G is always the better long-term investment.

Uplink Capacity to NVR/Server

The uplink between your access switch stack and the recording server (NVR or VMS server) is the most common bottleneck in poorly designed surveillance networks. All camera traffic converges at this point, and if the uplink is saturated, you will see recording gaps and degraded live view quality.

The recording server's network interface must be sized to handle the aggregate incoming bitrate from all cameras it serves, plus a margin for live viewing sessions. If 64 cameras at an average of 5 Mbps each generate 320 Mbps of recording traffic, and you anticipate up to 16 simultaneous live view streams at 3 Mbps each (48 Mbps), the total requirement is approximately 370 Mbps. A single 1GbE NIC could handle this, but a bonded dual-NIC (2 Gbps aggregate) or a 10GbE NIC provides the recommended headroom.

Real-World Example: 64-Camera System

Let us walk through a complete bandwidth calculation for a mid-sized commercial deployment. The client is a retail distribution center with the following camera breakdown:

Based on this calculation, the 64-camera system requires approximately 307 Mbps of sustained network capacity. A single 1 GbE NIC on the recording server can handle this with margin, but we would recommend dual 1 GbE bonded NICs or a single 10 GbE NIC for future expansion headroom. Two 48-port PoE+ switches with 10G uplinks would provide the necessary port density and bandwidth.

Storage Calculation for This Example

While this guide focuses on bandwidth, it is worth extending our 64-camera example to storage. The recording aggregate of 236 Mbps translates to approximately 2.48 TB per day of continuous recording (236 Mbps x 86,400 seconds / 8 bits per byte / 1,000,000 MB per TB). For 30 days of retention, you would need approximately 74.4 TB of raw storage, or about 90 TB formatted with RAID overhead. Two enterprise storage servers with 8x 18TB drives in RAID 6 each would provide sufficient capacity with redundancy.

Common Mistakes to Avoid

Over the years, Zimy has audited hundreds of surveillance network designs from other integrators. These are the mistakes we see most frequently.

1. Not accounting for analytics streams. If you are running server-side video analytics (like Genetec KiwiVision or BriefCam), the analytics engine needs its own copy of the video stream. This effectively doubles the bandwidth for every camera being analyzed. Edge-based analytics (processing on the camera itself) avoid this problem.
2. Unicast vs. multicast confusion. By default, most VMS platforms request a separate unicast stream for every client viewing a camera. If five operators are watching the same camera, the camera sends five identical streams. Multicast streaming sends one stream that the network replicates at the switch level, dramatically reducing camera-side bandwidth. However, multicast requires proper IGMP snooping configuration on all switches.
3. Ignoring the sub-stream. Many installers configure cameras with only a primary stream and forget to set up the sub-stream. This means every live view session pulls the full-resolution stream, consuming maximum bandwidth even when the operator is viewing a 16-up mosaic where each tile is only 320x240 pixels on screen.
4. Flat network design. Running cameras on the same VLAN as office computers, VoIP phones, and printers is a recipe for unpredictable performance. A single large file transfer or backup job can saturate a shared uplink and cause camera streams to drop frames. Always use dedicated VLANs for surveillance traffic.
5. Undersizing uplinks. Even if each access switch port has sufficient bandwidth for individual cameras, the uplink to the distribution or core layer can become a bottleneck. A 48-port switch with 48 cameras at 5 Mbps each generates 240 Mbps of aggregate traffic. A single 1G uplink handles this, but add a second switch daisy-chained through the first, and the uplink is overwhelmed.
6. Forgetting about cable distance. Cat6 Ethernet is rated for 100 meters maximum. Beyond that distance, the signal degrades, causing packet loss that manifests as video artifacts and recording gaps. If cameras are more than 90 meters from the switch (leaving 10m margin), you need a PoE extender, a fiber media converter, or an IDF closet closer to the cameras.
7. No QoS configuration. Without Quality of Service policies, the network treats video traffic the same as email and web browsing. During periods of congestion, video packets are just as likely to be dropped as a non-critical download. Configure DSCP markings and priority queuing to ensure video traffic always gets priority.

Summary

Bandwidth planning is not optional for IP surveillance. It is foundational. An undersized network will cause more operational headaches than a wrong camera choice, because network problems affect every camera simultaneously. The good news is that the math is straightforward: calculate per-camera bitrates based on resolution, frame rate, and codec; sum them; add overhead; and size your infrastructure accordingly.

When in doubt, size up. The marginal cost of a 10G switch versus a 1G switch is trivial compared to the cost of re-cabling or experiencing recording failures after deployment. And always, always test your network under load before commissioning the system. A network stress test takes a few hours; discovering a bottleneck after the client moves in takes much longer to fix.