An HD surveillance server typically needs between 50 Mbps and several gigabits per second of network bandwidth, depending on the number of cameras, their resolution, frame rate, and compression format. A single 4K camera can consume anywhere from 8 Mbps to 25 Mbps on its own, so a large deployment with dozens or hundreds of cameras places enormous and sustained demand on network infrastructure. The sections below break down every factor that shapes that figure, from individual camera streams to full system design.
How much bandwidth does a single HD camera actually use?
A single HD camera typically consumes between 2 Mbps and 25 Mbps of network bandwidth, depending on its resolution, frame rate, compression codec, and scene complexity. A standard 1080p camera running H.264 at 25 frames per second will generally sit between 2 Mbps and 6 Mbps, while a 4K camera using older compression or operating in a high-motion scene can push well beyond 15 Mbps.
Resolution is the most obvious driver, but it is not the only one. The compression format in use makes an enormous practical difference. H.265 (HEVC) typically cuts bitrate roughly in half compared to H.264 at equivalent quality, and newer codecs like H.266 push efficiency further still. Scene complexity also matters: a static corridor with low lighting variation produces a far smaller data stream than a busy car park with constant movement, changing light conditions, and vehicles crossing the frame.
Frame rate compounds the effect. A camera running at 30 fps produces roughly 20% more data than the same camera at 25 fps. Dropping to 15 fps cuts bandwidth significantly but may not meet the motion clarity requirements for forensic or analytics purposes. Understanding this single-camera figure is the essential starting point for any IP camera bandwidth calculation.
What factors increase bandwidth demand on a surveillance server?
Beyond resolution and codec, several operational and environmental factors drive HD CCTV bandwidth higher than baseline estimates suggest. The most significant are scene motion, analytics processing, dual-stream configurations, and continuous versus event-based recording. Any deployment that relies on variable bitrate encoding will see bandwidth fluctuate substantially depending on what cameras are actually seeing.
Variable bitrate (VBR) encoding is standard across most modern IP cameras because it produces better image quality at lower average bitrates. However, it also means bandwidth is unpredictable. A camera that averages 4 Mbps in a quiet corridor may spike to 12 Mbps during a busy period. Network infrastructure and server ingestion capacity must be sized for peak demand, not average demand, to avoid dropped frames.
Analytics workloads add another layer of demand. When cameras or servers are running video analytics such as object detection, facial recognition, or licence plate reading, the system may need to retain higher-quality streams or process secondary streams alongside the primary recording. Dual-stream configurations, where cameras simultaneously transmit a high-resolution stream for recording and a lower-resolution stream for live viewing, also increase the total data volume the server must handle. Multicast transmission can reduce the network load for live viewing, but the recording stream remains a dedicated, sustained flow regardless.
How does the number of cameras affect total network bandwidth?
Total network bandwidth scales directly with camera count. If each camera averages 4 Mbps, a 50-camera system requires a sustained 200 Mbps of inbound bandwidth to the surveillance server. A 200-camera deployment at the same per-camera rate demands 800 Mbps, and a 500-camera enterprise system can easily require several gigabits per second of sustained throughput.
The key word is sustained. Unlike typical office IT traffic, which is bursty and irregular, HD surveillance generates a near-constant, high-throughput data stream every second of every day. This is why surveillance servers must be engineered for continuous sequential write workloads rather than the random read and write patterns that conventional enterprise IT hardware is optimised for. A server that performs well in a standard IT benchmark may degrade or drop frames under the relentless sequential load of a large camera estate.
Camera count also affects how traffic is distributed across the network. Large deployments typically segment cameras across multiple network switches and VLANs, with aggregated uplinks feeding the central recording server. Each aggregation point must have sufficient capacity to carry peak traffic from all cameras on that segment simultaneously. Failing to account for this at the network design stage is a common source of performance problems in large video surveillance network deployments.
What’s the difference between inbound and outbound bandwidth on a surveillance server?
Inbound bandwidth is the data flowing into the server from cameras, and outbound bandwidth is the data flowing out of the server to clients, operators, and remote sites. In a surveillance context, inbound demand is typically far higher and more sustained, because every camera streams continuously, while outbound traffic depends on how many operators are viewing live or recorded footage at any given time.
Inbound bandwidth must be sized for the full camera estate running simultaneously at peak bitrate. This figure is largely fixed by the system design and does not vary much day to day. Outbound bandwidth, by contrast, is more variable. A single operator pulling a live 4K stream may consume 15 Mbps of outbound capacity. Ten operators viewing simultaneously, combined with remote site access and video export requests, can push outbound demand into the hundreds of megabits per second on a large system.
Where surveillance servers connect to wide area networks for remote access or off-site redundancy, outbound bandwidth becomes a critical planning consideration. Replicating footage to a secondary site or providing remote operator access over a WAN link requires dedicated, guaranteed bandwidth rather than best-effort connectivity. Failing to separate and correctly size these two traffic flows is a frequent cause of live viewing degradation in otherwise well-specified systems.
How do you calculate bandwidth requirements for an HD surveillance deployment?
The standard approach to calculating surveillance server bandwidth requirements is to multiply the per-camera bitrate by the total camera count, then apply a headroom factor of at least 20 to 30 percent to account for peak traffic, analytics overhead, and future expansion. This gives a working figure for inbound network capacity. Outbound capacity is then calculated separately based on the number of concurrent operator streams and any remote access or replication requirements.
A practical calculation for a 100-camera deployment running 1080p H.265 at 25 fps might look like this:
- Estimated per-camera bitrate: 3 Mbps (H.265, moderate scene complexity)
- Total inbound load: 100 cameras x 3 Mbps = 300 Mbps
- Peak headroom (25%): 75 Mbps additional capacity
- Minimum server inbound capacity required: 375 Mbps
- Outbound for 10 concurrent operator streams at 3 Mbps each: 30 Mbps
This is a simplified model. Real deployments involve mixed camera types, variable scene complexity, analytics streams, and dual-stream configurations that make accurate calculation considerably more involved. Tools that simulate the actual network load before hardware is specified are far more reliable than rule-of-thumb estimates. Secure Logiq’s proprietary Logiqal Benchmark utility allows systems designers to virtually deploy an entire camera network, simulating exact resolutions, frame rates, compression formats, and analytics workloads to validate server and storage throughput before a single piece of hardware is installed.
What network infrastructure does a surveillance server need to perform reliably?
A surveillance server needs dedicated, high-capacity network infrastructure that is separated from general IT traffic, sized for peak sustained throughput rather than average load, and built with redundancy at every layer. At minimum, enterprise surveillance deployments should use gigabit connections per camera segment, with 10 GbE or higher uplinks between aggregation switches and the recording server.
Several infrastructure elements are non-negotiable for reliable video surveillance network performance:
- Managed switches with QoS: Quality of Service policies prioritise surveillance traffic over general data, preventing frame drops when the network is under load from other sources.
- Dedicated VLANs: Segmenting camera traffic onto its own VLAN isolates surveillance data from corporate IT traffic and simplifies security and troubleshooting.
- Redundant uplinks: Link aggregation or redundant paths between switches and the server eliminate single points of failure at the network layer.
- PoE switches with adequate power budgets: Cameras powered over Ethernet require switches with sufficient power headroom, particularly where PTZ cameras or cameras with built-in heaters are in use.
- UPS protection: Uninterruptible power supply coverage for switches and servers ensures recording continues through brief power events.
The server itself must match this infrastructure. A surveillance server with a single 1 GbE network interface becomes the bottleneck in any deployment exceeding roughly 150 to 200 cameras at typical bitrates. Enterprise-grade servers should provide multiple 10 GbE interfaces, allowing both camera ingestion and operator access traffic to flow without contention. Storage throughput must also keep pace with network ingestion, which is why surveillance-optimised servers use hardware RAID arrays built on drives rated for continuous 24/7 write workloads rather than standard desktop or light enterprise drives.
How Secure Logiq helps with HD surveillance network bandwidth planning
Secure Logiq designs and manufactures HD surveillance servers built specifically to handle the sustained, high-throughput network demands that generic IT hardware cannot reliably support. Key advantages for bandwidth-intensive deployments include:
- Logiqal Benchmark: A proprietary simulation tool that models the exact bandwidth and storage load of a proposed camera estate before any hardware is ordered, eliminating guesswork from system design.
- High-throughput server architecture: Every enterprise server ships with multiple 10 GbE interfaces, hardware RAID arrays of 24/7 surveillance-rated drives, and dual redundant power supplies as standard.
- Pre-sales design authority: Secure Logiq’s in-house engineering team analyses the full end-to-end architecture, identifies hidden bottlenecks, and delivers bandwidth and storage calculation reports ready for tender submission.
- VMS-certified hardware: All servers are tested and certified for leading platforms including Milestone XProtect, Genetec Security Center, and Avigilon Unity, ensuring the network and storage stack performs as specified within the chosen software environment.
If you are planning a new HD surveillance deployment or scaling an existing system and need accurate bandwidth calculations and hardware recommendations, contact the Secure Logiq team to speak with a specialist.