In evaluating this, I think it's important to specify whether one is planning to use hard drives or SD cards for the distributed recording / storage.
I'll take hard drives first because it is the more common approach.
If you look at bank branches or retail stores, as an example, they almost always implement distributed network recording (with DVR/NVRs) because the cost / availability of centrally recording all of their video is prohibitive.
The more debatable scenario is where you have hundreds or thousands of cameras all in one facility or campus with high speed connectivity throughout. There centralized recording is often preferred because it provides a single location to management, allows for ensuring redundant powering, temperature cool, and centralized storage 'pools' (SANs or NASes) that can be shared across all cameras.
Hard drive definitely, so the scenario is a city surveillance scheme, spread across multiple suburbs all a few km's away from the central monitoring/recording area.
At the moment most of the camera network infrastructure flows back to a central point across each suburb, and then gets returned to the main hub via long range wireless or fibre.
These central locations could be used to store the NVR's and I could see some positivity about backhauling on a reduced stream quality due to wireless limitations.
So when you say 'central points across each suburb', you mean distributed points? Are you saying there are a number of suburb distributed points where NVRs can go instead of the current central hub in the city?
There are great benefits to the general model.
IMHO the achilles heel of the entire concept is the "open" nature of the industry. That is, the interoperability required between cameras, servers, and clients is beyond what an open model can support.
From what you describe, it sounds like you have a network with several hops, possibly some bridging, and maybe even some routing.
Ignoring pros and cons of physical access to the recorders for things like maintenance/environment, etc., you're basically weighing two approaches:
1) Recorders closest to the VMS Client/Operators (again, from a pure networking not physcial perspective) will minimize latency when accessing stoed video and generally make the system seem more responsive.
2) Recorders closest to the cameras will minimize chances of lost or degraded video due to network latency, network outages, etc.
Increased costs might not be as bad as first assumed, since most larger deployments will end up with more than one recording platform anyway. So, you might end up with only 2x-3x the minimum amount of required equipment, even if you more than just 2 remote sites. There may also be cost savings in network infrastructure not having to aggregate all the data back to a single point.
The "best" solution might depend on how the overall system will be used, if it's weighted more towards real-time use and loss of recorded video is acceptable, then centralized recorders might be "better". If the system is likely going to be part of crime reduction/prosection, then you might want to ensure the highest chance of getting the best possible recording, which would tend to be recorders close to the cameras.
As you might see in some other discussions, there can be hybrid approaches depending on the equipment and budget. Multicast to both local and remote recorders. SD cards in cameras (generally not efficient for pulling video from, but "in case of emergency" far better than nothing at all). Unicast to multiple recorders, etc.
- Distribution lessens single point of failure impact of network issue.
- Lowers or eliminates head end cost (unless you want central parallel storage or archiving)
- Low site latency.
- Less requirement for supplemental HVAC (assumes the NVR count is low)
Downsides (many can be overcome with proper design):
- NVR more likely to be appliance-based and therefore propriatary (Good for integrator; maybe not so good for customer). Need to keep equipment current and is more likely (the Use of Windows XP is an example) with local NVRs.
- Depending upon site requirments you may have to add infrastructure support such as HVAC.
- Need to accomodate incident based demand (too many folks trying to sign on at once)
- Policies and training needed.
- Bad Guys sometimes look for the recording device and destroy it to cover their misdeeds.
- NVRs more vulnerable to local emergency incidents (fire, tornado, etc).
- Trips to site to fix issues then if recording were located centrally.
- Not sure, but is there a more limited number of thick client workstations available with NVRs than with a centralized platform?
For any system there will be pros and cons. But its the customer's requirements which dictates what system should be in place.
In Distributed Network Recording the advantages are more for a large and spread over surveillance system. Cost should not be considered to be a factor to determine whether to have Distributed Network Recording.
The following are important in multisite systems or a city surveillance system.
Low latency, immediate retrieval for quick response, bandwidth consumption for transfer of live and stored data.
I feel Distributed Network recording is better rather than a centralised recording.
Yes, exactly as you've said.
At the moment there's essentially a few central locations where we have anologue to fibre decoders which then hop back to the central location via fibre.
We also have a high number of encoders being distributed over wireless to the central location/decoders.
The vms in question pulls a multicast from the camera's as it is. One to record and the second to monitor.
System is definitely being used for crime reduction/prosecution however real time use is the big pull card as it prevents crime in action/ensures community safety
1. Bang on the money there, we are for the present stuck with, or investing heavily in a pty system. Which as the end client = very poor for open source & preferred multiple supplier choices.
2. hopefully should already be ok in this point
3. should only be the occasional clients logging in outside of the control room, and with the system architecture I belive (not too sure yet) that there is a transcoding device at the head end which handles out-streams
4-7 arent an issue
8. again unsure of.