You didn't specify retention time so I would specify 4TB for 7 days. Obviously more storage for longer retention times.
I mentioned storage duration in the first sentence above. I left it out of the poll because I am not sure if everyone could normalize for that. For discussion purposes, we can assume a month, which would put you at ~18TB.
You must be using megapixel or HD cameras for 18 T. I was assuming standard high resolution which 4 T would cover 15 FPS for a month at 2 CIF with 30% recording during 24 hour period.
I don't want to speak for Carl :) but I will take a guess - He's using continuous recording 4CIF / 30fps, I believe MPEG-4
IPVMU Certified | 05/05/13 12:25am
9TB to 12tb has been the general averge lately.
John, I assumed 720p30 @3Mbps h.264 for 7 days equals 4TB and you're right. That would translate to ~18TB for a month.
Carl, I didn't know you were a 'megapixel man' now? and H.264? ;)
Shocking, isn't it ;^o And for my next trick...
Actually, for our new system I'm specifying:
- 3Mbps @ D1/30 for 720 analog fixed cameras @ 15 days = 334TB
- 5Mbps @ D1/30 for 160 analog PTZ cameras @ 15 days = 124TB
- 3Mbps @ D1/30 for 80 analog fixed cameras @ 60 days = 148TB
- 5Mbps @ 720p/30 or 1280x960/30 for 240 IP fixed cameras @ 15 days = 185TB
All cameras h.264 at 100% motion (I hate underestimating storage). My total storage estimate is 791TB (call it 800TB) for all cameras plus parity drives and cold spares.
By the way, raw storage will actually exceed 1PB since I'll be specifying 8+2 parity and at least one hot spare per chassis.
Carl, thanks. Slightly off topic, but how did you get 5Mb/s for the 720p/30? That's CBR, right? Why not 4Mb/s or 6Mb/s? Or VBR?
5Mbps was determined by my tests of IP cameras. That is the bitrate I determined provided smooth picture quality with little compression noise.
We will be using Axis P3354's unless they release a version with manual lenses (they have expressed an interest in doing so). I set them at CBR, although I also tested VBR. In actuality, Axis' CBR is "constrained bit rate" so their cameras can settle down a bit with no motion.
Still, I refuse to underestimate storage and would prefer to err on the conservative side. Besides, when the initial 240 IP inputs are filled, I would prefer to have sufficient storage to replace analog with IP without having to buy additional storage. We could probably live with 3Mbps on 720p, depending on the application.
Carl, thanks. What do those Axis P3354 cameras settle down at? i.e., what's the no / minimal motion bit rate?
By the way, I tested both Axis' Q7406 and IndigoVision's h.264 encoders at bitrates ranging from 1.5Mbps to 5Mbps and found that, except for PTZs, there was no perceptible improvement beyond 3Mbps. PTZs required the higher bitrate during movement to smooth out artifacting.
I also tested a number of IP cameras and found the Axis P33xx had the best image quality by far. Testing bitrates ranged from 2Mbps to 8Mbps and I found that 5Mbps gave very acceptable image quality.
Remember, we are eliminating our analog matrix so I want to provide the best "live" image quality I can within the constraints of our budget.
The Axis cameras tended to settle down to around 3.5-4Mbps with no motion, depending on what "quality" I plugged in. I believe I settled at 80-90%.
Axis' quality scale goes from 0 - 100, defaulting at 30, with lower numbers meaning less compression and higher numbers meaning more compression / lower quality. Here's the config section:
Do you recall what you set it to?
Yes but the VMS' settings specify "quality", rather than compression level. Not sure how the two figures equate.
The relationship depends on how the VMS manufacturer mapped Axis's scale to theirs. It could be Axis 30 is mapped to their 50% but the only way to know is to ask them.
Alternatively, you could measure the quantization level yourself of different quality settings and then get the 'real' numbers.
One thing we found from testing Axis camera compression levels is that, as one decreases the compression down from 30 towards 0, the bit rate tends to spike but the visible quality improvements tend to be minimal. In other words, such increases tend to have a poor quality improvement / bandwidth use ratio.
Well the point is moot for the next 5-6 months anyway. Once the system is at that point, I will probably configure the cameras myself and I may adjust bit rates down from my spec for certain apps. My figures are based on "worst case" scenarios and I will weigh image quality versus compression on a case-by-case basis as I get the opportunity. Again, I would rather have too much storage than too little.
By the way, there is a method to my madness (going megapixel). The new system will eliminate our analog matrix. The loss of resolution by going through encoders versus straight analog monitoring was too great so we have to replace the cameras in certain applications to meet our regulations, among them table games, where the ability to identify card suits is vital.
I did test other resolutions to get an idea what the tradeoffs were with scene clarity on gaming tables. VGA (640x480) was far worse than straight analog, with jagged edges obliterating the suit shapes. SVGA (800x600) wasn't much better, even though it was the closest resolution to our 600+-line cameras. XGA (1024x768) was the minimum resolution that met our goals but the "jaggies" were still a bit annoying.
Higher resolutions were wasted as they offered no visible improvements while requiring substantially higher bitrates.