What is a DVR?

The reality is, a true DVR (Digital Video Recorder) meant for security is a sophisticated system composed of hardware components, software programs and sub-assemblies with built-in checks and balances. It all must work in unison to create a robust and reliable piece of equipment, designed for mission critical applications. This is not to be confused with the TiVo or other set top cable boxes that are also known as “DVR's.” They are in no way related. Creating a DVR solution requires a dedicated team of software and hardware engineers, database programmers and system designers, plus support personnel. Remember, we are talking about security where there is no margin for error. These applications take years to develop and de-bug.

Some of the basic points we will cover here are:

• DVR technology
• DVR myth's and reality
• DVR cards in a PC-environment
• Peripheral concerns vis-à-vis DVR stability
• What you need in DVR software
• Questions to ask when buying a DVR

DVRs are Not Alike

DVR's are all simply not alike. If anything it's quite the opposite. It's no different than buying a car. There are $10,000 Hyundai's, $100,000 Mercedes and everything in between. It all depends on your needs and requirements - both can drive and get you from point “A” to point “B.” That is if you can keep them running. DVR's are a lot more temperamental than even the most exotic foreign cars that live at the mechanic.

Digital video recording is a processor intensive multitasking application and can tax even the most robust of systems. So every ounce of computing power is helpful. Along with that processing power you need equivalent components to drive it. The famous saying is “you are only as fast as your slowest component.” If the system is not beefed up from end-to-end, in each and every aspect of hardware and software, it does you no good. If it's underpowered it is going to break.

Using the car analogy, if you buy a light weight truck it may be a fine vehicle, as a light-weight truck. Try then loading it up with 10,000 pounds of cargo and drive it up a hill constantly. Don't expect a long life out of the transmission or engine. It's not that it's a bad product, but that's not what it was designed to do.

Similarly, this is one of the reasons for the disparity in DVR pricing. It's what's under the hood that you pay for, but unfortunately without a Consumer's Guide to DVR's, it's difficult at best, for the user to know the difference, until it's too late.

Components become even more of an issue when you get into large storage or multi-user applications. So “Caveat Emptor” – let the buyer beware – all DVR's are not alike. Some have the nerve to build them out of $399 PC's and call them server Grade Equipment.

As far as the system doing what you need it to do, if you do not have a lot of experience with DVR's, this is something you should look into very closely. The entry-level products will fail to mention many things that their system will not do. Often the buyer doesn't realize it until:

•  It doesn't work with certain cameras

•  Too many simultaneous users freezes the system

•  The quality of the recorded video is poor

•  The recording and display speeds were not as you were told

•  The number of days of storage are far from what you were promised

•  Certain functions only work under certain conditions

•  There is no one in this country to support the product

•  You just bought a second system from the same company and it doesn't work with the old one

•  The distributor I bought it from no longer carries that product

There is no shortage of potential shortcomings of a substandard system. That is if you can get it to work in the first place for any extended period of time. In our knowledge database, we have identified over 100 different items that can go awry with DVR construction, and hardware and software conflicts.

The biggest concern always remains reliability. Many of the entry-level systems, which we like to call “toys,” are not meant for mission critical security. Remember in its most crude form, you can go to Comp USA buy a PC Cam, video capture card and PC and voila, you've built yourself a DVR. But these are not the right components for security and of course there is the issue of software.

DVR Card Differences

We have identified there are inferior consumer–type economy cards as some like to call them, and industrial-type products. I would be suspect at best of anybody that would even have the conscience to sell you an "economy card". Its junk and doesn't say much for their reputation. We need to understand the difference between them. Most video capture board manufacturers do just that, manufacture “the board”. You know that green thing you see that has a bunch of neat looking colorful components soldered into it. In reality, these companies are assembly plants. This is no different than much of the consumer electronics industry, where virtually all companies create products assembled from other company's components. So what is it then that makes the difference, between a top notch product and a substandard one. Quality control. Care in how they are assembled. And the right combination of parts to achieve the best performance. In talking to distributors who have carried "economy cards" they experienced as much as a 40% reject rate. That 40% was just the board, forget about it when you factor in the software problems.

Bottlenecking

We have all heard of the term bottlenecking but what does it mean to the DVR.  If you have 100 hoses connected to each other, 99 of which can pump water at 3 gallons per minute, and a couple of hoses at the end or anywhere in between, that can only pump water at 1 gallon per minute, then the entire system will only pump 1 gallon per minute and the 3 gallon per minute hoses are of no added value. The same happens with DVR components. “You're only as fast as your slowest component.” So put a bunch of good high-performance components on a DVR board and one is not as fast and you have defeated the entire purpose.

Shared Resources

Shared resources occur when a component performs multiple tasks simultaneously, each function taking away a portion of the total resources. So when a manufacturer quotes a specification; that is usually the "maximum" performance level. It also usually assumes that the component is doing nothing simultaneous. A shared resource obviously slows down performance resulting in choppy, robotic or even poor quality images.

So when you see the better industrial video capture cards, which have hundreds of chips and multiple layers, that's because it has individual components for each and every channel of video to be broadcast. Again, you have to still consider the bottlenecking issue; because just one single unmatched component can slow the system to a crawl. The consumer-type boards may have 1 set of basic components, to be shared by all. Their idea for increased performance is put a bunch of cards in a single machine but that has its own set of problems. Keep in mind, up till now we have only addressed the hardware concerns.

Frames Per Second

One thing you need to be careful about when looking at specifications on a DVR as far as frames per second capabilities is – are they talking about:

•  The total number of frames per second for the entire card to be spread across all cameras (cumulative total)

•  The total number of frames for each individual channel

•  The maximum capacity of the hardware not taking into account software switching, simultaneous functions, etc. (rated hardware capacity)

•  Display speed

•  Recording speed

•  "I" frame or "P" frame calculation

•  A combination of all of the above

There are an infinite number of ways of presenting these numbers, many of which are misleading. Sounds like financial reporting on Wall Street! Remember that 30 frames per second is real-time / real motion video, but that is for a single channel. So if you want to record 4 cameras simultaneous, all in real-time/real motion video, you need 120 frames per second and its full unshared resources.

The frame rate issue is also a very tricky one. The fact is the speeds that manufacturers quote are usually the “maximum” obtainable, meaning under ideal conditions, and does not take into account anything else the PC, software, or video card might be doing. In other words it's like the MPG sticker on your new car – good luck trying to get that mileage; maybe downhill in neutral?

We keep calling them “capture” cards because they are “capturing” and recording video, but what plays back and displays the video on the screen? The answer is the capture card. Even though it is "capturing" the video, it also handles the video display on the card.

Some other math we need to learn. If we already know about the maximum recording frame rate of the board, what about the video display? Sorry, but yes we have to add that into the equation. So now that you are displaying and capturing at the same time, the performance may proportionately deteriorate, as they may be sharing the same components to accomplish different tasks. So one function must wait for the other or both perform at a reduced speed. To counteract this problem some companies such as DVSS use a separate video display card, which generates real-time video on all channels all the time. Each live video display card usually has separate chips for each channel of video displayed. Each chip is capable of generating a true 30 frames per second image per channel across all channels. It is a live feed from the board directly to the monitor and each channel transmits its own video, without the need for the software to compress the video signal. This should not be confused with the VGA video card, which is entirely different.

Let's jump back now to, how the heck does this capture card work. After all, raw video uses a tremendous amount of data and we are talking about transmitting as many as 32 simultaneous images from a single machine. Making practical to send, receive and store huge amounts of data requires video compression before it can be transmitted.

There are 2 types of physical compression; hardware and software. It is actually a case of compression and decompression. Compress it to travel and decompress to transmit, so the name “Codec.” When you use hardware compression there is no loss of speed, as all the work is being done on the board by the hardware. That is of course if you have all the right hardware components.

Software compression requires software to perform specific operations that when performed simultaneously in conjunction with other functions has a taxing effect on overall system performance. The software uses the available hardware resources to complete its task.

Compression Technology

Compression technology is based on mathematical algorithms. I think any video board or DVR manufacturer would be hard pressed to demonstrate that they have some magic algorithm. The industry has a number of standard compression methods, which have been developed by companies who do nothing but that. They have written them over the years spending infinite amounts of money in research and development. If one of these DVR companies had this magic compression formula they wouldn't be only selling it to the DVR industry where quantities are small. The most common codecs used are H.263, H.260, MPEG1, MPEG2, MPEG4, Morgan JPEG (MJPEG), and Wavelet JPEG. Manufacturers purchase a license to use these products and then attempt to “tweak” them, and tweak means fine-tune, not revolutionize. We are talking about enhancements of a couple of percentage points, not double or triple.

So the math is pretty much the same for everybody. So when you hear a DVR manufacturer say they have a proprietary algorithm and can compress data more than anyone else, be skeptical. The most common Codec used in DVR systems is MPEG2 with the newer MPEG4 just coming up behind it. The difference between codecs is how and how much data it can compress. While MPEG4 can compress more data than MPEG2, making the size of the data packets smaller, there are still other issues such as the hardware being able to utilize the full ability of MPEG4.

The reason we bring this up is compression leads us into another discussion; packet size. The questions security professionals always ask is how many frames per second and what is your packet size. Packet size being how much hard drive space each image takes up. Professionals think this will tell them how many real time images you can get and how much information can be stored on a hard drive. Sounds simple enough, yes? Factual, no. Why because you need to further qualify the question and the answers. Confused yet?

“We can store up to 6 months of storage on an 80 GB HD.” 

Heard that one before? This of course using their proprietary algorithm, but this time if you read the fine print it says “under normal conditions"

Here we go into the video math, but I have to take a step back to explain to you some minor details in video compression technology. Have you ever noticed that some people talk frames per second (“FPS”) and some talk images per second (“IPS”). Guess what, these are 2 different things and 2 different compression technologies.

IPS vs. FPS- have you ever seen how they make cartoons, or any animation for that matter. When cartoons are created, they draw individual cells, one by one, and for each second of animation, they make as many as 30 frames or cells for each second of animation. This equivalent is what we call “P” frames or recording using JPEG technology.

Now if you look close at the cells, whether it be the Flintstones, Yogi Bear or South Park, you will notice that only one character is usually moving, while the background and other characters remain fixed or don't seem to change much. This is done intentionally so they minimize the amount of work. If they can use the same background or limit simultaneous movements they can re-use components of other cells. This is what we call “I” frames or MPEG technology. If much of the image that the capture board is displaying stays the same then it only needs to change that small portion which is moving. This is MPEG, whereas, JPEG records each and every frame (“P”). MPEG disseminates what is the same and what is new.

The perceived advantage is, if you only have to transmit or record new data, and not the entire thing all over again, fewer resources are used.

Unfortunately, under many circumstances MPEG doesn't perform any better, as with fluorescent light fixtures which may be blinking undistinguishable to the naked eye. Or in a casino, where lights on wheels and slot machines are blinking at several hundred times per second, reducing the efficiencies of MPEG.

Packet Size

When manufacturers refer to packet size in brochures it's usually assuming MPEG with little simultaneous motion going on. So when you take home the DVR and don't get the capacity of data you want on your hard drive as they claim, this is one of several possible answers.

So what else adds up to skewing the math? Two more factors; image size and to what extent the images are compressed.

The simple fact is, the higher the compression ratio, the smaller the packet and the fuzzier the picture and the quicker the transmission speed. A lower compression ratio results in a larger packet size while generating a sharper image with a slower transmission speed.

Oh we did forget to mention one small point. When you hear packet sizes these are usually based on 320 x 240 pixels. To get even close to a true full-screen TV picture standard you need to have at least a 640 x 480 picture, which uses 4x the amount of data as 320 x 240 because you are doubling the width and the height.

The best way to understand compression is to think of the printer attached to your computer. If you use a higher resolution the quality is better but it takes longer to print because there are more dots per inch to lay down. Using a lower resolution is not as crisp, but it is faster because it has fewer dots per inch or less data. This actual goes back to a previous issue of speed claims. When they say your printer prints 12 pages per minute, it's usually not based on the highest resolution or with full page ink coverage, but the maximum possible on low resolution with normal amounts of print. There is no standard for what is "normal". For a more technical and in-depth understanding of video compression technology, click on the following hyperlink.  Compression Technology

To truly calculate hard drive space you need to multiply the length x width of the image (example: 640 x 480= 307,200 pixels), then decide how many times you want to compress the data, then multiply that by how many frames per second you want to record, times the number of cameras. Head spinning??? For a simple idea of how much hard drive space you would need to accomplish your tasks you can use out hard drive calculator at HD Calculator .

Remember, this assumes “average” movements. But what is average is just a hypothetical. This is based on our experience over the years. If anything, its a little conservative.

Some products such as DVSS have come up with solutions where you can independently control each channel for:

Till this point we have pretty much focused on the video capture card, how it works and what to look for. Again, the capture card is only a single aspect, but a crucial one.

Next, we need to address, what is it that makes this card do what it does. We addressed software compression, but not software functions, which is where we separate the men from the boys, or as we like to say "the Real McCoys from the Toys".

Video Storage Database

At the heart of a good DVR software program, is a solid database structure.

Hardware components aside, the architecture of the software's database is the most integral part of the system.

How the database stores the images, what happens when multiple users simultaneously access the database, how does it prioritize? What happens when you have to search through millions of images or conduct queries? How long do things take?

This comes back to industrial products vs. consumer. The foundation required for the two are entirely different. Designing a database to run 4 cameras at a few FPS is very different then running 16 live cameras on terabit RAID servers.

Designing software and database structures is an art and a science. The architect must take into account innumerable variables that are not constants, as well as future unknowns. You are laying a foundation for new features that are only concepts on paper and trying to plan for new hardware and technology.

To the casual user or observer looking at the software's graphical user interface (GUI) tells you little to nothing about its guts. A car can "LOOK" absolutely gorgeous and fast, but its looks don't tell you how it will really perform. We are always asked who made the first DVR software because they all “look-alike.” The graphics may be similar, but not the guts.

Again, looking-alike has nothing to do with the reliability, durability of the software, or the picture quality. A good database structure can clearly and quickly parse data for smoother images (hardware quality permitting.)

Did you ever notice on some DVRs how pictures seem to pause and then catch up? This could be a hardware issue but just as easily could be the database trying to play catch up.

Much of the software in the market place today is based upon adaptations of consumer/type basic video capture software from earlier generations. As the technology progressed, many manufacturers continued to try to put band aids on antiquated software and build on top of it with outdated architecture.

Many board manufacturers whose expertise was not in software design, merely bought software from others and try to keep it up to date with patches, having no control over the product or original source code, which is owed by someone else.

If you notice many DVRs use last generation PC components, because their software won't work with newer components. Not having the source code to the software doesn't allow them the ability to modernize.

Volumes have been written on database designs over the decades and it takes some very seasoned professionals to do it right. The tools they use are just as important. Is it an Oracle database or some inexpensive freeware so they don't have to pay licensing fees. This also adds to the price differential between boards, and the resulting differences are obvious.

Hardware Components 

We started out by saying some people consider a DVR, a PC with a capture card and some software. There are PC's that cost a few hundred dollars, and there are servers that run in the thousands. Hardware components are the engines that drive the DVR as a whole. This is the one place you need horsepower, in the form of PCI Bus, processor and memory speed. Being deficient in any one brings us back to bottlenecking and you are only a fast as your slowest component. So if you think a DVR card in a $399 PC is going to perform well, think twice. Good systems cost money.

Peripheral Software

There are a number of programs that need to run in the background, which give the DVR its reliability and stability.

The fact is, DVR's are part of a very young technology with the bar being pushed higher everyday. With constant demand for new features, a powerful software foundation is required. But new features mean new unknown variables and accompanying problems.

With the billions of dollars that Microsoft has, why isn't their software perfect? Why are there always updates and patches? The answer is, no software is flawless and every time something new is introduced into the mix, things behave differently. How you go about handling these problems is important.

Let's take one issue, for example. Have you ever noticed sometimes if you leave your computer on for extended periods of time, it tends to get slower and you need to reboot? This is probably caused by memory leaks. The simple answer is, make sure your DVR runs on the latest Windows OS or Linux, which minimizes or eliminates the problem.

A preventive measure some manufacturers built into their DVR software is a scheduled system reboot to refresh the system at specific times. We recommend at least once weekly, regardless if it's a problem or not. What is important with the system refresh feature is that it goes right back into the mode it was in immediately prior to the refresh, a feature in all DVSS software. Some systems will lock up if it was performing a function at the time the re-boot happens. While others go into a default mode and require reprogramming the settings the customer had before the reboot.

Running diagnostic software, which constantly monitors several different functions of the hardware and software of both the DVR and server are essential. If the diagnostics detects any deviations from the established baseline criteria, it should automatically reboot the DVR and notify the system administrator it has detected a problem.

Another important tool is remote diagnostic software which allows you or a technician to monitor system performance and diagnose and repair any potential problem remotely. This will save on unnecessary service calls to the DVR's physical location, which could be thousands of miles away. All these programs and features are standard in all DVSS DVR's.

System Monitoring Software

A DVR should have some sort of “heartbeat” or health monitor program that constantly transmits packets of data to let you know that it's alive and feeling OK. More importantly, it should be transmitting its IP address so you know where to find it. Beyond that, you need some methodology by which in the event of a failure, you are notified.

Quite often you will hear manufacturers talk about a “hardware watchdog.” Purportedly, it detects a problem and tries to reboot the DVR. The curious part is when they say if the DVR fails, the system will notify you.

We know this is not possible in many obvious instances. It may be able to notify you if it was able to restart and tell you that “you have a problem so I restarted” but if it had a problem and couldn't restart; then what? The answer is you need some sort of third-party notification program that when it stops receiving the heartbeat, it transmits an emergency message. This software would have to be on an external machine, as opposed to the dead DVR, which cannot transmit.

DVSS's data center hosts this application, for a small monthly fee, to its customer. In the event of a "flat-line" the data centers computers contact the designated parties by phone, fax, email or page notifying them of the impeding problem on a real-time basis.

CCTV Balun

From the drawing, one can see that a balanced signal has two matched conductors. They are matched because their paths to ground are identical, both at DC and at high frequencies.  Any interference that couples into one conductor will cause it to move in voltage. But with  Unshielded Twisted Pair (UTP) wire, the interference couples into the other conductor too.  Since both conductors move, it’s important that the devices at the end of the wire have absolutely identical paths to ground, and that the circuit receive only the voltage DIFFERENCE between the conductors, while ignoring their ‘common’ voltage to ground.  The ability to reject this ‘common’ signal, while receiving the ‘differential’ signal is the basis of any balun (or active differential amplifier.) Again, a balun is required at each end of the wire.  All of these circuits perform this function, but always in a less than perfect way. The closer we come to perfect balance, the better we can reject interference. A good balance circuit is tricky, and is one difference between baluns in the industry today.  There is a measurement for how good the balance is. It’s called Common-Mode Rejection Ratio (CMRR). On the balanced side of the balun, one puts a zero amplitude differential signal on the two wires (they’re shorted together), plus a large amplitude common signal (big voltage relative to ground). Now we measure the small voltage on the unbalanced (coax) side. Under ideally balanced conditions, the coax voltage should be zero. To the extent that there’s imbalance, a small error voltage will appear. We define CMRR as the ratio of this error signal (Vdm) to the amplitude of the common (interfering) signal (Vcm):  Vdm / Vcm