On this page
A network video recorder receives a main video stream from each network camera, may provide a lighter substream for viewing, connects through a network switch and serves footage to a local screen or remote viewing device. When choosing an NVR, the practical question is not simply how many camera channels appear on the specification sheet. It is whether the recorder can receive, record, display and send the complete set of streams at the same time, with enough headroom for real conditions.
What does throughput mean when choosing an NVR?
NVR throughput explained: which limits matter?
Throughput describes how much video data a recorder can process over a given period. It is often confused with the speed printed on a network port or switch. A fast Ethernet link is useful, but it does not prove that the recorder can accept, record, decode or retransmit video at the same rate. The internal recording hardware and software have their own limits.
The first figure to examine is incoming bandwidth. This is the combined load of the camera streams arriving at the recorder. If every camera records its main stream, those main-stream bitrates must be added together. Additional streams or audio can also contribute where enabled.
The next figure is outgoing bandwidth. It covers video sent from the recorder for live viewing, playback and export across the network. A property’s internet upload connection can impose a separate restriction on remote access, even when the recorder itself has adequate outgoing capacity.
Decoding is different again. The recorder must decode compressed video to show it on a connected display. A demanding multi-camera layout can therefore reach the decoding limit while incoming recording continues normally. The remote viewing device usually performs its own display decoding, although the recorder still has to retrieve and send the requested streams.
| Capacity term | What it limits | Typical demand |
|---|---|---|
| Incoming bandwidth | Combined video received by the recorder | Main recording streams from all cameras |
| Outgoing bandwidth | Video sent across the network | Live view, playback and export |
| Decoding capacity | Video displayed by the recorder at one time | Local multi-camera layouts and full-screen playback |
| Channel count | Number of camera connections supported | The total number of configured cameras |
| Network link speed | Traffic carried by a particular connection | Camera, recorder and viewing traffic sharing that link |
Channel count remains a hard limit, but it is only one limit. A recorder may have spare channels and still lack the throughput or decoding capacity for the proposed settings. Conversely, a system with modest stream settings may fit comfortably within the relevant limits while using every available channel.
Build the camera stream total
How do you calculate NVR recording bandwidth?
Start with the configured main-stream bitrate of each camera, not resolution alone. Add the bitrates for all streams that the recorder will receive and record. Cameras with different jobs need not use identical settings, so a line-by-line schedule is more reliable than multiplying one assumed value by the channel count.
- List every camera and its recording main stream.
- Record the intended bitrate, frame rate, compression mode and audio setting for each stream.
- Include any additional stream that the NVR receives continuously.
- Add the individual bitrates to obtain the expected aggregate incoming load.
- Compare the total with the recorder’s incoming limit and retain unused capacity.
Resolution and frame rate influence bitrate because they affect how much visual information must be encoded. They do not determine it on their own. Video compression settings, image noise and the amount of change in the scene also matter. A quiet corridor is easier to compress than moving foliage, flowing traffic or a busy shop entrance using otherwise similar settings.
Variable-bitrate video can rise when the scene becomes harder to encode. Strong image noise at night can also consume more data than expected. Treat a quoted target bitrate as a planning input, not proof that every moment will remain at that level.
Continuous and event recording change storage use, but the effect on incoming throughput depends on system behaviour. A camera may continue sending video so that the recorder can display it, analyse motion detection or maintain a pre-event buffer even when footage is not being written continuously. Do not assume that event recording reduces the network load unless the actual stream behaviour confirms it.
Account for real viewing behaviour
Recording calculations often assume that video enters the NVR and stays there. Real users open a local grid, check cameras from a remote viewing device, play back an incident and export a clip. These activities can overlap. A useful design describes who views the system, from where and in which layout.
A local display creates a decoding requirement. Showing many main streams together can be substantially more demanding than displaying one camera full screen. Recorders commonly use lower-demand streams for grid layouts and switch to the main stream when a camera is enlarged. That behaviour should be confirmed rather than assumed.
Substreams are valuable because they separate recording detail from routine viewing load. The NVR can retain the main stream while a phone, laptop or VMS (video management software) requests a lighter substream. The lower stream can use a less demanding resolution, frame rate or bitrate without reducing the recorded main stream.
- Remote live view consumes outgoing recorder capacity and property internet upload capacity.
- Remote playback reads recorded material and sends it to the requesting device.
- Export can create sustained outgoing traffic, particularly when several long sections are retrieved.
- Concurrent users can request different cameras or playback periods at the same time.
- Large display grids may request many substreams concurrently, while selected views may switch to main streams.
For a remotely managed home or business in Israel, test the exact access pattern that will be used from abroad. A recorder can be healthy while the viewing experience is constrained by the site’s internet uplink, Wi-Fi path or remote device. Those are separate bottlenecks and should be diagnosed separately.
Why can an NVR become overloaded?
Overload occurs when one required task reaches its own limit, even if the other capacity figures still look comfortable. The symptoms therefore vary. Cameras may disconnect or drop recording when incoming capacity is exhausted. A local grid may become slow when decoding capacity is reached. Remote playback may hesitate when outgoing traffic or an uplink is constrained.
What determines NVR camera capacity?
Practical NVR camera capacity is the lowest applicable limit: supported channels, incoming bandwidth, outgoing bandwidth, decoding capacity, network path or storage write capability. The camera total printed on the recorder is not permission to use every channel at any stream setting.
Bitrate peaks are a common planning difficulty. Outdoor scenes can become more complex when foliage moves, headlights cross the frame, IR reflects from nearby surfaces or image noise increases. At a street-front business, customers, traffic and changing displays can create sustained motion. When several cameras become busy together, their combined load matters more than any single stream.
The recorder is also only one part of the path. A PoE (power over Ethernet) switch can have adequate power yet an undersized or congested uplink. Traffic may cross several switches before reaching the NVR. Remote viewing can then share the same link used by incoming camera streams. Map the direction of each flow instead of treating the network as one undivided capacity figure.
A system is limited by the busiest shared path and the first recorder resource that reaches capacity.
Separate throughput from storage
Bitrate is the common input to both calculations, but throughput and retention answer different questions. Throughput asks whether the recorder can process the streams now. Storage asks how much recorded material the installed disks can hold under the selected recording schedule.
Retention planning must account for the combined recorded bitrate, recording hours, event behaviour and desired retention period. Recording throughput remains relevant even when retention needs are modest. A recorder can have ample disk space yet be unable to accept the complete incoming stream load.
Playback adds another distinction. Reading stored footage and sending it to users creates disk and outgoing network activity while recording continues. Simultaneous export can add a further sustained load. The design check should therefore include recording, local viewing, remote playback and export operating together.
Adding disks or external storage expands retention only. It does not automatically increase incoming bandwidth, outgoing bandwidth, channel support or decoding capacity. The reverse is also true: a recorder with generous processing capacity may still need more storage for the required recording period.
Plan for the Israeli property
Property type changes the stream calculation. In an apartment building, a private apartment system may cover the door and interior while shared entrances, parking areas or lifts belong to a separate building arrangement. Establish which feeds will actually reach the apartment NVR. A shared-area camera should not be included in the calculation merely because it appears relevant on a floor plan.
Private homes often need detail at a garden gate, driveway and pedestrian entrance. These views can include moving trees, strong sunlight and deep shade in the same frame. WDR (wide dynamic range) can help the camera represent bright and dark areas, but its image processing and the changing scene still need to be tested with the chosen bitrate.
Street-front businesses generally present a different load. Entrances, tills, aisles and pavement-facing views may remain visually active for long periods. A configuration tested in an empty premises may not represent normal operation. Review the stream rates while displays, people, doors and exterior traffic are moving.
Dust, coastal humidity and glare affect camera placement and image quality. A dirty cover, direct sun or IR reflecting from a wall can add haze or noise. Besides reducing useful detail, that unstable image can be harder to compress. Good positioning and routine cleaning are therefore relevant to both image quality and bitrate behaviour.
A mamad, the reinforced safe room found in many Israeli homes and workplaces, must be considered when planning network routes. Reinforced walls can make wireless paths less predictable. If the NVR, internet router or viewing point is inside or beyond the mamad, plan a wired path where practical and check the complete route before fixing equipment locations.
Choose capacity with useful headroom
Select capacity from the expected camera configuration, not from a channel label. The working schedule should show each camera, its main-stream bitrate, any substream used for viewing, recording mode and likely concurrent access. Compare the aggregate load with every relevant recorder limit.
Unused capacity is not waste. It accommodates variable bitrate peaks, changes in night-time image noise, additional viewers and later adjustments to frame rate or image quality. It also allows a future camera or a more demanding replacement to be considered without automatically replacing the recorder. Headroom should be deliberate, not whatever happens to remain after the calculation.
- Confirm the maximum supported camera channels separately from incoming bandwidth.
- Check the incoming limit against the complete main-stream total, including relevant audio or additional streams.
- Check outgoing capacity against expected live viewing, playback and export occurring together.
- Check decoding capacity against the intended local display layouts and playback use.
- Verify the switch uplinks and other shared network paths in both traffic directions.
- Calculate storage retention independently from all recorder throughput limits.
- Document future cameras or setting changes already being considered.
Capacity figures should be obtained in writing and read with their conditions. A decoding specification may apply only to a particular combination of stream demands. An incoming figure may differ from the usable total once other functions are active. If the documentation is ambiguous, design to the confirmed capability rather than the most generous interpretation.
Final validation should reproduce simultaneous use. Record all cameras at their planned settings. Open the normal local grid. Start remote live viewing, retrieve playback and perform a representative export. Then inspect camera status, recording continuity, stream selection, processor load and network interfaces. This checks the installed system rather than a collection of isolated specification figures.
The strongest recorder choice is not necessarily the one with the largest headline number. It is the one whose separate limits are understood, documented and comfortably aligned with the cameras, network and viewing habits of the property.
Key takeaways
- Channel count is not a substitute for checking the recorder’s incoming, outgoing and decoding limits.
- The combined bitrate of all main camera streams determines the incoming recording load.
- Remote viewing and local multi-camera display place different demands on the recorder and network.
- Storage retention must be planned separately from recording throughput.
- Useful capacity headroom accommodates bitrate variation, concurrent use and later configuration changes.