Hardware sizing for IP cameras

A

amnixed

Hello Readers,

I'm seeking advice on hardware recommendations for a server which needs to serve IP cameras and make live or recorded videos available.

The setup will have 8 cameras (HIKVision DS-2CD2132-I). The claimed frame rate is 30 fps with 1920 x 1080 resolution, and the highest reasonable frame rate/resolution would be used. The cameras would be recording 24/7.

1) What kind of hard drive(s) are the best for this purpose? High RPM traditional drive(s), such as a Seagate Cheetah 15K? Are SSDs a good choice for continuous video recording?

My understanding is that large files and streaming entails mostly sequential reads/writes, and little random reads/writes, am I correct?

2) Is there an advantage to split the 8 cameras over 2 or 4 NICs/LANs/VLANs (viewers/clients would be served over a separate NIC/LAN) for a total of 3 or 5 NICs?

3) How much RAM would be comfortable assuming 4 simultaneous viewers of live video?

4) CPU: Would an Opteron 6320 be sufficient, for example? Is that overkill?

Any other hardware considerations?

Many thanks for your insight!
 
I had a video recording server at a prior job that became my responsibility for a short time mainly because I was the closest person there. I'll lend whatever advise I can remember based off that.

amnixed said:
Hello Readers,

I'm seeking advice on hardware recommendations for a server which needs to serve IP cameras and make live or recorded videos available.

The setup will have 8 cameras (HIKVision DS-2CD2132-I). The claimed frame rate is 30 fps with 1920 x 1080 resolution, and the highest reasonable frame rate/resolution would be used. The cameras would be recording 24/7.

1) What kind of hard drive(s) are the best for this purpose? High RPM traditional drive(s), such as a Seagate Cheetah 15K? Are SSDs a good choice for continuous video recording?

My understanding is that large files and streaming entails mostly sequential reads/writes, and little random reads/writes, am I correct?
Click to expand...

The system I worked on had 12 3 TB WD Green drives if I remember right. WD even makes drive specifically for recording from 24/7 cameras now, the WD Purple drives. It does seem like you are vastly overestimating your needs thinking 15K drives and/or SSDs. I don't mean to advertise, but looking at the datasheets for the Purple drive may be a good start to helping determine your needs.

amnixed said:
2) Is there an advantage to split the 8 cameras over 2 or 4 NICs/LANs/VLANs (viewers/clients would be served over a separate NIC/LAN) for a total of 3 or 5 NICs?
Click to expand...

I searched for "1920x1080 mpeg4 bitrate megabytes per second". The first result mentioned 1920x1080 weighs in at around 30MB in file size per minute. Unless your cameras are streaming uncompressed video, you should be fine with a NIC or two. Mainly, it makes more sense to divide things for security. From what I remember, the cameras were all some 5-10 year old embedded Linux, think 2.4 kernels, and the manufacturers don't do security updates on them. Keep them off anything close to a publicly accessible network. In other words, have a NIC/VLAN that only talks to cameras and a NIC/VLAN that only talks to clients.

amnixed said:
3) How much RAM would be comfortable assuming 4 simultaneous viewers of live video?

4) CPU: Would an Opteron 6320 be sufficient, for example? Is that overkill?

Any other hardware considerations?

Many thanks for your insight!
Click to expand...

If you are only archiving and streaming already compressed video, the RAM and CPU usage shouldn't be extreme.

My advise, look around at some of the commercial video recording products to get an idea on how their specifications. If you are going to go the route of setting up your own, drawing some ideas off other products would be a big time saver.
 
I have some of the similar 3 MP barrel cameras, as well as the 1.3 MP cameras. I think they work very well.

The purpose of your surveillance has a big impact on the quality of video required (both frame rate and resolution), as well as how long the video record has to be saved. One hour? One day? One week? For the statute of limitations (multiple years)? If you have to keep video records for more than a few days, can you offload video to an archive after some period of time?

There can be a big difference between watching an employee entrance that is very busy for a few minutes three times a day (and hardly used at all otherwise), and a customer service counter at a busy retail store.

Most people find that for "normal" surveillance 5 or 6 frames per second is just fine. For watching somebody manipulate small objects (counting money, dealing cards, etc.) or other "detail" surveillance then you need tight focus with high pixel and frame rates (and that generally means lots of cameras, too). If your goal is to read license plates on vehicles entering and leaving your premises then you will need pretty tight focus to be able to read them at 3 MP (experiment with it and you'll see). In that case vehicle speed will probably determine the frame rate requirement.

It matters an awful lot what software you are going to run to record the video. Storing the H.264 stream just as it comes from the camera would probably give you the least storage and processing requirements. Is that what your software will do? My big question about this is if something happens when nobody is there, and you have to find a video record of the event, and you don't know what time it happened, how will you do that? Watch 24 hours worth of video at 30 frames per second? Can your software post-process the video stream to identify motion so you can completely skip the useless parts? To me, that is the advantage of video surveillance software that records events (i.e. you follow the timeline and skip all the dead time, but your motion detection and/or other triggers have to be configured to work really well).

Some software (e.g. ZoneMinder) converts incoming video to a series of JPEG images for use in motion detection, and then records it that way. That is not necessarily bad, but it certainly increases the CPU requirement (all the time for motion detection) and disk space/bandwidth requirements (while recording).

You might find that the only practical way to estimate your LAN, CPU, and disk requirements is to build a test system with your proposed software, and record a video stream with a relatively high motion level (because H.264 compression mostly sends the image changes) and measure the LAN, CPU and disk bandwidth and space needs.

When you are estimating your hardware needs don't forget to account for somebody (or multiple somebodies) watching and/or exporting previously recorded video while you continue recording.
 
1. Reading the data sheet each camera will output 16mbit/s tops, 16 * 8 = 128 mbit/s so 16 mbyte/s. As long as you use decent mechanical drives you'll be more than fine using a simple RAID 1 array (ZFS preferable). 2TB of storage would last about 36h so depending on how long you want to hold on the footage you might want to consider a RAID 5 array instead. That said, WD Purple etc are just low RPM drives with spin down disabled at a premium price. If I were you I'd have a look at something that plays nice with RAID/HBA cards such as the Toshiba DT01ACA series Toshiba (DT01ACA200 being 2TB, Toshiba DT01ACA300 3TB) and connect these using builtin Intel AHCI controller and/or a LSI card (9210-8i or a clone/variant of it in IT mode).

2. No, given the reasons above it's just a waste of time.

3. How? Usually the frontend (client) is used on the client computer which doesn't depend on performance of the storage server.

4. As for storage an i3 CPU would be more than enough irregardless of file system.

Uniballer:
Yes, this matters indeed. You could also use ffmpeg to read the streams (off the cameras) and output in X chunks with timestamping but it would require transcoding. I do however except the camera to do this. You would probably need to play around a bit first to see how well different compression algorithms scale (you'll have much lower load using MPEG4 instead of H.264) but it might not matter as x264 is very well optimized these days.
//Danne
 
diizzy said:
1. Reading the data sheet each camera will output 16mbit/s tops, 16 * 8 = 128 mbit/s so 16 mbyte/s.
Click to expand...
That multiplies out to about 10 TB per week.
You could also use ffmpeg to read the streams (off the cameras) and output in X chunks with timestamping but it would require transcoding. I do however except the camera to do this. You would probably need to play around a bit first to see how well different compression algorithms scale (you'll have much lower load using MPEG4 instead of H.264) but it might not matter as x264 is very well optimized these days.
Click to expand...
To the best of my knowledge, the HikVision cameras mentioned by the OP only support H.264, so transcoding is required for anything else.
 
You must log in or register to reply here.
Back
Top