Do ip video storage costs matter?

[jhonovich 0]

From time to time, we have discussions on the value of megapixel cameras and the importance of image quality.

 

The biggest problem I see here is the cost of storage. Even 16 camera systems can easily require tens of TBs of storage, which becomes a significant cost overall and on a per camera basis.

 

I have posted an analysis of what I think these problems are: http://ipvideomarket.info/report/problems_video_surveillance_storage

 

I know that a lot of members feel otherwise - that image quality is king and worrying over storage costs is a worry of the past.

 

I'd be interested in you reading my analysis and providing feedback.

[amirm 0]

First, let me say that I enjoy reading your articles. They are short and to the point .

 

On this front though, I think the poster "CameraMan" hit the right note. If you buy a NAS (or PC solution) with room to grow, then the incremental costs are what he stated. Namely, a 1.5 TB Seagate drive cost $130 to add, not $750 to $1000. Your answer to him that you need a new enclosure only holds if you blow past the capacity of the box you bought.

 

Amortized over the cost of say, 4 drives, the cost of the base engine is well below your estimate anyway.

 

Having said this, as I look at my own application with 8 cameras, with half at megapixel resolution, the amount does add up. Or else, you don't get to hold the video for as many days.

 

The advent of MPEG-4 AVC (H.264) over MJPEG and simple MPEG-4 implementation is also significant in saving some storage costs. This of course assumes that they are using a proper AVC encoder and not just something that is compliant with the bitstream but lacks the "tools" to provide full efficiency.

[amirm 0]

Also in reference to motion detection mentioned in the article and here: http://ipvideomarket.info/report/video_analytics_greatest_value__storage_reduction, I was surprised to see that this is a misnomer. In the one camera design where the algorithm was disclosed (I forget the brand), there is no real motion detection. But rather, the frame brightness is compared to previous one and if there is sufficienty change, then the camera declares that it has seen "motion." Needless to say, this will generate false positives in that if the light levels change, you wind up recording things when nothing of significance has occured in the image.

 

Now maybe it doesn't matter in grand scheme of things. But as a guy coming from signal processing/compression, it is kind of bothersome to see the wrong terminology used here.

[Soundy 1]

I largely agree with your points, particularly the first three.

 

What I don't fully agree with is this:

While hard drive prices look cheap, the cost of storage is significantly more than individual drive prices. For instance, today, a 1TB hard drive is about $100 USD. However, the total cost of 1TB of storage is closer to $750 - $1500. You cannot simply buy dozens of hard drives by themselves. You need management system, enclosures and hardware to connect all of the drives (e.g., NAS and SANs). While these are continuing to decline in price, the price is not negligible, especially for surveillance video which can easily demand many TBs per camera.

 

IMHO this over-simplifies... or over-complicates, depending on how you look at it. Specifically, the way you inflate 1TB of storage from $100 to $750+ is... well, 'alarmist' describes the attitude of it, I guess.

 

Adding 1TB to most machines is easy: open it up, plug in the drive, configure the OS/software to use it. In fact, with most decent motherboards these days including multiple SATA channels and onboard RAID controllers, putting 4 or 5 extra TB into a system need not necessarily cost more than the price of the drives themselves (unless you're using really cheap motherboards, which isn't advisable for a DVR in the first place). Even external USB, Firewire or e-SATA drives can be had for $50 or less over the cost of an internal.

 

Really, you don't usually get into the NEED for expensive NAS solutions until you're talking a half-dozen drives or more... at that point, you're probably talking about a pretty expensive system to begin with, for pretty high-end customers, where the additional money for the NAS system is not as big a concern.

 

The only other reason for such a system is redundancy and data security - RAID5 and RAID6, for example. If the data is that critical, the cost of the hardware to make it happen probably isn't a major concern - that will apply whether you need 10TB or 100GB.

 

At that point, the cost of the space itself is almost negligible: once you pay, say, $4000 for a RAID5 NAS enclosure, whether you're paying $50 each for 80GB drives or $100 each for 1TB drives becomes pretty much irrelevant; it's a mere fraction of the total cost. In fact, it's far cheaper to go with the bigger drives in this situation - three 1TB drives at $100 will give you 2TB with RAID5 redundancy at the same cost as six 80GB drives for only 400GB/RAID5.

 

The point of all this, is that I think you greatly overstate the cost of storage. By the time it really becomes a factor, you're getting into fairly high-end and expensive installations anyway, at which point it's a relatively small percentage of the overall cost.

[jhonovich 0]

Hi Amir,

 

Thanks for your thoughtful replies.

 

I agree with you about the lower cost when using internal storage or NAS. And for your application and for people using low camera counts, short durations or low frames, this should be fine.

 

The challenge that you get into is when you do larger projects with high frame rates and long durations. Then you need tens of TBs, exceeding consumer class NAS and internal storage.

 

And, yes, I agree with you about the importance of more efficient CODECs.

 

Finally, I agree that the industry is cavalier about the technically accuracy of terms used.

 

Cheers,

 

John

[jhonovich 0]

Soundy,

 

Thanks for your feedback. I agree with everything you are saying about lower cost for internal storage.

 

The only points I would question are:

 

1) A lot of customers are locked into proprietary DVR systems that charge way more for storage (this is the reality for 80% of deployments).

2) I think you start facing this problem of needing expensive NAS/SAN solutions at lower camera counts than you imply in your comment:

 

"Really, you don't usually get into the NEED for expensive NAS solutions until you're talking a half-dozen drives or more... at that point, you're probably talking about a pretty expensive system to begin with, for pretty high-end customers, where the additional money for the NAS system is not as big a concern. "

 

With megapixel cameras, MJPEG, high frame rates, continuous recording, etc., these storage costs can balloon very quickly. I can recount numerous anecdotes from just this year when mainstream end users where shocked about the size of the quote for storage (and had to make cuts to accommodate budgets).

 

I'd be interested in your feedback. I will update the article to reflect your input.

 

Cheers,

 

john

[Soundy 1]

1) A lot of customers are locked into proprietary DVR systems that charge way more for storage (this is the reality for 80% of deployments).

 

Well, in that case more storage is going to be an issue regardless of how much you need. That's something the customer has to weigh from the start (or something his salesman should bring up): if you're going to need a lot of space for your requirements, is it cheaper to get a $1500 dedicated system, where adding space is going to cost you $500/TB... or to just go with a $3000 PC-based system where you can drop in multiple TB at $100 a pop?

 

2) I think you start facing this problem of needing expensive NAS/SAN solutions at lower camera counts than you imply in your comment:

 

"Really, you don't usually get into the NEED for expensive NAS solutions until you're talking a half-dozen drives or more... at that point, you're probably talking about a pretty expensive system to begin with, for pretty high-end customers, where the additional money for the NAS system is not as big a concern. "

 

With megapixel cameras, MJPEG, high frame rates, continuous recording, etc., these storage costs can balloon very quickly. I can recount numerous anecdotes from just this year when mainstream end users where shocked about the size of the quote for storage (and had to make cuts to accommodate budgets).

 

Oh, for sure... but there you're running back into your first three points regarding resolution, compression, frame rates, motion detection, and other such considerations. It goes back to unrealistic customer expectations, and it's been an issue since long before megapixel cameras and terabyte drives.

 

Heck, these same issues of balancing cost with customer expectations existed even with time-lapse VCRs: do you want to pay more for a 16-channel MUX to add more cameras when four will really do, for example? And no, you don't have to pay $600 for a time-lapse VCR... you could pay $80 for an off-the-shelf home VHS machine, and get smoother motion, but you won't get multi-camera ability and you'll have to change tapes every few hours. And sure, now you've shelled out for time-lapse... now you have to decide whether you want smoother motion and higher quality but only get two hours on a tape, or very jerky motion and very degraded quality but you only have to change tapes once every four days...

 

And so on.

[jhonovich 0]

Hi Soundy,

 

I agree with you that this is not a new issue. The importance of the issue has simply moved back up as high definition is more heavily marketed.

 

By the way, the original article has been updated to reflect on our discussion.

 

Thanks,

 

John

[Soundy 1]

BTW, on the issue of customer expectations vs. cost, keep in mind this extends to the cameras themselves, too. When he was just starting out with his own company, my boss made a pitch to the local port authority: they listed all their specs for the types of views they wanted, and those were pretty extreme. He demoed a camera for them that did everything they wanted, including reading the text off the side of a building several kilometers away. They were blown away.

 

Then he told them what it would cost - I think the one camera alone was about $3k (and it wasn't even a PTZ). They were expecting the whole system - cameras, recorder, installation, everything - would be about a third of that.

 

In the end, he had them pretty much convinced, but then management changed (ah, bureaucracy) and the new guard decided they didn't need that kind of sophistication. What can ya do?

 

Point is, extreme tastes come with extreme costs; that's just the way it is, and your first three points demonstrate this nicely. Large amounts of storage, however, don't have to be "extreme" if you can settle for more reasonable "needs". Once your needs (or wants) move from the "reasonable" to the "extreme", expect the costs to inflate accordingly.

 

That applies to everything in life and business.

[survtech 0]

Once your needs (or wants) move from the "reasonable" to the "extreme", expect the costs to inflate accordingly.

 

That applies to everything in life and business.

Define the two.

 

In our casino, with 900+ analog cameras, we have approximately 300TB of storage, running all cameras 7/24/365 at 30fps and mostly D1 resolution with 14 days retention using MPEG-2. If we add some megapixel cameras with MJPEG, we will easily have to expand to 0.5PB or more.

 

That kind of storage necessitates RAID boxes; either DAS, NAS or SAN. The cost of empty 24-bay RAIDs is approximately $8,000 and 1TB enterprise drives (don't use desktop drives in RAID enclosures) are approximately $180 each x 24 = $4,320 so 24TB raw is approximately $12k. Net with a hot spare and RAID-6 striping would be 21TB. Add the cost of SAN switching and data path redundancy and the system can cost at least $1000 per TB.

 

Most enterprise systems would cost in that range. We're not talking mom and pop store systems here, but there are many apps that require that kind of horsepower: prisons, airports, large corporate networks and, of course, casinos to name a few.

[Thomas 0]

There are some ways to reduce some of the overhead. MJPEG isn't the most efficient codec for storage space. So why aren't more companies taking advantage of transcoding when dealing with MJPEG? The amount of loss in the image would be below what humans would notice and the space savings can be tremendous. It does require more CPU power but CPU power is cheap if it means the difference between a machine running 6TB in raid 5 or jumpping up to true managed storage like an EMC solution.

[Sawbones 0]

MJPEG does suck up storage space, but the quality difference between that and MPEG4 is significant (or at least it is on my DS2).

[survtech 0]

There are some ways to reduce some of the overhead. MJPEG isn't the most efficient codec for storage space. So why aren't more companies taking advantage of transcoding when dealing with MJPEG? The amount of loss in the image would be below what humans would notice and the space savings can be tremendous. It does require more CPU power but CPU power is cheap if it means the difference between a machine running 6TB in raid 5 or jumpping up to true managed storage like an EMC solution.

That's exactly what the Honeywell Enterprise and many other enterprise systems do. If it's done well, there are no perceivable problems with the video. There are, however, other downsides to using transcoders:

* The cpu power requirements of transcoding limit the number of IP (especially megapixel) cameras per server.

* In some cases, the transcoders limit frame rates.

* Transcoders must be custom-designed for each IP camera.

* Transcoding is, in effect, image manipulation and could be challenged in court.

[Thomas 0]

There are some ways to reduce some of the overhead. MJPEG isn't the most efficient codec for storage space. So why aren't more companies taking advantage of transcoding when dealing with MJPEG? The amount of loss in the image would be below what humans would notice and the space savings can be tremendous. It does require more CPU power but CPU power is cheap if it means the difference between a machine running 6TB in raid 5 or jumpping up to true managed storage like an EMC solution.

That's exactly what the Honeywell Enterprise and many other enterprise systems do. If it's done well, there are no perceivable problems with the video. There are, however, other downsides to using transcoders:

* The cpu power requirements of transcoding limit the number of IP (especially megapixel) cameras per server.

* In some cases, the transcoders limit frame rates.

* Transcoders must be custom-designed for each IP camera.

* Transcoding is, in effect, image manipulation and could be challenged in court.

 

Transcoding doesn't represent a frame rate limiter unless your CPU power is very low. Nor does it need to be custom designed for every camera, it simply requires the decoder for that camera. Which you would need anyway for the viewing of the camera. And for MJPEG the encoders and decoders are fairly interchangeable. Compatibility problems are extremely unlikely. As far as the manipulation argument, it's no different then the original encoding of the video. If that argument holds then all IP camera video and all DVRs would be tossed.

[amirm 0]

Transcoding doesn't represent a frame rate limiter unless your CPU power is very low.

Can you provide some specifics? In the world of digital video where I come from, encoding in HD at 1080p (2 megapixels) is barely doable with the latest quad core CPUs at 24fps. And that is a single stream. Increase resolution up to 3 or more and the job becomes even more difficult.

 

Sure, you can take shortcuts and produce compliant streams but quality will not be there.

 

Nor does it need to be custom designed for every camera, it simply requires the decoder for that camera.

I can see both sides of this argument. One may want to optimize the data rate for example for the camera in use. A night camera with a lot of noise may need to be encoded at higher bitrate as opposed to one with plenty of light. And of course, if the cameras are not identical, then the settings will not be either.

 

Which you would need anyway for the viewing of the camera. And for MJPEG the encoders and decoders are fairly interchangeable. Compatibility problems are extremely unlikely. As far as the manipulation argument, it's no different then the original encoding of the video. If that argument holds then all IP camera video and all DVRs would be tossed.

I would imagine in either case you need to show that manipulation is difficult. I think most people would agree that modifying a camera's encoder is much harder than some PC software performing the same function.

[survtech 0]

Transcoding doesn't represent a frame rate limiter unless your CPU power is very low. Nor does it need to be custom designed for every camera, it simply requires the decoder for that camera. Which you would need anyway for the viewing of the camera. Compatibility problems are extremely unlikely. As far as the manipulation argument, it's no different then the original encoding of the video. If that argument holds then all IP camera video and all DVRs would be tossed.

Obviously, you've never worked with the Honeywell Enterprise NVR system!

 

And for MJPEG the encoders and decoders are fairly interchangeable.

For viewing the original data stream, yes. For transcoding, not necessarily.

[Thomas 0]

Transcoding doesn't represent a frame rate limiter unless your CPU power is very low. Nor does it need to be custom designed for every camera, it simply requires the decoder for that camera. Which you would need anyway for the viewing of the camera. Compatibility problems are extremely unlikely. As far as the manipulation argument, it's no different then the original encoding of the video. If that argument holds then all IP camera video and all DVRs would be tossed.

Obviously, you've never worked with the Honeywell Enterprise NVR system!

 

You're right. I wouldn't work with that system.

 

And for MJPEG the encoders and decoders are fairly interchangeable.

For viewing the original data stream, yes. For transcoding, not necessarily.

 

For MJPEG, yes. The wonderful thing about old standards is they are pretty stable. The difference between transcoding video and displaying it is what you do with it after decoding.

 

Can you provide some specifics? In the world of digital video where I come from, encoding in HD at 1080p (2 megapixels) is barely doable with the latest quad core CPUs at 24fps. And that is a single stream. Increase resolution up to 3 or more and the job becomes even more difficult.

 

Are you coming from the broadcast world? Because the encoders on the camera are set to much, much more lossy to start with then you would see for TV broadcasting.

 

 

I would imagine in either case you need to show that manipulation is difficult. I think most people would agree that modifying a camera's encoder is much harder than some PC software performing the same function.

 

Pull the libraries for the codecs. Run them though a hashing file. Compare against a known good copy that clearly doesn't tamper with the video. Note that the hashes match. Choose a different hashing function. Repeat.

[amirm 0]

Are you coming from the broadcast world? Because the encoders on the camera are set to much, much more lossy to start with then you would see for TV broadcasting.

My background is both in the broadcast industry and computer/IT/signal processing. My group at Microsoft led the development of MPEG-4 AVC (H.264) and its competitor, VC-1. My team also had extensive experience in optimizing encoders to run fast both on PC and non-PC environment. This is me if you want to read more http://www.microsoft.com/presspass/exec/amirm/default.mspx

 

You are correct that encoders in cameras cheat a lot to reduce computational requirement of encoding video. H.264 is especially CPU intensive. It takes a cluster of PCs to approach real-time encoding for production of Blu-ray High Definition discs. VC-1, is about twice as fast but still, both take a lot more CPU than MPEG-2 and far more than MJPEG.

 

So it is not enough to hear that some encoder is H.264. What is important is what features of the standard it uses. At the extreme, H.264 is only 10 to 30% more efficient than MPEG-2 which is not a whole lot. To get 2X or higher, the encoder must support more advanced features like multiple reference frames, "CABAC," etc all of which take considerably more CPU.

 

Pull the libraries for the codecs. Run them though a hashing file. Compare against a known good copy that clearly doesn't tamper with the video. Note that the hashes match. Choose a different hashing function. Repeat.

How do you provde which library (encoder) was used? Encoders do not leave a trace to prove which software or hardware was used. So the hash is not going to be strong evidence. Now you could argue that the same is true of the in-camera encoder . I suspect though human evidence of what was used is easier to come by in the case of a camera output going directly to disc as compared to some system with ever changing software recompressing things. At the end though, maybe we are splitting hairs here. I don't know .