Specifying an IP Camera System That Won't Choke Your Network

Resolution should be set by what a reviewer needs to see at the farthest useful point in the frame, not by the highest number on the spec sheet. A common industry rule of thumb is pixel density: identifying a face typically calls for on the order of 40-80 pixels across the width of the face at the distance where identification matters, while simply detecting a person or vehicle needs far fewer pixels per foot. A 4K camera on too wide a lens can still leave license plates unreadable across a parking lot, while a 2MP camera on a tight lens over a doorway can resolve faces cleanly. Resolution and lens focal length are one decision, not two.

A wide lens covers more ground per camera but spreads pixels thinner across any one subject; a narrower, longer-focal-length lens concentrates pixels on a smaller area at greater distance. Fixed-focal cameras are simplest once mounting distance is settled; varifocal lenses give an installer room to adjust on-site when the exact distance isn't locked until the mount goes up. For long approaches, license-plate lanes, or perimeter fence lines, a narrower lens or a dedicated PTZ unit usually beats stepping up sensor resolution alone. Overlap coverage at handoff points — gates, hallway junctions, loading-dock aisles — and don't chase a uniform spec across the whole site: a lobby camera and a perimeter camera rarely carry the same evidentiary weight.

Every camera on the wire consumes bandwidth in proportion to its bitrate, not its resolution alone. A 4MP camera running H.265 at 15 fps on a static scene can produce a lower sustained bitrate than a 2MP camera running H.264 at 30 fps on a busy loading dock, because codec efficiency and scene motion move bitrate more than resolution does. Manufacturers publish typical bitrate ranges per resolution, frame rate, and codec combination — pull that figure for every camera model in the design, not one blended estimate, since a mixed-vendor or mixed-tier deployment rarely runs a single bitrate across the board.

Sum those per-camera bitrates and you have the aggregate load the network carries continuously, not just at peak — surveillance video is a constant stream, unlike bursty office traffic. That aggregate figure is what sizes the switch's uplink and, eventually, the NVR's ingest requirement. It's a different calculation from how much storage that same video consumes over a retention window; for the storage math specifically, our companion guide on video surveillance storage sizing picks up right where this one leaves off.

Every powered camera draws from a fixed pool: the switch's total PoE power budget, not just its per-port maximum. A switch can advertise PoE+ on every port and still fall short if its power supply can't feed all of them at once — vendors publish that ceiling as a separate total-wattage figure, and it's the number that actually caps how many cameras a given switch can power. Across the switch options on our catalog, total PoE budgets run from roughly 120-240W on compact 8-port edge units up to 400-600W on 48-port aggregation switches — the spread that decides whether a wiring closet needs one switch or three.

Match the standard to the device, not the other way around. A basic fixed camera typically runs fine on 802.3af (about 15.4W at the port); a PTZ camera, a heated outdoor housing, or a camera running onboard analytics usually needs 802.3at/PoE+ (about 30W); multi-sensor or high-power outdoor units can require 802.3bt. Add headroom rather than sizing to exact nameplate draw — cable runs near the 100-meter limit lose more power to resistance, and cold outdoor housings draw more at startup. Because powered devices carry no power of their own, back the PoE switch with a UPS if the cameras need to keep recording through a utility outage.

An access switch with plenty of open PoE ports can still be the bottleneck if its uplink to the core or the NVR wasn't sized for what those ports carry. Every camera streams continuously whether or not anyone is watching live, so the uplink has to move the summed load of all of them at once, not an average. Add up the sustained bitrate of every camera on a switch and compare it against the uplink — twenty-four 4MP cameras averaging 4 Mbps each push roughly 96 Mbps continuously, which a single 1GbE uplink absorbs easily, but an IDF aggregating several such switches toward the NVR can outgrow 1GbE fast enough that a 10GbE uplink or SFP+ trunk belongs in the design from the start, not as a retrofit.

Put camera traffic on its own VLAN, separate from user data and voice. That's not optional hygiene — cameras are a large population of unattended, infrequently patched network devices, and isolating them limits the blast radius of a compromised unit and keeps a firmware storm or a misbehaving camera from flooding anything else. It also simplifies quality-of-service: prioritizing video by VLAN protects stream quality without tagging every device individually. Confirm switch port counts against camera counts with room to grow — a design that fills every port on day one has no path to add a camera without a hardware change.

Channel count is the number most NVR quotes lead with, and it's necessary but not sufficient. A channel license covers one camera stream; buy enough to cover the current camera count plus a reasonable growth margin, since most NVR platforms sell licenses in fixed blocks and running out mid-project means a second purchase order, not a quick add. NVRs on our catalog span from 4-channel desktop units with a couple of drive bays up to 32-channel rack-mount appliances with far larger bay counts — the right tier is set by camera count today plus the zones most likely to grow.

Channel count alone doesn't guarantee the recorder can actually record every channel at its full designed bitrate. Ingest throughput — the sustained write bandwidth the recorder's network interface, backplane, and drives can absorb simultaneously — is a separate spec, and it's the one that gets skipped when a quote is built off channel count. Check the total bitrate calculated earlier against the NVR's rated ingest throughput, not just its channel maximum; an appliance licensed for 32 channels can still choke if every channel runs high-bitrate 4K at once. Redundant power and a second network interface are worth specifying on any NVR a site can't afford to lose.

ONVIF (Open Network Video Interface Forum) is an industry standard that defines how IP cameras, NVRs, and video management software (VMS) discover and talk to each other regardless of manufacturer — streaming setup, PTZ control, and event handling are covered by published ONVIF profiles, commonly Profile S for streaming, Profile T for advanced streaming and analytics, and Profile G for storage and recording. A camera that speaks ONVIF can be added to an ONVIF-conformant NVR or VMS from a different manufacturer without a proprietary integration; a camera that only speaks its own manufacturer's protocol locks the recording layer to that manufacturer for the life of the deployment.

This matters more at the recorder than at any individual camera, because the NVR or VMS is the layer that's hardest to replace once a site is live — it holds the configuration, the event rules, and often the storage. Specifying ONVIF conformance, and naming which profile the RFP needs, keeps a future camera refresh, brand consolidation, or VMS migration from turning into a full system replacement. It's a cheap line to add to a spec and an expensive gap to discover after award, when the only way to add a competing camera brand turns out to be replacing the recorder too.