Bandwidth Calculation

The bandwidth a link needs is about the number of cameras × the bitrate per camera × 1.3, where 1.3 is a 30% margin for live viewing and bitrate peaks, the same margin the KDT website calculator uses. For example, 16 cameras of 4 MP with H.265 at 25 fps need about 3 Mbps each: 16 × 3 = 48 Mbps, and 48 × 1.3 = 62.4 Mbps with the margin, which a 100 Mbps link can carry. The same 16 cameras with H.264 need about 6 Mbps each, so 96 Mbps, or 124.8 Mbps with the margin, which calls for a gigabit link. Do this calculation separately for every link on the path: the switch uplinks, the port and incoming bandwidth of the recorder (NVR) and, for remote viewing, the site's internet upload speed.

Open the storage calculator in the After-sales services section of the KDT website (/after-sales/storage-calculator); besides disk space, it estimates network bandwidth. For each group of similar cameras, enter the number, resolution, codec, frame rate and scene activity to see the bitrate of each camera and group and, under “Total bitrate (network bandwidth)”, the overall total. The page also tells you whether a 100 Mbps link is enough, a gigabit link is needed, or several recorders or a 10 Gbps link are required; this advice already includes the 30% margin, and the recording hours and retention days do not affect it. The calculator counts one stream per camera, so add sub-streams, remote viewers and any other traffic on the same links yourself, and if you want KDT's experts to review the result, send them the link from the “Copy link” button.

Bitrate is the amount of data per second in one stream, for example 4 Mbps for one camera; bandwidth is the capacity of a link or device to carry data, for example 100 Mbps or 1 Gbps; and throughput is the speed actually measured in practice, after overhead and network conditions, which is always lower than the nominal rate. Designing means making sure that the bitrates of all the streams crossing a link, plus a margin, stay below its real throughput. Ethernet is full duplex: a gigabit link carries 1 Gbps in each direction, and the recording traffic of cameras flows mostly one way (from the camera to the NVR), so count that direction.

The reference values of the KDT website's calculator, for one camera at 25 fps with medium scene activity and H.264, are about 2 Mbps for 1 megapixel (720p), 4 Mbps for 2 megapixels (1080p), 6 Mbps for 4 megapixels, 8 Mbps for 5 megapixels and 12 Mbps for 8 megapixels (4K). With H.265 these become about half (1, 2, 3, 4 and 6 Mbps), and with a smart codec such as H.265+ about 0.3 times the H.264 figure. The calculator scales the bitrate by the frame rate divided by 25 to the power of 0.85, so 15 fps needs about 65% and 30 fps about 117% of the 25 fps bitrate, and it multiplies busy scenes by 1.5 and quiet ones by 0.6. These are planning figures; for an installed system, read the actual values from the camera or recorder settings.

Network speeds are given in bits per second (lower-case b, as in Mbps), while file sizes and download managers use bytes (upper-case B, as in MB/s), and one byte is 8 bits, so divide Mbps by 8 to get MB/s. A 20 Mbps internet connection therefore downloads at most 2.5 MB/s, a 100 Mbps link 12.5 MB/s and a gigabit link 125 MB/s. In practice protocol headers take a few percent, so a file copy over gigabit Ethernet reaches roughly 110 to 118 MB/s at best. Network units are also decimal (1 Mbps = 1,000,000 bits per second), so a camera bitrate of 4096 Kbps is 4.096 Mbps.

No. That line is the range within which the bitrate can be set (several 6 and 8 megapixel models in the KDT datasheets list 11 Kbps to 16 Mbps, and many 4 and 5 megapixel models 11 Kbps to 10 Mbps), not what the camera actually sends. The real traffic is the bitrate configured for each stream: the fixed value in CBR mode, or anything up to the configured maximum in VBR mode. Plan the network with the values you will actually set, but if the cameras are left at a high maximum, the network has to carry that maximum from all of them at the same time.

At similar image quality, H.265 typically needs 30 to 50% less bitrate than H.264, and the KDT website's calculator takes it as half; smart codecs (listed as H.264+ and H.265+ in KDT camera datasheets) lower the average further, which the calculator models as 0.3 times the H.264 bitrate. Example: 24 cameras of 2 megapixels need 24 × 4 = 96 Mbps with H.264, or 124.8 Mbps with the 30% margin, more than a 100 Mbps link can carry, but only 48 Mbps (62.4 Mbps with the margin) with H.265. The saving of a smart codec is mainly in the average: when the scene gets busy, the bitrate climbs back towards the configured maximum, so size network links for that maximum rather than for the average. The saving only applies if the camera, the recorder and the viewing software or app all support the codec.

With CBR the camera sends a nearly constant bitrate, so the network load is predictable but image quality drops when the scene gets complex; with VBR the bitrate follows the scene up to the maximum you set, so the average is lower but the peaks reach that maximum. For bandwidth, always plan with the VBR maximum, because peaks coincide: at night, image noise raises the bitrate of all the cameras together. For example, 16 cameras with a 4 Mbps VBR cap may average only 2 Mbps each, but the uplink must be sized for 16 × 4 = 64 Mbps, or 83.2 Mbps with the 30% margin. As a starting cap, use about the typical value for the resolution (for example 3 Mbps for 4 MP with H.265) and up to 1.5 times that for busy scenes; raise it if the night image or moving objects turn blocky.

The main stream has the full resolution and is used for recording and for viewing one camera full screen; the sub-stream is a low-resolution copy, typically about 0.25 to 1 Mbps, made for split-screen views and mobile apps, and KDT datasheets state the number of streams per camera, usually Dual Stream or Triple Stream. A split view should use sub-streams, because each tile is small anyway: 16 tiles on the main streams of 4 MP H.265 cameras need 16 × 3 = 48 Mbps, but only 16 × 0.5 = 8 Mbps on sub-streams. Set the NVR, the VMS software or the mobile app to show sub-streams in multi-camera views and to switch to the main stream only when one camera is opened full screen. If the recorder also pulls the sub-streams for its preview, count them on the links between the cameras and the recorder as well.

An I-frame is a complete picture and is many times larger than the P-frames between two I-frames, which carry only the changes; the shorter the interval, the higher the average bitrate. It is commonly set to about one to two times the frame rate, for example 25 to 50 at 25 fps, and smart codecs lengthen it automatically in static scenes. A longer interval saves bandwidth, but after a lost packet the picture takes longer to recover and playback can only jump to I-frames, so avoid very long intervals on networks that lose packets, such as wireless links. I-frames also send short bursts above the average bitrate, one more reason to keep headroom on every link.

Not exactly: the bitrate is only the video data, and the RTP, UDP or TCP, IP and Ethernet headers add roughly 4 to 8% on the cable. Audio with G.711 adds about 64 kbps plus its headers, and every other stream the camera sends, such as a sub-stream for the recorder's preview, is extra traffic. Each client that connects directly to the camera by unicast also receives its own copy, so three viewers of the same camera triple the traffic on that camera's port. The 30% margin of the KDT website's calculator covers the headers and ordinary peaks, but extra streams and viewers have to be added to the calculation separately.

Usually not: in most systems the camera keeps streaming to the recorder around the clock, because the recorder needs the live stream for live view, for detecting events and for the pre-record buffer, so motion, event or scheduled recording saves disk space but not network bandwidth. That is why the KDT website's calculator uses the recording hours only for storage and bases its network-link advice on the total bitrate alone. Traffic really drops only when streams are stopped, for example when a camera records to its own memory card and is viewed only on demand, or when some VMS software is set to pull a stream only while someone is watching or an event is being recorded.

The KDT website's calculator uses 30%: a link counts as enough when the total bitrate × 1.3 fits in it, which means loading a 100 Mbps link with at most about 77 Mbps and a gigabit link with about 769 Mbps. This margin covers VBR peaks, the short bursts of I-frames, protocol headers and ordinary live viewing. Leave more where the link also carries other traffic, such as office computers, or where it is wireless, where it is better to use no more than about half of the throughput you actually measure. Also count the cameras you expect to add in the next few years, because replacing backbone links later usually costs more than sizing them correctly now.

The most effective measures are: use H.265 or a smart codec (H.265+) instead of H.264; lower the resolution of cameras that do not need fine detail (in the KDT website calculator's model, a 2 MP camera needs about a third of the bitrate of an 8 MP one); lower the frame rate of less critical cameras (15 fps instead of 25 fps saves about 35%); and set a suitable bitrate cap. For example, 16 cameras of 4 MP with H.264 at 25 fps need 96 Mbps; with H.265 that drops to 48 Mbps, and at 15 fps to about 31 Mbps. Use sub-streams in multi-camera views and multicast when many people watch the same camera. Check every change on the night image and on moving scenes, because cutting the bitrate too far ruins the picture.

Divide the usable capacity by the bitrate per camera: with the 30% margin of the KDT website's calculator, a 100 Mbps link can take about 77 Mbps and a gigabit link about 769 Mbps. With 4 megapixel H.265 cameras at about 3 Mbps that is 25 cameras on a 100 Mbps link and 256 on a gigabit link; with 4 megapixel H.264 or 4K H.265 cameras at about 6 Mbps it is 12 and 128. On a gigabit link to an NVR, the real limit is often the recorder's own incoming bandwidth, which is usually lower than its gigabit port. Before choosing, add sub-streams, remote viewers and future cameras, and use the VBR maximum rather than the average.

Yes: one camera stream is only a few Mbps, and even the 16 Mbps maximum listed in the datasheets of most KDT IP cameras is far below 100 Mbps; those datasheets also list a 10/100 Mbps Ethernet port on the camera itself. The bottleneck is the uplink, where the streams of all the cameras add up: 24 cameras at 6 Mbps make 144 Mbps, or 187.2 Mbps with the 30% margin, more than a 100 Mbps uplink can carry. That is why PoE camera switches often combine 100 Mbps camera ports with gigabit uplinks, for example KDT's KP-2407H3SFT with 24 Fast Ethernet PoE ports, three gigabit RJ45 uplinks and three gigabit SFP uplinks. Connect the uplink to a gigabit port on the next switch or the recorder, and check that the link really came up at 1000 Mbps.

You can, but each link in the chain carries the traffic of every camera behind it, and the link nearest the recorder carries the total. For example, three switches in a row with 16 cameras each at 6 Mbps put 3 × 16 × 6 = 288 Mbps on the last link, or 374.4 Mbps with the 30% margin, so it must be gigabit. Every extra switch is also one more point of failure that disconnects all the cameras behind it, so a star layout, with a separate gigabit (or fiber) uplink from each access switch to a core switch next to the recorder, spreads the load and is easier to troubleshoot. Do not compare the total with the switching capacity in the datasheet (for example 128 Gbps for a switch with 24 gigabit ports and four 10 Gbps uplinks): all the camera traffic leaves through the one uplink port, and that port's speed is the real limit.

Every NVR has a maximum incoming (recording) bandwidth, given in its datasheet as Input Bandwidth and usually lower than its gigabit network port: in the datasheets of KDT 4K NVRs it is 40 Mbps for 4-channel, 80 Mbps for 8-channel, 160 Mbps for 16-channel and 256 Mbps for 32-channel models, 1024 Mbps, or 512 Mbps with RAID enabled, for the 8K models, and 320 to 500 Mbps with smart bandwidth management, or 200 Mbps with RAID, for the 64-channel 4K models. For example, a 16-channel NVR with a 160 Mbps limit accepts 16 cameras at 4K with H.265 at about 6 Mbps each (96 Mbps in total), but not with H.264 at about 12 Mbps each (192 Mbps). When the total is exceeded, depending on the model, the recorder refuses to add the channel, reports insufficient bandwidth or drops frames. Add up the recorded streams of all channels at their VBR caps and keep the total under the Input Bandwidth; enabling RAID may lower this limit.

It is the maximum total the recorder can send to its clients at once: live view and playback in the VMS software, the web interface and mobile apps, and downloads of recordings. In KDT datasheets it ranges from 80 Mbps on entry-level models to 256 Mbps on many 16- and 32-channel 4K models and 800 Mbps (400 Mbps with RAID enabled) on the 8K models. Four operators each watching 16 cameras on 0.5 Mbps sub-streams use 4 × 16 × 0.5 = 32 Mbps, but if each opens the 3 Mbps main streams the total becomes 4 × 16 × 3 = 192 Mbps, more than 80 Mbps. Keep operators on sub-streams in split views; on a full-duplex gigabit port this outgoing traffic does not take capacity from the incoming camera streams, but it is still limited by the recorder's Output Bandwidth.

When the total bitrate × 1.3 is more than 1000 Mbps, which is where the KDT website calculator advises several recorders or a 10 Gbps link. For example, 200 4K cameras with H.265 at about 6 Mbps make 1200 Mbps, or 1560 Mbps with the margin: connect the access switches to the core over 10 Gbps uplinks, for example on a switch like KDT's KP-4806H5SM3 with 48 gigabit PoE ports and six 10 Gbps SFP+ uplinks, and split the cameras among recorders whose incoming bandwidth covers their share. Link aggregation (LACP, IEEE 802.1AX, formerly 802.3ad) of several gigabit ports also adds capacity, but it spreads different streams over the member links, so no single stream can use more than one link. Use fiber for backbone runs longer than the 100 m limit of copper Ethernet.

With unicast every viewer receives its own copy of the stream, so the source sends viewers × bitrate; with multicast the source sends one copy and the switches deliver it only to the ports whose devices have joined the group. Ten operator stations watching the same 4 Mbps camera take 40 Mbps from it by unicast but only 4 Mbps by multicast, and paging to 50 IP speakers with G.711 takes about 4.4 Mbps by unicast against about 87 kbps by multicast. Multicast needs IGMP snooping on the switches and an IGMP querier in the same VLAN, otherwise the switches flood the stream to every port like broadcast traffic, and it normally works only inside the local network, not over the internet. KDT camera and NVR datasheets list both multicast and unicast; the viewing software must support it as well.

They can share the switches if the links have capacity to spare, but cameras send a steady, heavy stream around the clock, and a large file copy or backup on the same uplink can then saturate it and cause dropped frames and gaps in recordings. At the least, put the cameras and recorders in a separate VLAN, size the shared uplinks for camera plus office traffic, and use QoS to give voice the highest priority and video priority over bulk data. For large systems, or where recording is critical, a physically separate camera network with its own switches is the simplest way to guarantee bandwidth, and it also keeps the cameras apart from office devices for security.

What matters is the site's upload speed, not the download speed that internet plans usually advertise, because the video leaves the site towards the viewer and each remote viewer receives a separate copy. Add up what will be watched at the same time: four cameras on 0.5 Mbps sub-streams need about 2 Mbps, one 4 megapixel H.265 main stream about 3 Mbps, and two people watching at once need twice as much, plus a margin. On many ADSL connections the upload is only about 0.5 to 1 Mbps, enough for one or two sub-streams, while VDSL, fiber (FTTH) and many 4G/TD-LTE connections offer more upload; measure the actual upload with a speed test at the site. With little upload, use sub-streams or a lower-bitrate third stream for remote viewing, fewer tiles and H.265.

The file size is the recorded bitrate × the duration: one hour at 4 Mbps is 4 × 3600 ÷ 8 = 1800 MB, about 1.8 GB. The download is limited by the site's upload, so it takes about the duration × (recorded bitrate ÷ available upload), plus some overhead: at 2 Mbps of upload, one hour of 4 Mbps video takes about 2 hours, while on the local network it is usually a matter of minutes. Remote playback at normal speed likewise needs an upload at least equal to the recorded bitrate, so for long clips export them at the site, download only the event clips you need, or play back a lower-bitrate stream if the recorder offers one.

The data volume in MB per hour equals the bitrate in Mbps × 450 (3600 seconds ÷ 8 bits per byte). A 0.5 Mbps sub-stream uses about 225 MB per hour, four such streams (2 Mbps) about 900 MB per hour, and a 4 megapixel H.265 main stream at 3 Mbps about 1.35 GB per hour. A site that streams 2 Mbps continuously over 4G to a monitoring center uses 21.6 GB a day and about 648 GB in 30 days, which counts against the site's 4G data package, and against the viewer's too if that one is volume-limited. On volume-limited connections, view on demand with sub-streams, and keep the recording on a local NVR or memory card rather than sending it over the internet.

Each branch needs upload for the streams the center pulls from it, and the center needs download for the sum of all the branches. For example, if the center watches 4 cameras in each of 10 branches on 0.5 Mbps sub-streams, each branch needs 2 Mbps of upload (2.6 Mbps with the 30% margin) and the center 20 Mbps of download (26 Mbps with the margin). Recording every branch centrally on main streams is a very different load: 10 branches × 8 cameras × 3 Mbps is 240 Mbps of continuous traffic, which is rarely practical over the internet, so the usual design is to record locally in each branch and to view live or fetch clips from the center when needed. Where the branches are connected by a private network or a VPN, add its encapsulation overhead and remember the phone and business traffic on the same links.

The nominal rate, such as 300 Mbps for 802.11n 2×2 on a 40 MHz channel or 867 Mbps for 802.11ac 2×2 on 80 MHz, is the raw radio rate, shared by both directions and by every device on the same channel. Real throughput is typically about half of it at best, and less with distance, obstacles, interference and a weak signal. Measure the real throughput after installation, for example with iperf3 between two laptops, and plan the cameras at no more than about half of the measured figure: if a link sold as 300 Mbps measures 120 Mbps, keep the cameras to about 60 Mbps, for example 20 4 megapixel H.265 cameras at 3 Mbps. Prefer the 5 GHz band, keep the line of sight between the antennas clear, and use VBR caps so that bitrate peaks cannot saturate the link.

Divide about half of the real throughput you measure at the camera locations by the bitrate per camera: if a home router on 2.4 GHz gives 40 Mbps of real throughput where the cameras are, about 20 Mbps is usable, which is roughly enough for ten 2 megapixel H.265 cameras at 2 Mbps. The real number is often lower, because a camera with a weak signal talks at a low rate and takes much more airtime, slowing down every other device on the same channel, including phones and laptops. Place the access point where the cameras get a strong signal, use 5 GHz if the cameras support it, and connect busy or distant cameras by cable, which is still the most reliable choice for continuous recording.

With 20 ms packets, a G.711 call (64 kbps codec rate) uses about 80 kbps in each direction at the IP layer and about 87.2 kbps on Ethernet; the wideband G.722 codec usually uses the same, and G.729 (8 kbps codec rate) about 31.2 kbps on Ethernet. So 30 simultaneous G.711 calls need only about 2.6 Mbps in each direction, and a SIP trunk over the internet needs roughly 80 to 90 kbps per concurrent call in both upload and download, depending on the link's framing. For voice, delay, jitter and packet loss matter more than raw bandwidth: ITU-T G.114 recommends keeping one-way delay below 150 ms, so give voice priority with QoS (DSCP EF, value 46) wherever it shares links with video or data.

Typical signs are jerky or frozen video, grey or smeared blocks spreading across the picture (lost packets, especially in I-frames), live view lagging several seconds behind, gaps in recordings and bandwidth warnings on the NVR; they tend to appear when many cameras are opened at once, or at night and in busy scenes when VBR streams peak. To confirm it, add up the bitrates on each link and compare them with its capacity and with the recorder's Input Bandwidth, check port utilization, errors (such as CRC errors) and the negotiated link speed on the managed switches (a faulty cable or connector can hold a gigabit link at 100 Mbps), and see whether the problem goes away when you switch the view to sub-streams or close some cameras. If the problem appears on only one camera and at all hours, the cause is more likely that camera's cable, power supply or settings.

For the cameras, read the current bitrate on the NVR's channel or network status page, or on a managed switch, where the traffic on each camera's port shows its actual rate; SNMP monitoring software can also graph port traffic over a full day and night so that the peaks show up. For a link, run iperf3 between two computers at its two ends (the TCP test shows the usable throughput, and the UDP test also shows packet loss and jitter), and for the internet, run a speed test at the site and look at the upload figure. Compare the results with your calculation: if the real bitrates are higher than you assumed, correct the calculation or lower the caps before adding cameras.

Yes. The “Ask for a project design” button on the storage calculator page sends your request to KDT's sales team, whose engineers size the recorders, hard disks and network for your site and suggest suitable cameras and NVRs. For a useful answer, send the number of cameras of each type with their resolution, codec and frame rate, a simple plan of the site with the buildings, cable distances and any wireless links, the number of operators and remote viewers who will watch at the same time, the type of internet connection with its measured upload, and the models of any switches and recorders you already have. A link to your own calculation from the “Copy link” button also saves time.