Fixing CCTV

Filed under: Uncategorized — 2005-07-22 @ 17:32:16

In response to Erik's question on gadling. BTW, if any of you guys over there read this, gadling is great. I HIGHLY suggest you go check it out.
Erik was asking why we don't use multi-megapixel survaliance cameras. I originally started just to explain why, but then I found a solution as well.
London has one of the largest survaliance camera networks in the world. You have to realize that this comprises tens of thousands of cameras. Now, while this in of itself doesn't seem like a monumental task, also remember that you would have to upgrade the infrasturcture to support this. Assuming that we record at full-DV video, we would need 3.6MB/s which current infrastuctre can't handle. The gold-standard is a daisy-chained fiber-optic network. Generally the bandwidth avalible there would be sufficent to run about 25-30 cameras in a chain.
But, this gets more compilicated, generally security services archive video for MONTHS. So, let's do some math.
10,000 cameras * 3.6MB/s == 3.6 GB/second of needed storage.
or 2.16 TB/minute
or 12 exabytes/hour
or 311 exabytes/day
or 9 petabytes/month
or 112 petabytes/year
So, really it's the storage thats at issue. This is however solveable. First, by downsampling all video down to 25% of DV resolution. However, in an emergency all cameras could revert to recording at full-DV or half-DV. Then, run at 1/2 or 1/3rd the frame rate.
Next, assume that yesterdays video is not as important as todays. so implement some scaleable compression policy. After a week the video gets encoded to a losse-codec. After a month it gets re-coded to even more losse-codec. After a year, even more. In the end, you would STILL have better quality video than that image.
Also, let's track when we actually have motion on all the cameras and only store images from those times, no need to record blank spaces.
Lets assume that we both cut the resolution to 50% of DV and cut the framerate to 33% of DV.
that gives us 0.6MB/s, much more managable.
Assuming that there is motion 60% of the time (an, i think, high estimate).
that's, 45 mb/second
2.6 GB/minute
162 GB/hour
3.8 TB/day
this is where things get murky, becuase we are talking about doing compression from this point on, things will change alot, but here goes.
Assuming 720k XviD — for the monthly archives. — below numbers don't include the above numbers.
1.0 TB/month — yes ladies and gentlemen, it will take us less to store 1 month of archived footage then it will to store 1 day of regular footage. This is a good thing.
Assuming 320k XviD for the yearly archives.
177 TB/year

Not bad overall and considering how some of the anti-terror money is spent and the fact that this could actually help deter and prevent all kinds of crime not just terrorisim this would be money well spent.
Oh, you actually want me to tell you how much this is going to cost too!
The current cost for 500GB SATA drives is 399 dollars
you would need about 500 of them. that would give you 250 terabytes of storage. Assuming you use some raid level you will probably end up with 200TB of useable storage.
Raw Drive cost == $199,500
Cost for hardware to make it work(tm) == ~200k

This doesn't include the cameras, or the fiber-optic network, or the massive computing power needed to downsample the video and encode it to XviD. That will probably make this a many million dollar project. But, when our goverment can afford to loose 8.8 billion dollars in funds how are we supposed to quibble about something that could actually SOLVE some of these problems?

Politics……

No Comments »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a comment

Line and paragraph breaks automatic, e-mail address never displayed, HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>

(required)

(required)