What VMS Hardware Do I Need For 16 2MP H.264 Cameras?

They are saying you need "2 units of i7 Intel PC" for 16 channels of H.264 2MP cameras? As in 2 physical machines with i7s? That sounds like overkill.

Who are the VMSes specifically that are recommending this?

For background, we cover this in our Specifying VMS Server Size tutorial.

The key driver typically in specifying VMS hardware is throughput. Let's be conservative and say you need 6Mb/s for each H.264 2MP camera - I am assuming here 30fps so this number may be too high.

Say 6Mb/s multiplied by 16 gives you ~100Mb/s.

Even at a 100Mb/s, it still should not be too much for a single server.

Questions:

• What's the fps you plan to use? What are you estimating the bitrate to be?
• Are you planning on using server side motion detection?
• Do you need to do local viewing (i.e., the server doubles as a workstation for clients to monitor the video live)?

Milestone says you can run that setup on a pentium 4 machine with 2GB of Ram. I wouldn't try it because I feel the performance would not be good enough for my liking. Avigilon which in terms of pure size in MB is smaller than Milestone and they show these stats for a Server workstation configuration (local view). The link indicates an Intel quad core xeon 2.0Ghz with 2 Gb of RAM. Those stats will run up to 64 cameras. I run a workstation on an Intel i5 at 3.2 Ghz with 8 GB of RAM and a 2GB video card. A mid level consumer system by todays standards. I havent tried this yet but I planned on running 16 cameras on my system with little worry. I can't imagine requiring dual servers unless you were looking for failover protection. I looked at a ton of VMS recently before purchasing and not a single one required two physical servers. Now maybe your getting confused with dual core processors or the other possible scenario a server specification that says it needs dual processors. In the world of IT that could mean two physical processors on one board. Just FYI an Intel Core i7 entry level is a quad core processor. Four processor cores on one physical chip. The question about linux versus windows you ask if you can run 32 cameras. Short answer yes. Linux systems can run 32 cameras, but you asked it in the context of the above discussion which you limited your windows system to 16 cameras. If you are thinking that you can double your camera count and all you are changing is the operating system I would say no that won't happen. I will venture out here and say camera counts rely on hardware more than software to achieve their camera count goals. As an example if you ran a supercomputer with a VMS and an old windows computer from say even five years ago with the same VMS side by side the supercomputer would run more camera count hands down. It is all based on the level of hardware available. With that in mind I would like to see the specifications from the place where you got your information to verify what I believe is happening here. I think there might be some confusion in what you are reading or the specification from this company has a major typographical error.

Hello Marcus, I don't see anything wrong with your inputs, but if I had a VMS telling me those requirements for hardware I would go looking somewhere else. Not very CPU efficient does not even begin to describe this situation. Like John said who are these people? I trust your imputs I just don't believe your results are accurate and I don't understand what the cause would be. Either CPU inefficientcy or a buggy calculator. Try a different calculator from someone elses VMS and I can almost asure you of better hardware utilization. Those are incredible results. Ones that I wouldn't use if I had to base my decision strictly off a calculator like the one shown in your screenshot. Good Luck

Hi all, here is another screen capture that I done.

It is showing another VMS which indicates that a single PC with i7 CPU (41% CPU usage) can handle:

1) Local Display + recording

2) Server side motion detection

3) Remote viewing or local networked Client PC remote viewing

supporting 16 2MP H.264 cameras @ 25fps @ 50% complexity (H.264 compression is based on Baseline Profile)

Perhaps, John's IPVM team should do a round of investigation in terms of testing which VMS in the market is more CPU efficient?

:-) Just to make a comparison and see why customers are paying $$$ big bucks in spending good VMS.

This is really not simple question, because it depends on many technological aspects. Most simple case is just recording without server-side analytics and local viewing. In this case we don't need to decompress stream, so it is just copying stream to the disc. P4 is enough. If we need analytics or viewing, then we need to decompress the stream and this is really hard for CPU. Normally, single i7 can't decompress 16 2Mp H.264 25fps each. For such job we need 2xXeon system. But, if I have 4 layouts with 4 cameras in each, single i5/7 will be enough. What other tricks we can have to work with single CPU? VMS can support dual streaming in the way, when you switch to layout with 16cameras, it will request lower resolution streams. For analytics, some system can use only I-frames, so decompressing will be not very consuming or request lower resolution stream. And finally, system can utilize GPU for decompression, but this works only for viewing. For analytics still need to decompress to normal memory.

As for recommending hardware, we are also on conservative side when calculating. We suggest not to load CPU for more than 60%. And all our calculations based on real tests, that is why in our form we ask for camera vendor and suggest wide range of different CPU models. Click here for calculator.

Yes, typically it is just 1fps. When we say about motion detector (not object tracking) there is no any issues with accuracy. During 1sec any motion will be even more obvious. Slow motion can be missed when comparing frames between 40ms. That is why usually in such detectors everyone has buffer to compare with 1sec old frame and even 5sec. The only reason to compare with each frame is to detect motion earlier. But why not to setup pre-alarm recording for this second? So, if we detect motion by comparing current frame with 1sec old frame, then we start recording, but first flush 1sec from pre-alarm buffer. In this case we'll not miss any motion and save a lot of CPU resources.

Also good way is to use camera embedded detectors. Now almost every camera has and we support all of them.

Our testing has shown that i5 CPUs may have difficulty rendering high framerate/high resolution video images. We have seen issues with as few as 9 2MP cameras at 30fps. We believe this to be some sort of bottleneck in the bus structure of the chip. We recommend either i7 or E5 CPUs in our specifications.

We have not tested every variation, however, it seems to be a recurring theme. We also had issues with a HP Z400 that met the minimum specs, and had an i7 CPU, but would not reproduce over 270 fps total. We provided HP with the VMS and some test clips and they could not determine the issue. We thought that it was a bottleneck in their motherboard bus. The end user replaced the HP machines with Dell T-3500 with the exact same CPU and video card, and had no further issues.

Not implying anything. Just reporting issues I have seen in tech support and on several jobsites. With the HP Z400, we could display nine cameras at 1.3MP/30 fps just fine. After adding a 10th camera, it looked like a time-lapse recording on all tiles. We were able to display 20+ cameras on the Dell. We put the Dell video card (Nvidia NVS295) in the HP with the same results. We put the HP video card (Nvidia Quadro 4000) in the Dell and it worked fine. Both units had the same Intel W3670 CPU and 4GB of RAM. Where was the bottleneck? We could not determine that, and frankly, it was not our responsibility to do so. We assumed it is in the motherboard.

We never had issues with different chipset. In any case, when performance was lower than expected from particular CPU, the problem was with:

-insufficient memory

-graphic card

-network card

and never chipset.

We received a response from Luxriot development. Essentialy they said the calculator is outdated by not offering higher end or more recent server options such as those with higher cores/thread counts or more chip sets in one PC, hence the reason calculator recommended 2 or more PCs to accommodate 16 cameras.

Moreover, Luxriot says they recognized the limitations of Server Side MD and local client viewing and have suggested 2 improvements (B is currently in beta testing and slated for release by EOY):

A. Use of Multistreaming. The hardware calculator does not take that into account.

B. Implemented a new motion detection mode that "..will reduce CPU load by 10x by not decompressing full video and again using sub stream for MD"

With these modifications, here is their provided new hardware requirements:

"So as an example if both options will be used (sub stream at D1@25fps for live view and new motion detection mode):
Single high performance Intel CPU (for example i7-3930K) will be able to handle 32xFullHD@25fps stream for recording by new software MD and live view (sub streams) for all streams at a time."

Since surveillance is a highly parallel process, having more physical cores is highly desirable to deal with the multiple video streams. Although an i7 performs better overall, it is also at a higher price point not only for the CPU but also for a quality motherboard that goes with it. Our favorite is the AMD FX8350, it is priced comparably to an i5 4570 at sub $200 and performs better than it. It is also a true 8 core CPU, not the same as an i7 which is really 4 cores with hyper threading to mimic 8 cores. Also notice that not all i5s are created equal, online benchmarks show a wide range of processing power within that family. We have also noticed that adding additional RAM past 8GB offered little improvement to performance if any, but RAM is pretty cheap these days.

We have done extensive PC load testing here in our company using various VMS's and basically you have to break down the functions into 3 categories.

1. Recording: This is very easy for the PC to do, all it does is take data received from the network card and write it on to the HDD. So most of the work is not done by the CPU but by the storage and network subsystems. We were able to achieve up to 500 Mbit/s throughput using the AMD CPU and onboard sata drives. That's only 50 MByte/s of writing speed which is nothing to brag about considering there are performance HDD's out there with more than 100 MByte/s sustained random write speed.

2. Viewing / Playback: This requires the PC to decompress the H.264 data as well as displaying it on the monitor. This is the part that kills the CPU and also requires a separate mid range video card. Using 10 cameras at 1080p / 30 FPS at around 5mbps each will fully saturate the performance of the above CPU. So that's only about 50 mbps of throughput of video stream viewing. However there is a trick for getting acceptable performance without breaking the bank to be discussed below.

3. Analytics: This part varied wildly between different VMS's, the kind of analytics, how it was implemented and most importantly the scene. We are skeptical for any calculator to provide a reasonable estimate and our advices is to only use the motion detection buit-in to the cameras. Any other analytics will have to be evaluated on a case by case basis.

Now the viewing trick. Since most PCs aren't connected to 16 individual monitors, all of the VMSs offers some kind of matrix viewing. So essentially you are dividing up your 1080p monitor into a minimum of 4 views. This lowers the resolution of each view to a bit more than VGA resolutions (960 * 540). Although not all VMS supports this function, those that do, can display secondary streams from the cameras while recording the primary stream.

You can further reduce the CPU usage by lowering the Compression Quality settings for secondary streams and it's not very noticeable in a high count matrix view. The result, even when using the PCs that we built/sell which supports 4 monitors simultaneously, you are still only viewing 16 VGA resolutions and this mid-range PC is well able to handle the task. For higher count matrixes you can lower the resolution and quality of the secondary stream even further to around CIF and still present a reasonable picture to the viewer.

Having more CPU cores simply means there is less context switching to remove unnecessary overhead. More info on it here.

That being said, the performance of each core is different among CPU models and most newer i7s trumps the 8350 in raw calculation power per core. Here is a good reference chart on CPU performance.

Our goal was to find a PC that gives a good performance / cost ratio for small/medium sized systems in the current market and we found the AMD CPU served this purpose well. You also have to consider the price of Intel vs AMD motherboards.

Our tests has been done using the below VMS's:

1. Our in house VMS PowerVideo+

2. NUUO Main Console

3. ExacqVision Pro

4. Milestone Xprotect Corporate

5. AxxonSoft Next Trial

6. GVD

The results are similar because everyone has to decode H.264 pretty much the same way. Some VMS even use the same open source decoder FFMPEG. The smart solution is to look for a software that is capable of viewing the secondary stream. Some VMS even does this automatically.