A multi-site retailer we worked with once had every camera at one location go dark for six minutes during a break-in, not because the hardware failed, but because nobody sized the network to carry that many simultaneous streams. By the time IT noticed the gap, the footage that mattered was already gone.

Security camera bandwidth planning isn't optional homework. It's the difference between a system that actually catches what it's supposed to and one that quietly drops the footage you need most. Six factors determine how much bandwidth your cameras really need, and this piece maps all six to real network decisions, from switch selection to storage architecture.

Why Security Camera Bandwidth Planning Matters

For most IT teams, a bandwidth problem doesn't look like one at first. It looks like buffering on the live view, a delayed alert, or a recording that seems to skip a few seconds. By the time it's obvious something's wrong, you're usually looking at packet loss, jitter, or degraded video across several cameras at once, not just one.

The stakes get higher once you factor in what bandwidth controls. It doesn't just affect how smooth your live view looks; it drives your storage capacity math for whatever retention period you're required to hit. Underestimate bandwidth, and you get less footage than you planned for, a much harder problem to catch before it costs you.

The Six Factors That Drive Security Camera Bandwidth

Camera bandwidth isn't one number you look up once and forget. It's the product of six variables working together: video compression, image quality and bitrate mode, scene complexity, video resolution, frame rate, and the number of cameras and viewing clients on your network.

The first two, compression and image quality, are really about the same lever: how hard the camera works to keep quality up without bloating the stream. The other four are more straightforward multipliers. We'll walk through both groups below.

Compression and Image Quality

Every IP camera compresses video before it hits your network. Raw footage from a single 1080p camera at 30 frames per second would need roughly 1.5 Gbit/s, more than any realistic network could carry at scale. The codec and bitrate mode you choose determine how much of that raw data actually gets sent.

• MJPEG: Compresses each frame independently. Simple to decode, but can use roughly 10 times the bandwidth of H.264 for the same footage.
• H.264: The current baseline standard. Stores full frames (I-frames) at intervals and encodes only the differences between them, balancing quality against bandwidth.
• H.265 (HEVC): 25 to 50% more efficient than H.264 at the same visual quality, though it needs newer hardware to run.
• Variable bitrate (VBR): Holds image quality steady and allows bandwidth to fluctuate. Best when your LAN and storage have headroom to spare.
• Constant bitrate (CBR): Holds bandwidth steady and lets quality flex instead. Useful with a hard bandwidth ceiling.

Resolution, Frame Rate, and Camera Count

Three more variables multiply bandwidth in ways that are easy to underestimate until you add them up. Each is simple on its own, but they compound quickly once you're planning a real deployment rather than a single test camera.

• Resolution: More pixels means more bandwidth, proportionally. Jumping from 640x480 to 1920x1080 multiplies raw data roughly 6 times before compression.
• Frame rate: Smoother video costs more bandwidth, but the relationship isn't linear. Cutting frame rate in half doesn't cut bandwidth in half, since compression efficiency drops too.
• Number of cameras: Bandwidth scales directly with camera count when cameras are equivalent, before you even get to viewing traffic.
• Number of viewing clients: Live and playback viewers pull bandwidth on the recorder-to-client side, separate from the camera-to-recorder side, and can become the bigger bottleneck.

Estimating Your Network's Bandwidth Requirements

Once you know the variables, turn them into a number for your network. Start simple: multiply each camera's expected bitrate — a 1080p camera at a moderate frame rate typically runs 2 to 4 Mbit/s with H.264 — by your camera count, for a rough total.

That number shifts depending on how you record. Continuous recording gives a predictable, steady load, but eats storage fast. Event-based recording, triggered by motion or another sensor, saves storage significantly, but its bandwidth is harder to predict since you're estimating event frequency, not a constant stream.

No bitrate table or calculator, including ours, gives an exact number. Scene complexity, lighting, and compression settings all shift the real figure. This is the same approach Hummingbird Networks recommends before finalizing any multi-site camera infrastructure: pilot a small number of cameras on-site, review the actual bandwidth usage, and adjust before you commit to hardware.

• At a glance: Continuous recording provides predictable bandwidth but requires more storage; event-based recording saves storage but makes bandwidth harder to predict in advance.

Where Bandwidth Bottlenecks Happen

Even a well-estimated camera network won't perform if there's a chokepoint somewhere between the camera and the viewer. Bottlenecks can show up at almost any aggregation point: the edge switch uplink, the core switch, or the connection to the internet.

The fix is nearly always the same principle, regardless of where the bottleneck shows up: keep actual throughput to 50 to 70% of a link's rated capacity, not 100%. The two environments you're planning for, your own local network and everything routed over the internet, behave differently enough to walk through separately.

Local Network (LAN) Bottlenecks

The most common chokepoint is an edge switch aggregating many camera feeds onto a single uplink. A Fast Ethernet 100 Mbit/s uplink gets overloaded fast: even a few dozen cameras at a few Mbit/s each will exceed it.

This is why Gigabit uplinks on both edge and core switches are standard beyond a small deployment. It's a straightforward upgrade that buys headroom for the cameras you'll add later, not just the ones you're planning for today.

Remote and Internet-Based Viewing

Internet bandwidth behaves differently than your LAN. It's less predictable and carries higher latency, which is exactly why recording directly over the internet isn't recommended. Always place your recorder on the same local network as your cameras.

Remote viewing is a lower-risk use of internet bandwidth by comparison. A dropped frame during live viewing doesn't lose footage, since the recorder already captured it locally regardless of what the viewer sees.

Network Best Practices for Multi-Site Camera Deployments

A few architecture decisions up front prevent most of these problems, and two matter more than the rest: keeping camera traffic separate from business traffic, and sizing switches correctly from day one instead of retrofitting later.

These are the two most common gaps Hummingbird Networks sees when a multi-site camera network chokes after rollout. Start with traffic separation, since it affects both performance and security.

Segment Camera Traffic From Business Traffic

Camera traffic and business traffic competing for the same resources is a common, avoidable problem. Separating them protects both sides: business applications don't slow down during a camera traffic spike, and cameras aren't starved for bandwidth by whatever else is happening on the network.

• Dedicated switch: The cleanest separation. Camera bandwidth never competes with business traffic because it's on its own hardware.
• VLANs: A practical fallback when a dedicated switch isn't in the budget. Splits one physical switch into isolated virtual networks.
• Security benefit: Segmentation limits the blast radius if a camera's firmware is ever compromised, since it can't reach the business network directly.

Choose Switches Sized for Camera Traffic

Switch sizing follows a few consistent rules regardless of vendor. Get these right at the planning stage and avoid a forklift upgrade eighteen months in, once you've added the cameras you always meant to add.

• Fast Ethernet (100 Mbit/s) ports: Generally sufficient for individual camera connections, which don't typically need more.
• Uplink ports: Need to support the sum of all incoming camera traffic, which is why Gigabit uplinks are standard beyond a handful of cameras.
• Capacity headroom: Plan for 50 to 70% of rated capacity as usable throughput, not 100%, for spikes and future growth.

How Meraki MV Simplifies Bandwidth Planning

Some of this planning burden shifts depending on the camera platform. Meraki MV's on-camera SSD storage model, sometimes called cloud-augmented edge storage, changes the bandwidth math in your favor: instead of streaming continuous full-resolution video upstream, the camera stores footage locally and transmits mostly metadata and alerts by default.

That reduces the uplink sizing problem considerably, since your network isn't carrying the full weight of every camera's stream. As a Cisco Meraki partner, Hummingbird Networks configures MV deployments across multi-site networks regularly, and this storage model is usually why we recommend it for bandwidth-constrained sites. 

If you're still deciding between platforms, our comparison of the best cloud-based security cameras breaks down how Meraki MV stacks up against Verkada, Avigilon Alta, and a few other options.

Plan Your Camera Network the Right Way

Bandwidth planning is solvable. Get traffic segmentation, switch sizing, and platform choice right up front, and run a short pilot before you commit to hardware. Once you've sized your network, browse our security camera lineup to see what fits.

Hummingbird Networks has spent over 20 years helping multi-site teams size networks like this correctly the first time.

Not sure your network can handle the load? Contact us, and we'll help you plan it out.