CCTV
Work out how much NVR storage a camera fleet needs to hold a required number of days, and whether the network will carry it. Build a schedule of camera groups, each with its own resolution, recording mode and retention period, then size the recorder, as a custom build or one of 65 real catalogue configurations, against capacity, sustained write rate and channel count.
Every surveillance design starts with the same two questions. How much storage does this fleet need to hold the retention the client asked for, and will the network carry it. Both are simple arithmetic, and both are routinely got wrong, because the inputs are less certain than they look and the unit conventions quietly disagree with each other.
The first uncertainty is bitrate. No camera datasheet publishes a stream bitrate, because bitrate is not a property of the product. It is a property of the encoder settings and the scene in front of the lens. Of the 154 real cameras in the noIM3 component catalogue, exactly one mentions a bitrate anywhere in its specifications. This tool therefore does not pretend otherwise. Enter a measured or specified figure and it is used exactly as entered. Use the bits per pixel model instead and every figure it produces is marked as an estimate, with the coefficient visible in the reference panel and editable in the inputs.
The second is that a real site is never uniform. A car park recording on motion for thirty days and a reception recording continuously for ninety days are two different storage problems, and averaging them produces a number that is wrong for both. The schedule here is built from groups, each carrying its own stream definition, recording mode and retention period, so a mixed site sizes correctly in one pass.
The third is that capacity is not one number. Drives are sold in decimal terabytes and reported by the operating system in binary tebibytes, and a ten terabyte drive presents as 9.09 tebibytes. RAID parity, hot spares and the headroom reserve take more out again. And once all that is accounted for, the recorder count is often set not by capacity at all but by the sustained write ceiling or the channel limit, which no amount of extra drive capacity will fix. The tool walks that whole chain and names the constraint that actually binds.
Cameras are entered as groups of identical units, each with its own resolution, frame rate, codec, scene complexity, recording mode and retention period. A site that keeps thirty days on the car park and ninety on the entries sizes correctly in a single pass, with each group's contribution to bandwidth and storage reported separately.
Direct mode takes a measured or specified figure in Mbps and uses it verbatim. Model mode estimates from resolution, frame rate, codec and scene complexity, and marks every figure it produces as an estimate on the row, in the summary and in the clipboard export. The bits per pixel coefficient is shown in the reference panel and can be overridden to match a stream you have actually measured.
Packetisation overhead from RTP, UDP and IP headers applies to what crosses the wire. Container, index and video management metadata apply to what lands on disk. They are genuinely different quantities, so the tool keeps them separate and editable rather than carrying one figure and applying it to both.
Storage is reported both as the decimal terabytes a drive is sold in and the binary tebibytes the operating system shows. The two differ by about nine percent, which is exactly the gap that turns a nominally adequate array into a short one at commissioning.
Raw installed capacity, then hot spares removed, then RAID parity charged in whole drives, then the recording headroom reserve. RAID 5 loses one member, RAID 6 loses two, mirrored levels lose half, and an array with too few members for the level is reported as unbuildable rather than quietly producing a number.
A custom build is specified as drives, bays, hot spares, RAID level and headroom. A catalogue recorder is picked from 65 configurations normalised across eight product families and quoted at its published usable capacity, channel ceiling and write rate, with the verbatim datasheet wording beside every figure. Those ceilings depend on how the recorder is connected, so the network connection is an explicit input, the conservative figure is the default, and a mode the vendor does not offer reports no figure rather than falling back.
Capacity, sustained write rate and channel count are each a hard ceiling, so the recorder count is the largest of the three. The tool says which one binds, because a design short on throughput is not fixed by fitting larger drives, and neither is a design short on channels.
A four head multi sensor camera is one unit on one cable drawing from one PoE port, but four encoded streams and four recorder channels. Counting it as one channel understates the recorder requirement fourfold, so channels are tracked in streams throughout.
PoE load uses PSE figures, the power reserved at the switch port. 802.3af reserves 15.4 W to deliver 12.95 W at the camera, so sizing a switch on the powered device figure under counts by about sixteen percent. Cameras with no power data are counted and surfaced rather than assumed to draw nothing.
The tool runs on labelled generic camera classes and needs no database. An optional picker seeds a group from 154 real catalogued cameras, filling in resolution, maximum frame rate, codec support, imager head count and PoE class, and listing any field it could not read from the row rather than defaulting it silently.
Reach for the CCTV Bandwidth & NVR Storage Calculator in any of the following situations.
Because no camera datasheet publishes one. Bitrate is a property of the encoder settings and the scene in front of the lens, not of the product: the same camera on a static corridor and on a busy forecourt produces very different streams. Of the 154 real cameras in the noIM3 component catalogue, exactly one mentions a bitrate anywhere in its specifications. Selecting a catalogue camera here seeds its resolution, frame rate, codec support, head count and PoE class, and leaves the bitrate to your measured figure or to the model, which labels itself as an estimate.
It is a planning estimate and is captioned as one everywhere it appears. The model computes Mbps as width times height times frame rate times bits per pixel times a codec factor, with four scene complexity bands from 0.05 to 0.20 bits per pixel defined at H.264. As an anchor, 1080p at 25 frames per second on the Medium band computes 5.18 Mbps, which sits mid range against published H.264 tables. It is good enough to size a system and to have a budget conversation. It is not a substitute for measuring a commissioned stream, and where you have a measured figure the Direct mode uses it verbatim.
Usually one of three reasons. Vendor calculators often carry a single overhead figure and apply it to both bandwidth and storage, where this tool applies packetisation overhead to the wire and container overhead to the disk separately. They often report in one unit convention without saying which, where this tool reports decimal and binary side by side. And they usually assume a smart codec saving by default, where this tool defaults that to zero because the saving is entirely scene dependent and headline figures are best case. Set the assumptions to match and the numbers converge.
A decimal terabyte is 10 to the twelfth bytes, which is how drives are sold. A binary tebibyte is 2 to the fortieth bytes, which is what the operating system reports. A ten terabyte drive presents as 9.09 tebibytes, a difference of about nine percent. Size an array in one convention and buy drives in the other and the result is a shortfall that only appears once the archive fills. Both figures are shown throughout so the conversion is never left implicit.
Because capacity is not the constraint that binds. A recorder has three hard ceilings: how much it can store, how fast it can write, and how many channels it can accept. The count is the largest of the three, and the tool names which one it is. If sustained write rate or channel count binds, larger drives change nothing and the answer is to split the fleet across more recorders, reduce the stream load, or specify a platform with a higher ceiling.
A multi sensor camera is one physical unit on one cable drawing from one PoE port, but each imager head encodes its own stream. So a four head unit is one camera, one port, four streams and four recorder channels. The tool tracks channels in streams throughout, and the catalogue adapter reads the head count from the structured resolution rating, so a four by eight megapixel unit seeds four channels automatically.
Yes, through the idle rate. Motion mode records at the full rate for the active fraction of the recording window and at a stated percentage of the full rate for the remainder. Set the idle rate to zero and nothing is written between events. Set it above zero to model pre and post roll buffers or a reduced rate idle stream. Storage is charged on the resulting twenty four hour average, while bandwidth is still charged at the peak, because the link has to carry every camera triggering at once.
Because it is reported at the switch port, not at the camera. The 802.3af standard reserves 15.4 W at the power sourcing equipment to deliver 12.95 W at the powered device, and a switch power budget is consumed at the port. Sizing a switch on the powered device figure under counts by about sixteen percent, which is a common way to overload a supply. Cameras with a measured draw use that figure; cameras without one fall back to the class reservation.
No. It is built on labelled generic camera classes and is fully usable with the catalogue unreachable. The catalogue picker is an optional convenience that seeds a real camera's capability envelope, and if it fails to load the tool says so and carries on with the generic classes.
Create a free account and start calculating today.
