Migrating Casino Surveillance System To IP, Suggestion?
I am currently in the process of finding a new surveillance system for the casino I work at. Currently we have between 700-800 analog Pelco cameras and run a hybrid system (digital recording on NVRs and monitoring/control through an analog matrix). We are looking to move away from the analog matrix to a virtual one with a system that will easily allow us to utilize the 700+ cameras we have now, but also migrate in IP cameras as time and money allows. Through my own research and observations I've found a few I like and/or am interested in so far (Avigilon, Indigovision & Genetec). If anyone has experience with these that they'd like to share, or other options they'd like to throw out there it would be very much appreciated. Some key factors for me would be:
Reliability with redundancy (can not afford video loss or downtime)
LATENCY
User interface (useful tools with easy navigation)
Cost (have a decent budget, but not unlimited)
There are obviously other factors to consider such as video quality, but the ones mentioned above seem to separate the systems I've looked at.
Thanks so much
Hi Adam,
The casino I work at just went through the same process. We had a Pelco 9780 matrix and Honeywell NVR system. We spent almost a year evaluating a number of systems and wound up going with IndigoVision.
Evaluations were done in two phases: the first, about a week long for each system, evaluated the basics - ease of use, quality of video, latency, playback functions, bookmarks, clip creation, etc. Many of the evaluation systems fell by the wayside during the first stage, including Avigilon, Pelco Endura and Genetec. The second phase evaluated the remaining three systems in depth and lasted about a month for each system. Dallmeier was eliminated in Phase 2, leaving us with Geutebruck and IndigoVision.
We also evaluated a number of third party encoders, including Axis, Bosch, Sony, TKH and Verint and IP cameras, including Axis, IndigoVision, Bosch and Ganz during Phase 2. Testing revealed a virtual tie between three of the encoders: IndigoVision's own, the Axis Q7406/Q7900 and the Bosch X1600XF. We requested the Axis encoders when soliciting bids for the Geutebruck system (we were not impressed with Geutebruck's own encoders) and the IndigoVision encoders with the IndigoVision system (for obvious reasons).
Three Integrators were invited to bid on both systems, however Geutebruck was only offered by one Integrator - a major cause of their elimination in the final RFP analysis.
IndigoVision was chosen because the system offered a good mix of features, among the best picture quality for their encoders, reasonable price which gave good "bang for the buck", warranty options and their willingness to work with us on system improvements and feature requests.
System installation was basically completed on December 20, 2013 although final tweaking took a few more weeks. We are happy with the system and our decision to go with a virtual matrix. Doing so gives us a lot more flexibility while reducing system footprint and power and cooling requirements by at least 1/3. In the end, the reduction in power and cooling requirements will save the casino substantially.
Along with the basic system, we purchased five full years of warranties, support and upgrade licenses. That rolled those costs into the casino CAPEX, making Accounting happy.
I'll be happy to answer any questions but will be out of touch for two weeks so be patient for a response.
By the way, the new system is set up for 1,200 inputs, 960 analog and 240 IP.
Carl,
how you manage the servers and the storage for such system?
Hernan,
We use a combination of IndigoVision's built-in applications, Dell's server and storage tools (IV's high end servers are made by Dell) and a few other apps. We also allow limited and controlled remote access to various responsible parties to remotely troubleshoot and update the system as required.
The latter was something we wrestled with greatly. We strongly resisted allowing remote access to our last system (Honeywell Enterprise). That made troubleshooting by manufacturer and Integrator almost impossible so we had to learn and manage almost every aspect of the system.
In the end, we compromised with our vendor and have a firewalled lock box plug-in connection with the additional requirement that management monitor and record all remote sessions. I know some would feel we are taking security too far but that was a regulation policy requirement.
How is your current system working? Why do you want to change to IP?
Avigilon also has several casino installations. Some of their largest deployments are in the casino market. Something to consider with casinos specifically is on the video review. Video review is done super quickly in Avigilon with almost zero latency.
Apparently, table reviews have to be performed anytime someone wins even the smallest amount of cash, thus searching is done often. This is where Avigilon differentiates itself in the market. Time is money.
Bonus points: Avigilon manufactures their own encoders which is perfect for migrations as you have described. Each 4 port encoder uses only a single video channel license where as many other systems charge for each video channel individually. With Avigilon, you can migrate 4 cameras for the cost of a single encoder and a single license.
Good luck in your product evaluations.
Mike,
Has Avigilon solved the severe latency and PTZ control problems we dicovered during our system evaluations? Measured latency through Avigilon encoders was >500ms; the highest of any system tested. Also, apparently, Avigilon's Pelco protocol didn't issue "Stop" commands so PTZs would continue motion for >1000ms after we released the joystick.
The combination of PTZ latency and run-on were prime reasons Avigilon failed Phase 1 testing.
One piece of advice (from me, an integrator), actually test your existing cameras with the new systems you are considering. Many... no, MOST manufacturers claim that they work well with '3rd party' cameras (which is what Pelco cameras will be to any other system)... and yet, in actual practice, they do not. You will then likely end up in "finger-pointing hell", caught between one or more of them and basically not getting your issues resolved.
Good luck in your hunt.
Allen,
Analog equals analog. No need to test the cameras, although I would recommend testing multiple encoders with open architecture systems.
As I stated, we tested a number of encoders before settling on Indigovision's own. Although the Axis Q7406/Q7900 tested the best for resolution, bitrate efficiency and overall picture quality, IndigoVision's own were close enough (perhaps tied with Bosch) that we decided to deploy them. Besides, the IV encoders have some advantages in terms of not requiring per-channel licenses and their ability to provide multiple simultaneous 30fps streams.
That said, I repeat that the OP's existing system is analog so there is no concern about IP compatibility. I would recommend testing a number of IP cameras with evaluation systems, though. Since installing the IV system, we have been evaluating more IP cameras than we did during our Phase 1 & 2 system evaluations, starting with PTZs.
We've found a number of compatibility issues with PTZs. Many aren't compatible with the IndigoVision VMS. Problems range from total inability to access cameras' video streams to poor control of pan/tilt functions. The former are typically due to the camera's inability to stream multicast video via ONVIF (Pelco Sarix and Sony) and the latter are most likely also ONVIF-related. So far, the best PTZ performance and compatibility have been demonstrated by IV's own PTZs (what a surprise) and by JVC. Bosch PTZs do work but control is "touchy".
"Analog equals analog"...
That said, the rule doesn't apply when considering 960H and other high resolution "analog" cameras. One thing to consider when changing from full analog to virtual matrix/monitor wall systems is that the encoder becomes the primary limiting factor for "live" viewing. We found severe loss of detail with every encoder we tested - obviously, the limiting factor being encoders' 4CIF/4SIF/D1 maximum resolution, and increased noise caused by compression.
We found a number of ways to minimize the losses, including increasing bit rates over those suggested (running all fixed cameras at 2.5 to 3.0Mbps and PTZs at up to 5Mbps). We also adjusted the encoders' GOP structure and other settings.
In the end, we've found a combination of tweaks can help but the only real cures involve camera replacement and/or adjusting our expectations.
Carl,
Your posts are always detailed and relevant and I enjoy reading them. I, for one, thank you for the education they provide. You make salient points and I always learn something from them.
To sum it up:
Going from a high-quality analog matrix system to a virtual matrix/monitor wall system involves a number of trade-offs. What you gain in flexibility and the ability to view HD video is often partially offest by what you lose in terms of "live" picture quality on your analog cameras, though "playback also equals playback". By that, I mean that given equal playback video quality between the "old" and "new" systems (in our case, the Honeywell Enterprise system's recorded video quality was essentially on par with IV's when set to approximately the same encoder settings), you should consider the other ramifications of replacing systems.
With an analog matrix, high quality analog cameras and high quality analog monitors allow better video quality for "live" viewing than playback can possibly reproduce while with a virtual matrix/monitor wall system, the two qualities are often the same.
There are some other possible "fixes". One possibility depends on the new system's capabilities. If the system can accomodate it, you can feed two independent streams from your encoders: one at very high quality for "live" viewing and one at reduced quality for recording, to conserve storage requirements. The other is the path we chose: replace critical analog cameras with IP MP cameras, along with "kicking up" the encoder settings in general.
A final thought: when we considered our final path, we knew it entailed upping the storage requirements. That was something we actually had to argue with our vendors about during RFP negotiations. The manufacturers and Integrators all felt that we over-specified the required amount of storage. We specified 700TB net after subtracting storage overhead while vendor recommendations ranged from 350TB to 600-something TB.
In the end, we won the arguments ;-)
We wound up with a lot of empty space and longer retention times than required but that includes allowance for over 200 additional cameras' expansion capability.
When discussing storage, I recommend using worse-case scenarios to compute requirements. I multiplied 3Mbps (encoder setting) times the number of cameras and used 100% continuous motion. I also used 5Mbps for analog PTZs, 4Mbps for 720p cameras and 8Mbps for 1080p cameras. All at 100% motion.
I also considered storage overheads like parity, hot spare drives and Windows overhead.
One thing I learned from the HE system: it is always better to have too much storage than too little. If you have too much, you can increase retention times and/or improve picture quality. If you have too little, your options are severly limited.
Newest Discussions
| Discussion | Posts | Latest |
|---|---|---|
|
Started by
Ethan Ace
|
8
|
less than a minute by Undisclosed Manufacturer #5 |
|
Started by
Jay Hobdy
|
7
|
less than a minute by Jay Hobdy |
|
Started by
Brian Rhodes
|
13
|
43 minutes by Daniel Tyrrell |
|
Started by
Adam Morrison
|
5
|
less than a minute by Undisclosed Integrator #3 |
|
Started by
Undisclosed Integrator #1
|
6
|
less than a minute by Undisclosed Manufacturer #2 |