Our Man in the Field: The Process of the IP Solution, Part VIII

In the last installment of our column (see The Process of the IP Solution, Part VII) we defined the idea of real-time video. It also pulled us into the new intricacies of digital recording. Ah yes, there are options to be discussed here.

In the olden days, we worried about how many hours to record on a 2 or 3 hour cassette. It was a little thing called "time loss factors". You could take the recording speed and divide it by 120 to calculate the number of frames recorded each second. Then you used that to determine how many images you recorded from each camera per second or minute or week. The only other concern was whether or not to alarm the recorder or the multiplexer or both. Alarming the recorder increased the speed of the tape, but had no affect on the switcher so you would end up with more images per camera, but the same amount of time loss while switching between them. Alarming the switcher would lock onto a single camera or flip between two.

So, if the action left the area of the alarmed switcher channel, you lost everything. We had worries. We worried about how many cameras we were switching through when recording. We worried about time loss factors, but, for all intents and purposes, that was about all the options we had to worry about. Today the ball is in a different court, and yet we still worry. Today our worries are:

  1. How much space do we have to store our images and data on?
  2. How do we calculate the amount of space that we need?
  3. How many images per camera do we need or want and under what circumstances?
  4. What level of resolution do we record each camera:
    a. As a group?
    b. Individually?
    c. Under normal circumstances as opposed to duress or alarm?
  5. What format do we store our images in?
  6. Do we want or require off-site monitoring, playback, control, and search capabilities?
  7. Do we require watermarks or encryption?
  8. Do we need or have the ability to download images in a court-accepted format for evidence?
  9. What is a court-accepted format?
  10. Is the format or the unit that we choose for our recording and storage going to be obsolete in five minutes ... and if so, will the company that sold it or produced it still be in business to support updates or upgrades?
  11. Is the software compatible with the other items in my system that have special design and/or needs?

Overall, I could probably come up with 10 or 15 more questions to ask, but I am not here to depress you all or to remind you about how little we all know about our new futuristic recording traps.

The first important question in the equation is storage space. We have to ask how much is required. This is still a maddening experience for me personally. OK, I know it's just math, and math is my forte, right? Right! However, the number of answers required to calculate storage space can be huge. You'll need answers to questions, but you may or may not be able to answer these questions precisely at the time you are trying to calculate your space. Expect questions like:

  1. How many images per camera per second do you intend to record, and, for that matter, how many cameras do you intend to have in your system that are recorded?
  2. How many events will you have in a day, week, month and at what frame rate and for how long each?
  3. What resolution will you require under normal recording circumstances?
  4. If a green car is traveling east on Highway 44 at 65 mph and a red car is traveling west on Highway 44 at 85 mph, at what point will they crash and burn?

OK, you won't have to answer that last question, but the point is that for some of these questions, you may find that you need to make a decision on a potentially expensive and extremely important aspect of your system design in a "half guess" manner. So let me explain and then you decide.

Most Digital Video Recorders (DVRs) are nothing more than a hard drive, a bit of firmware, and an encoder/decoder. What this means is that they are not digital at all. Most DVRs can't even accept a digital signal. Most DVR units use encoders and decoders (usually this is proprietary technology). The encoder compresses analog video signals into a format of digital language. The decoder then converts the outgoing signal back to analog for the monitor(s). In some cases, the DVR may be designed to accept IP or digital signals, but here again there may be a problem of compatibility as there are no set standards for the type of digital output our IP cameras and field encoders use.

To top it off, most of the DVRs use one format or another of proprietary compression for recording. This means that to play a video segment back, off-site, you may end up having to convert the digital signal into a new format such as a .mov file or MJPEG or whatever. The second half of this ugly snake is that you may end up having two or more DVRs at multiple sites that are unable to communicate or playback video information between them. What a waste! It's like having a diesel car at a methane pump. The lesson is that you'll need to pay attention to the details as you assemble your equipment.

Network Video Recorders (NVR) are glorified DVRs. OK, that is a bit of an oversimplification and a little cruel to the manufactures of NVRs, but it's not so far off as to miss the mark completely. NVRs generally have several options that DVRs cannot compete with. The first and most obvious is in the name. NVRs are designed to work over the Internet. Of course, some of you are saying, "My DVR works over the Internet!" and you may be right. However, there is little or no comparison between DVRs and NVRs once they are connected to the Internet.

Most DVRs will transmit a highly compressed image or group of images. Additionally, controlling the DVR from afar may be easily done, but what about controlling the system? NVRs tend to give you full control of the system, right down to individual Pan/Tilt/Zooms. NVRs are designed for large capacity storage (usually) and are generally considered to be "open-ended" technology. Yes, they may have a base recording format that is proprietary, but it is open to outside influences. Newer DVRs carry many different types and quality of features, but in most cases, if you want to beef up the system a bit, you must beef up the DVR. NVRs not only carry many interesting recording and playback features, but they can generally be upgraded via software.

DVRs tend to come in group formation inputs of 4, 8, 12, 13, 16 and/or 24 cameras. Need to add one camera to your existing 16 camera system? Watch out, you may have to purchase another DVR and stack them. That can mean you're paying another $2,000 to $3,000 for one camera. NVRs, on the other hand, are usually open ended. With an NVR system, if you need to add more cameras, you buy an inexpensive encoder and there you go. Overall, the size of your system (the final size); the interactive qualities that you will require between sites and/or for off-site monitoring; and the requirements that you have for "open architecture" design will be what determine if you will use a single DVR (or a stack of them) or if you will break into an NVR-based system.

If you think about it, this kind of sounds like everything else that I have been saying for these past months. Design the application and then investigate, test and apply the equipment to the job ... not the other way around.

OK, so what about all the other questions? Many of them I have answered in past columns. However, I will make you a promise to answer everyone of them next time. From there we will step into compression factors and the net result of recording. After that, it will be time to discuss the differences between on-site surveillance as opposed to off-site monitoring. For some reason, a huge portion of our industry just seems to have problems telling the difference between the two. Once you understand, however, you will never have trouble telling the difference between apples and oranges again. Until then, keep your head down and always think before purchasing or selling equipment ahead of the application's design and/or before a good, on-site, 7-day test. See you when my next column appears in October on SecurityInfoWatch.com.

Loading