Understand how bitrate affects image quality, bandwidth, and storage in IP CFTV, how CBR, VBR, MBR, and ABR work, and how to size network and storage using engineering criteria.
Check it out!
Bitrate in CFTV is the amount of data a video stream generates per unit of time, usually expressed in Mbit/s or kbit/s. It is not merely a camera parameter: it is a design variable that connects image quality, network capacity, server load, and storage volume. The higher the effective bitrate produced, the greater the demand tends to be on uplinks, network interfaces, and storage; the more aggressively it is limited, the greater the potential loss of visual detail in complex scenes.
Therefore, there is no single “correct bitrate” defined only by camera resolution. A 4 MP camera does not, by definition, have a fixed rate; two cameras with the same resolution and codec may generate very different streams depending on motion, lighting, noise, frame rate, GOP, rate-control strategy, and encoder implementation. Proper sizing starts with the monitoring objective and required evidentiary image quality, defines capture and compression parameters, and only then verifies whether the network and storage can support the system’s average and peak behavior.
What Is Bitrate in IP CFTV?
In digital video, bitrate is the data throughput produced by the encoding process. If a stream operates at 4 Mbit/s, this means that, over a given interval, the encoder is producing approximately four million bits per second of encoded video. This number may be a measured value, a time average, a control target, or a maximum limit, depending on the rate-control mode implemented by the equipment.
No IP CFTV, video leaves the camera as network traffic and passes through switches, uplinks, and server interfaces until it reaches the VMS and recording subsystem. The same parameter that defines how much traffic crosses the network also determines, as a first approximation, how many bytes must be written per unit of time.
The relationship is direct:
bitrate → network traffic → write rate → retention capacity.
However, this relationship should not be confused with absolute equivalence. The bitrate indicated by the camera represents the encoded stream; the network carries that stream with additional encapsulation and protocols; storage also deals with the file system, indexes, VMS databases, metadata, redundancy, and retention policies. The basic calculation is the starting point, not the final design result.
Why Can’t Bitrate Be Selected Based Only on Resolution?
Resolution indicates how many pixels make up each frame, but it does not indicate how many bits will be required to represent the frame sequence after compression. The encoder looks for spatial and temporal redundancies. A static, well-lit wall with little noise is highly compressible; the same camera pointed at trees in the wind, rain, reflections, heavy traffic, or a noisy night scene may require much more data to preserve equivalent quality.
The factors that most affect the effective rate include:
- image resolution and aspect ratio;
- frame rate;
- amount and speed of motion;
- level of spatial detail in the scene;
- electronic noise, especially in low-light conditions;
- exposure time and motion blur;
- WDR and lighting dynamics;
- codec and encoder implementation;
- I-frame interval and GOP structure;
- quality/compression policy;
- rate-control mode;
- region-of-interest or content-aware encoding features;
- presence of associated audio and metadata.
This explains why generic tables such as “1080p = X Mbit/s” serve only as a preliminary reference. In design, the value should be confirmed using explicit assumptions and, when justified by criticality, by testing representative scenes.
How Do H.264 and H.265 Affect Bitrate?
H.264/AVC and H.265/HEVC use temporal compression to represent a video sequence with less data than would be required to encode every frame in full. Efficiency comes from prediction, transform, and coding tools, but the codec standard does not prescribe a single rate-control algorithm or guarantee that two different encoders will produce the same quality-to-bitrate relationship.
This point is decisive for specification. The ITU-T recommendation defines the syntax and mechanisms required to produce and decode a compliant bitstream. The specific strategy used by the encoder to decide how much detail to preserve, where to spend bits, and how to respond to scene complexity can vary between implementations.
H.265 Does Not Automatically Mean “Half the Bitrate”
Fixed savings percentages are often attributed to H.265 compared with H.264. This should not become a universal design assumption. Actual gains depend on resolution, motion, texture, noise, GOP, profile, quality level, processor capability, and manufacturer implementation. In some scenes the gain can be substantial; in others, lower than expected.
For sizing, the technically defensible approach is to compare codecs under equivalent image-quality and scene conditions, using equipment data or representative measurements. The codec should reduce demand without compromising the monitoring objective.
There is also an operational cost: more efficient codecs may require greater decoding capacity in clients, servers, GPUs, or operator workstations. Therefore, bitrate cannot be optimized independently of the processing chain.
GOP, I-frames, P-frames, and Their Effect on Bitrate
Temporal compression works with frames that play different roles. An I-frame is self-contained: it can be decoded without depending on another frame. Predictive frames reuse information from reference frames and therefore generally consume fewer bits.
The set between keyframes forms a GOP, or Group of Pictures. Reducing I-frame frequency tends to lower the average bitrate because complete frames are sent less often. However, a longer GOP increases temporal dependency and can affect recovery time after losses, random access to recordings, and behavior in certain forensic applications.
Sizing should avoid two opposite simplifications: treating the I-frame interval as irrelevant or maximizing the GOP solely to save bandwidth. The parameter must be compatible with operations, recording, playback, interoperability, and stream resilience.
The peak of an I-frame matters to the network
Even when the average bitrate appears comfortable, I-frames can generate larger bursts. If many cameras are configured similarly and produce peaks close together in time, instantaneous traffic on uplinks or recording interfaces can deviate significantly from the average. This is one reason not to size a network merely by dividing nominal link capacity by the average bitrate of each camera.
CBR, VBR, MBR, and ABR: What Is the Difference?
Rate-control terminology varies among manufacturers and platforms. Therefore, the specification should describe the intended behavior rather than merely require an acronym. In functional terms, the four most common concepts are as follows.
| Mode | Prioritized variable | Typical behavior | Main design risk |
| CBR | bitrate budget/target | encoder adjusts quality to remain close to the target | detail degradation when the scene becomes complex |
| VBR | defined quality | bitrate rises or falls according to scene complexity | peaks higher than the expected average |
| MBR | quality with a bitrate ceiling | VBR until the limit is approached; then the encoder restricts quality and/or another parameter | reaching the ceiling precisely during the critical event |
| ABR | average budget over time | controller compensates periods of lower and higher consumption while seeking an average | confusing time average with required instantaneous capacity |
CBR: Constant Bit Rate
CBR is often interpreted as a constant bitrate, but in real implementations it should be understood as control around a target bitrate. Video complexity continues to vary. To stay within the budget, the encoder changes quantization and quality parameters, and the instantaneous rate may fluctuate.
The main advantage is predictability. When a link has contracted or restricted capacity, working with a known target simplifies planning. The tradeoff is that during difficult scenes, bit limitation can appear as loss of texture, block artifacts, or reduced quality precisely when there is more visual information.
VBR: Variable Bit Rate
With VBR, the system seeks to maintain a given quality and allows the bitrate to follow scene complexity. An empty, static area may consume little; the sudden arrival of people, vehicles, rain, or noise can significantly increase throughput.
It is a coherent strategy for applications where preserving quality is a priority, provided the infrastructure is sized for plausible peaks, not only the average observed under favorable conditions.
MBR: Maximum Bit Rate
MBR combines variable behavior with a ceiling. While the scene remains within the budget, the encoder preserves the configured quality. As it approaches the limit, it must alter encoding to prevent the stream from exceeding the maximum throughput.
This mechanism is useful when there is an objective bandwidth constraint. However, the ceiling must be validated in critical scenes. If the limit is selected only to “fit the network,” the system may respond to the most complex event by degrading exactly the image it should preserve.
ABR: Average Bit Rate
ABR works with an average budget over a period of time. The principle is to allow lower-consumption periods to create margin for more demanding periods while seeking to meet a planned average volume. It is particularly useful when retention is the dominant constraint.
A controlled average does not eliminate instantaneous peaks. The network and interfaces must still support the transient rates permitted by the encoder.
Which Mode Should Be Selected in the Design?
There is no universal answer. The choice depends on the dominant constraint.
When forensic image quality is the priority and the network has sufficient capacity, VBR or equivalent quality-oriented strategies tend to preserve complex scenes better. On constrained links, MBR can establish a necessary ceiling, but that ceiling must be tested. CBR may be appropriate when bandwidth predictability is a strong requirement, provided image quality under the worst-case scenario is demonstrated. ABR makes sense when the main issue is managing a storage budget over time.
The engineering criterion is simple: do not choose the mode by its acronym; choose it based on how the system needs to behave when the scene departs from average conditions.
How to Calculate Aggregate Traffic in a CFTV System?
The first approximation is to add the bitrates of the streams that actually traverse the link being analyzed.
If Bᵢ is the bitrate of the active stream from camera i, then:
B_total = Σ Bᵢ
For equivalent cameras:
B_total = N × B_câmera
where N is the number of cameras simultaneously transported on that segment.
This calculation must be applied per traffic path. An access-switch uplink may carry only the cameras connected to that cabinet; the recording server interface may receive cameras from several switches; a WAN link may carry only selected streams, substreams, or events.
Example: 25, 50, and 100 cameras at 4 Mbit/s
Considering only the nominal payload of a 4 Mbit/s recording stream per camera:
| Cameras | Bitrate per camera | Nominal aggregate traffic |
| 25 | 4 Mbit/s | 100 Mbit/s |
| 50 | 4 Mbit/s | 200 Mbit/s |
| 100 | 4 Mbit/s | 400 Mbit/s |
These numbers do not justify concluding that a 100 Mbit/s link is adequate for the 25 cameras in the first scenario. Nominal interface capacity is not equivalent to the design capacity available for video. Protocol overhead, encoder variations, other services, bursts, contingencies, and availability policies must be considered.
For a deeper analysis of the topology and bottlenecks among access, uplinks, backbone, VMS, and storage, see the article on IP CFTV infrastructure.
Average, Peak, Percentiles, and Worst Case
A VBR system should not be characterized by a single bitrate reading. A short measurement of an empty scene may produce an apparently excellent value that is completely inadequate for peak-activity periods or nighttime conditions.
A useful measurement campaign should record the time series and, according to criticality, evaluate:
- average during the observed period;
- instantaneous maxima or maxima over short windows;
- percentiles such as P95 and P99;
- daytime and nighttime behavior;
- occurrence of rain, vegetation, shadows, headlights, and intense movement;
- alarm events and scene changes.
The average is useful for estimating storage volume. Peaks and high percentiles are relevant for sizing the network and understanding operating margin. The technical worst case should also consider conditions that may not have occurred during testing.
Average Bitrate Is Not the Same as Link Capacity
A 1 Gbit/s Ethernet interface should not be treated as a “reservoir” of exactly 1,000 Mbit/s available for video. The design needs to consider all traffic sharing the link and the availability requirements.
In an IP CFTV network, the most frequent bottlenecks occur at concentration points: uplinks, stacking, trunks, backbone, server interfaces, and paths to storage. A camera port on Fast/Gigabit Ethernet is rarely the limiting factor for the entire system; the problem arises when dozens or hundreds of streams converge.
There is no universal percentage margin that can replace calculation. Headroom must reflect peaks, expected growth, failover, competing traffic, and equipment behavior.
Multiple Streams: When Should They Be Added Together?
IP cameras normally support more than one stream with different resolutions, FPS, codecs, or quality settings. A main stream may be intended for recording; another, lighter stream for mosaic viewing; a third may serve a specific integration.
A common mistake is to add all configured streams as though they were permanently active. The opposite mistake is to ignore that multiple consumers can generate simultaneous traffic.
The calculation should answer:
- which streams are produced continuously;
- which are requested only on demand;
- whether the camera sends independent unicast streams to multiple clients;
- whether the VMS receives the video once and redistributes it to clients;
- whether multicast is used and on which segments;
- how behavior changes during alarms, playback, and investigation.
This analysis is particularly important in control rooms with many displays, remote clients, and integrations.
Unicast, Multicast, and Redistribution by the VMS
With unicast, each session may require a copy of the stream to the destination. If several clients access the same camera directly, device egress traffic and traffic on the involved segments can grow with the number of consumers. In architectures where the VMS acts as a proxy or distributor, the camera may provide one stream to the server while clients receive copies from the backend infrastructure.
Multicast can reduce duplication in certain live-view topologies, but it requires a network prepared for this behavior and does not eliminate the need to size recording. The design should map the source, destination, and direction of each relevant flow.
How to Calculate Storage from Bitrate?
For a continuous stream, the basic conversion is straightforward. Using decimal units:
GB per day ≈ bitrate in Mbit/s × 10.8
This comes from:
Mbit/s × 1,000,000 × 86,400 s ÷ 8 ÷ 1,000,000,000
Therefore, an average 4 Mbit/s stream generates approximately:
4 × 10.8 = 43.2 GB/day
Over 30 days:
43.2 × 30 = 1,296 GB ≈ 1.296 TB per camera
Examples of Continuous Retention for 30 Days
| Cameras | Average bitrate | Payload/day | Payload/30 days |
| 25 | 4 Mbit/s | 1.08 TB | 32.4 TB |
| 50 | 4 Mbit/s | 2.16 TB | 64.8 TB |
| 100 | 4 Mbit/s | 4.32 TB | 129.6 TB |
These values represent the nominal video payload. The required raw disk volume will be greater when filesystem overhead, VMS databases and indexes, metadata, operating reserve, RAID or erasure coding, hot spares, retention policies, and other platform requirements are included.
Complete subsystem sizing is covered in the dedicated content on storage for CFTV and enterprise VMS.
What About Event-Based Recording?
If recording is not continuous, an activity factor can be used as an initial estimate:
Storage ≈ average bitrate during recording × time actually recorded.
If a camera records, on average, 40% of the 24 hours, the preliminary estimate can apply a factor of 0.40 to the continuous volume. However, this percentage must be treated cautiously. Detector sensitivity, pre-buffer, post-buffer, schedules, shadows, rain, vegetation, and analytics alter the actual duration of events.
In critical systems, event-based retention should be validated using observed data or conservative assumptions. An arbitrary activity factor can silently undersize storage.
FPS and Bitrate: Does Doubling Frames per Second Double Bandwidth?
Not necessarily. The relationship is not perfectly linear because interframe codecs exploit temporal redundancy. Moving from 15 to 30 fps increases the amount of temporal information to encode, but the impact depends on motion, GOP, codec, and encoder.
The correct question is not “which FPS saves the most?”, but what frame rate is required for the monitoring objective. Fast movement, cash registers, production lines, vehicle traffic, and frame-by-frame investigation may require higher rates than low-dynamic areas.
Reducing FPS solely to make the system fit the network is an engineering decision only if the operational requirement remains satisfied.
Low Light Can Increase Bitrate
A counterintuitive consequence is that an apparently “static” scene can consume more data at night. In low light, electronic gain tends to increase and, with it, image noise. To the encoder, this noise appears as spatial and temporal variation that must be represented.
Therefore, a test performed only during the day may underestimate nighttime bitrate. Lighting, exposure, gain, noise reduction, and codec configuration interact directly with bandwidth and storage.
This relationship shows why image quality and infrastructure cannot be treated as independent disciplines.
Motion, Vegetation, Rain, and High-Complexity Scenes
Trees, water, smoke, particles, heavy rain, crowds, and traffic generate continuous changes across a large portion of the frame. In VBR, this can significantly increase consumption. In CBR/MBR, the same complexity can pressure the controller to the point of sacrificing detail.
A perimeter camera pointed toward vegetation should not automatically receive the same bitrate budget as an indoor corridor camera simply because both have the same resolution.
The design should classify scenes according to expected behavior and allocate parameters compatible with each class.
Resolution, Pixel Density, and Forensic Image Quality
Bitrate cannot be used as a substitute for an image-quality criterion. A camera may transmit 8 Mbit/s from a poorly framed scene and still be unable to identify the target. Required quality begins with the image requirement: field of view, pixel density on the object, lighting, focus, motion, and environmental conditions.
The article on monitoring points and pixel density explores this stage in greater depth. Only after defining the useful image does it make sense to optimize compression.
How to Size Access-Switch Uplinks
The procedure is to calculate which cameras converge on each uplink and the design bitrate profile of each one. If a switch has 20 cameras and each recording stream has been validated with a design peak of 8 Mbit/s, the primary video contribution can reach 160 Mbit/s on that path, before other flows and overhead.
Then evaluate:
- effective uplink capacity;
- peak simultaneity;
- management traffic and other services;
- additional streams;
- expected growth;
- behavior during failure of a link or device;
- LACP aggregation, when applicable;
- capacity of the next concentration level.
The calculation must continue through the recording server and storage. Solving only the first uplink simply moves the bottleneck to the core or server interfaces.
Bitrate and Recording-Server Interfaces
The recording server receives an aggregate of streams, performs processing, and writes data to the storage subsystem. Depending on the architecture, it may also serve recorded video, redistribute live view, and process metadata.
Therefore, the server NIC should be analyzed in two directions: recording ingress and egress to clients or external storage. In large systems, multiple interfaces, traffic segregation, bonding/teaming, and distribution across recording servers may be necessary.
The server’s network capacity should not be confused with the array’s write capacity. A server may receive packets correctly and still lose recordings if the storage backend cannot sustain the IOPS, throughput, or latency required by the platform.
Rate Control Does Not Replace QoS
CBR or MBR controls encoder behavior. QoS acts on traffic treatment and prioritization in the network. They are different mechanisms.
Limiting each camera to a ceiling does not ensure that critical video will have priority when the link is congested. Likewise, marking packets with priority does not fix a system whose sustained demand exceeds physical capacity.
QoS is a traffic-governance layer; sizing is still required.
How to Handle WAN Links and Remote Sites
WAN introduces constraints different from LAN: contracted bandwidth, asymmetry, latency, jitter, loss, downtime, and transport cost. At remote sites, permanently transmitting the maximum-quality recording stream to the center may be inappropriate.
Possible architectures include local recording, edge storage, substream transmission for operations, later retrieval of high-quality video, and transmission of main streams only during events. The choice depends on continuity requirements and the maximum acceptable time to retrieve evidence.
In this context, bitrate is an architectural variable. The best solution may not be simply to compress more, but to change where the video is recorded and where it needs to travel.
Edge Storage and Failover
Edge storage makes it possible to keep recording close to the camera during loss of connectivity with the central server. When the platform supports later retrieval, the missing video can be reintegrated into the central archive.
This feature changes the traffic profile: during the failure, the stream no longer reaches the server; during recovery, additional traffic may arise to synchronize the backlog while current video continues to be transmitted. The link also needs to be evaluated in this recovery state.
Bitrate and Analytics
Analytics can run in the camera, on the server, or on specialized infrastructure. When processing occurs at the edge, it is not always necessary to transport an additional stream solely to perform the analysis. When analytics receives video on another server, there may be a new flow or redistribution of the stream already received by the VMS.
Analytical metadata normally represents a much smaller volume than video, but it is part of the system and needs to be considered in interfaces, storage, and integrations when retaining that data is a requirement.
More importantly, compression cannot degrade the image to the point of harming the algorithm. A bitrate limit suitable for human viewing may not be suitable for the intended automated analysis.
Bitrate and Cybersecurity
Protecting video with secure protocols adds processing and some overhead, but this does not justify removing encryption to “save bandwidth.” Cybersecurity should be an architectural requirement. The design must ensure that switches, cameras, servers, and clients have sufficient capacity to operate the intended protection mechanisms without compromising performance.
The topic is explored further in the whitepaper on cybersecurity in CFTV systems.
A Nine-Step Sizing Methodology
A traceable sizing process can follow the sequence below.
- Define the monitoring objective. Establish what each point must allow the system to observe, detect, recognize, or identify and under which conditions.
- Define capture parameters. Resolution, field of view, FPS, exposure, WDR, and other parameters that influence the useful image.
- Define codec and rate-control strategy. Select H.264/H.265 and the expected behavior of VBR, CBR, MBR, or equivalent.
- Classify the scenes. Separate static, dynamic, outdoor, nighttime, vegetation, traffic, or other relevant scenarios.
- Obtain a reference bitrate. Use design tools, manufacturer data, or representative measurements with documented assumptions.
- Define design average and peak. Do not use a single value for every verification when the stream is variable.
- Map flows in the topology. Add only the streams that traverse each link, server, or interface.
- Size retention. Convert average bitrate into volume, add storage layers, and validate the retention policy.
- Commission and measure. Confirm in the field the image, bitrate, traffic, recording, and recovery under the intended states.
This sequence avoids the classic mistake of selecting cameras first, filling in a generic Mbps spreadsheet afterward, and discovering the bottleneck only during implementation.
Design Matrix: Parameter, Impact, and Evidence
| Parameter | Main impact | What must be verified |
| resolution | spatial detail and data volume | compliance with the image objective |
| FPS | temporal continuity and consumption | critical motion reproduced adequately |
| codec | efficiency and processing load | compatibility and equivalent quality |
| GOP/I-frame | bitrate, recovery, and random access | behavior during recording and loss |
| VBR/CBR/MBR/ABR | quality × predictability relationship | critical scene within the budget |
| average bitrate | storage volume | actual retention achieved |
| peak bitrate | network capacity | absence of saturation and losses |
| multiple streams | camera/network/VMS load | actual simultaneity |
| event-based recording | duty cycle and retention | actual event duration |
| edge/failover | continuity and recovery | backlog reintegrated without network collapse |
Complete Example: 100 Enterprise Cameras
Consider 100 cameras whose main stream has been validated with an average of 4 Mbit/s and design peaks of up to 8 Mbit/s in representative scenes.
For continuous storage, the aggregate average is:
100 × 4 = 400 Mbit/s.
The nominal daily payload is:
400 × 10.8 = 4,320 GB/day = 4.32 TB/day.
For 30 days:
4.32 × 30 = 129.6 TB of nominal video.
This number is not the final array size. Storage architecture, redundancy, reserve, filesystem, metadata, retention policy, and VMS requirements still need to be applied.
For the network, it would not be correct to size paths only for the 400 Mbit/s average. If all streams can reach 8 Mbit/s, engineering needs to study simultaneity and peak behavior at concentration points. The theoretical upper limit of stream contribution would be 800 Mbit/s, before other traffic. The topology can distribute cameras across multiple uplinks and recording servers, reducing concentration on a single path.
The example shows why storage is predominantly governed by the average over time, while the network must survive plausible high throughputs.
Example of a Remote Site with a Constrained Link
Consider a remote site with 20 cameras and a limited WAN uplink. Transmitting 20 main streams at 4 Mbit/s would require a nominal 80 Mbit/s for continuous video alone, which may be incompatible with the link or with other corporate services.
There are at least three engineering strategies:
- reduce the bitrate of the remote stream while preserving the main recording locally;
- transmit substreams for monitoring and request the main stream only when needed;
- maintain local/edge recording and synchronize evidence during events or controlled windows.
The best option depends on the operational requirement. Simply reducing every stream to an arbitrary bitrate may solve the bandwidth problem while creating an evidence-quality problem.
How to Specify Bitrate Without Locking the Design to a Manufacturer
A vendor-neutral specification should avoid values copied from a datasheet without relation to the requirement. Rather than requiring a “fixed bitrate of X Mbit/s,” it is more robust to establish performance criteria.
Examples of verifiable requirements:
- allow configuration of resolution, FPS, codec, and rate-control parameters required by the architecture;
- allow bitrate limiting where there is a link constraint;
- preserve the minimum quality defined for reference scenes;
- support the simultaneous streams planned in the design;
- provide interoperability with the VMS and the adopted encoding profile;
- allow consultation or measurement of effective bitrate;
- maintain stable operation under the highest-complexity specified scenario.
The specification may indicate a network budget or design range, but acceptance must demonstrate the operational result, not merely the presence of an option in the camera menu.
What Should Be Tested During Commissioning?
Bitrate should be included in the test plan when it affects network capacity, retention, or image quality. Commissioning can compare the design calculations with the system’s actual behavior.
A minimum test campaign should include:
- streams and parameters configured according to the design;
- average and peak bitrate measurements;
- verification of uplinks and recording interfaces;
- planned simultaneous playback and live view;
- behavior during alarms;
- nighttime scenario and highest-motion scenes;
- retention actually achieved;
- connectivity loss and recovery, when failover is provided;
- image quality under the specified bitrate limit.
Acceptance should not be limited to confirming that “the camera records.” It is necessary to prove that the system records the intended quality, for the intended period, without exceeding infrastructure capacity.
Common Mistakes When Sizing Bitrate in CFTV
Using a Single Mbps Value for Any Camera
This ignores the scene, lighting, FPS, codec, GOP, and encoder behavior.
Sizing the Network by the VBR Average
The average may be adequate for storage while still hiding peaks that saturate uplinks.
Using the Maximum Limit as Though It Were the Storage Average
This can drastically oversize retention when the stream rarely reaches the ceiling. The reverse — using an optimistic average as a guaranteed maximum — is also incorrect.
Assuming Fixed Savings When Switching from H.264 to H.265
Efficiency depends on the implementation and video conditions. Generic percentages do not replace testing or equipment data.
Ignoring Nighttime Conditions
Noise and gain can increase bitrate demand and change quality under CBR/MBR.
Ignoring Viewing Streams and Integrations
Mosaics, operators, analytics, remote clients, and integrations can create additional traffic.
Adding All Configured Streams Without Analyzing Simultaneity
Not every existing stream is active all the time. The flow map must represent actual behavior.
Treating RAID as Available Nominal Capacity
The sum of disk capacities is not equivalent to usable capacity. Redundancy, spares, and the filesystem reduce the space effectively available for video.
Bitrate Should Be Addressed in CFTV Design, Not During Final Configuration
When bitrate is discussed only during implementation, the most important decisions have already been made: number of cameras, topology, uplinks, servers, storage, retention, and remote links. At that stage, “reducing the bitrate” becomes an attempt to make the system fit the contracted infrastructure.
In IP CFTV and Video Surveillance Design, bitrate should be part of the sizing calculations and architecture: assumptions by camera class, average estimates, peaks, simultaneous flows, retention, and margins must be consistent with one another.
This approach also improves procurement and inspection. The contractor receives not only a number of cameras and retention days, but verifiable criteria to demonstrate that the proposed solution meets network, processing, and storage requirements.
Final Considerations
Bitrate is the linking variable between image and infrastructure in an IP CFTV system. It should not be selected from a generic table, from the camera’s default value, or from an assumed compression percentage. The design must begin with the monitoring objective, characterize the scenes, define capture and codec parameters, select the rate-control strategy, and then calculate how flows accumulate in each part of the architecture.
For storage, the time average determines the primary recording volume. For the network, peaks, bursts, and simultaneity become decisive. For image quality, the fundamental test is to verify what happens when the scene becomes more difficult and the encoder must work within the available budget.
When these three axes — image, network, and retention — are addressed together, bitrate ceases to be a camera setting and becomes what it truly is: an engineering parameter of the video surveillance system.
Technical references
[1] INTERNATIONAL ELECTROTECHNICAL COMMISSION (IEC). IEC 62676-1-2:2013 — Video surveillance systems for use in security applications — Part 1-2: System requirements — Performance requirements for video transmission. 2013. Available at: https://webstore.iec.ch/en/publication/7348.
[2] INTERNATIONAL TELECOMMUNICATION UNION (ITU-T). Recommendation H.264 (06/2026) — Advanced video coding for generic audiovisual services. 2026. Available at: https://www.itu.int/rec/T-REC-H.264.
[3] INTERNATIONAL TELECOMMUNICATION UNION (ITU-T). Recommendation H.265 (01/2026) — High efficiency video coding. 2026. Available at: https://www.itu.int/rec/T-REC-H.265.
[4] AXIS COMMUNICATIONS. Technical Guide to Network Video. Available at: https://www.axis.com/forms/technical-guide-to-network-video.
Frequently asked questions
It is the amount of data produced by the video stream per unit of time, usually in kbit/s or Mbit/s. In design, bitrate connects image quality, network capacity, recording load, and storage volume.
There is no universal value. Bitrate depends on resolution, FPS, motion, lighting, noise, codec, GOP, configured quality, and rate-control strategy. The value should be defined from the image objective and validated for the expected scenes.
CBR works around a target bitrate and tends to adjust quality to remain within the budget. VBR prioritizes a defined quality and allows the rate to vary according to scene complexity. Exact behavior depends on the encoder implementation.
MBR is a maximum-bitrate strategy: the stream may vary while it remains below the ceiling, but when it reaches the limit the encoder must restrict encoding, potentially reducing quality or another parameter depending on the implementation.
No. H.265 can be more efficient, but actual gains depend on the encoder, scene, resolution, motion, GOP, and quality criterion. A fixed percentage should not be used as a universal sizing assumption.
For continuous recording using decimal units, an approximation is GB/day ≈ bitrate in Mbit/s × 10.8. Retention, number of cameras, redundancy, filesystem, metadata, and VMS requirements must then be considered.
The nominal continuous payload is approximately 129.6 TB over 30 days. This is not the final array size: redundancy, filesystem, metadata, operating reserve, and storage architecture increase the required raw capacity.
In low light, increased gain and noise can make the image less compressible. The encoder must represent more variation, which can increase the rate in VBR or pressure image quality when a CBR/MBR limit is imposed.
No. The average is useful for estimating recording volume, but the network must also be verified for peaks, bursts, simultaneity, additional streams, and contingency states.
Yes, when it is an assumption for network capacity, quality, or retention. Configured parameters, average and peak bitrate, uplink utilization, recording, retention, and critical-scene image quality should be verified.
Additional technical materials
Related services
- IP CFTV and Video Surveillance Design: coverage, VMS, storage, and integration
- Logical Network and Enterprise Network Design
