Thomas

We are tied to certain capture cards.

Obviously, you've never worked with the Honeywell Enterprise NVR system! You're right. I wouldn't work with that system. 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. 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. 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.

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.

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.

Corrosion of the platters? I thought they were non-corrosive! Wikipedia: "Platters are typically made using an aluminium or glass substrate. In disk manufacturing, a thin coating is deposited on both sides of the substrate, mostly by a vacuum deposition process called magnetron sputtering. The coating has a complex layered structure consisting of various metallic (mostly non-magnetic) alloys as underlayers optimized control of crystallographic orientation and grain size of the actual magnetic media layer on top of them, i.e. the film storing the bits of information. On top of it a protective carbon-based overcoat is deposited in the same sputtering process. In post-processing a nanometer thin polymeric lubricant layer is deposited on top of the sputtered structure by dipping the disk into a solvent solution, after which the disk is buffed by various processes to eliminate small defects and verified by a special sensor on a flying head for absence of any remaining asperities or other defects (where the size of the bit given above roughly sets the scale for what constitutes a significant defect size). In the hard disk drive the hard drive heads fly and move radially over the surface of the spinning platters to read or write the data. Extreme smoothness, durability, and perfection of finish are required properties of a hard disk platter." In my experience with hundreds of drives, the most common failure is mechanical - voice coils, bearings, etc. The next most common failure is head crashes. The third most common failure is electronics. I suppose corrosion could be a factor in some of the above but I doubt it would be of the platters. I've talked in depth with Western Digital engineers about this since we have approximately 800 disks recording video in our system and experience about 1-2 failures a week now that the drives are two years old. It's a non-corrosive coating. It does have some degree of permeability. High amounts of humidity can still cause water to seep through that layer. It can also be cracked if you get a sudden temperature change. Different metals react differently to different temperatures. Given that most hard drives are nickle, aluminum and copper under that carbon layer, you can get cracking from the metals shrinking or expanding due to heat. There is also a small amount of wear and tear from air friction as well. And if a head crash happens it can scratch the carbon layer. Platters are corrosive resistant, that not quite the same thing as non-corrosive.

If someone has physical access to the machine, your ability to defend it drops to almost nil. The Windows password will stop someone who doesn't want to walk off with the machine and is completely computer illiterate. Hard drive failure from motor failure is rare. By far the most common reason for drive death is damage to the platters either by corrosion or drive head crashes. Hibernation won't prevent the first one, and increases the later one by a small percentage. Google has a great white paper on the subject, where they show the effects of various things on drive life expectancy. One of the things they found is that high utilization of the only has an impact on very young and very old drives. And that the number seem to show that those drives were defective and wouldn't have made it to the manufacturer's warranty period or were well outside it in the case of older drives.

The software is almost always tied to the capture card. You won't have much luck trying to mix and match.

802.3af.

http://www.onvif.org/onvif/ver10/tc/onvif_core_ver10.pdf So ONVIF has released it's new standard for IP cameras. For those of you about to ask your favorite software vendor why they don't support it....well it's a 226 page document that came out today.

Seperate network is always better. Because issues like this can always pop up: http://seclists.org/bugtraq/2006/May/0336.html http://securitytracker.com/alerts/2003/May/1006854.html http://securitytracker.com/alerts/2004/Nov/1012157.html So either physical or VLAN separation should be used on the cameras.

What software are you planning to use?

An NVR does a couple of things. It records the video to a central location. It handles some of the higher functions. An IP camera can be viewed via a web browser. So can an IP camera. The major difference is the transmission method.

Pretty close. It has an onboard encoder and then a small embeded OS. So it's a network device that streams video.

Short answer? No. Slightly longer answer: Yes but it's of extremely limited utility. You can't make data out of thin air. What you see in movies and TV only works with scriptwriting magic.

Generally security measures are placed on the cards so that you can't mix and match the cards and software.

And at the same time the demands for length of storage went up with it. Five years ago, people were pretty happy with 30 days. Now I read RFPs for 90 days or 120 days storage requirements. And in the end there is a cost issue. Using two codecs at the same time has a major processing cost. This means better processing power. In some cases more ram. It requires more coding. All of which lead to significantly increased costs. And the fastest way to make a dealer howl is increase their costs. We do it on the IP side with our products but there is room for it in the costs. On the Analog side, price is extremely important.

Installers and customers want to cram as many cameras on a machine as they can with the least amount of processing power used. Running two encoders is a huge processor hit. Plus end users (and to a limited degree installers) believe that the ultimate codec is the ultimate codec, not understanding that different codecs do different things well. And people don't want to pay for storage.

Nope.

If the DVR doesn't allow for SSL support then you won't be able to use Gmail for the SMTP gateway. I would look into seeing if your home ISP supports it. If not, you may be out of luck.

The streaming method is going to vary by DVR used. There isn't a universal solution. What kind of DVR are you planning to use?

8 cameras, 30 seconds, 24 hours a day... 23040 images per day. A bloody nightmare to sort through.

Did you read the posts with it? XP rebooting was an issue prior to SP1. If your copy of XP is randomly rebooting, it's a viral issue or an issue with their software.

I'm a little confused to your question. SMTP doesn't have a "authorization" layer beyond username and password. The protocol doesn't require a check box. But I can answer some of your issues at least. Most of the web e-mail services don't allow remote SMTP connections. You can't use Hotmail for it. Gmail does support SMTP. http://lifehacker.com/software/email-apps/how-to-use-gmail-as-your-smtp-server-111166.php Most home ISP's will not accept an SMTP connection from an end user. SMTP is meant more for server to server communications and most TOSs prevent end users from running a home mail server.

If it's happening, then they are configuring XP incorrectly. XP by default doesn't reboot.

You owe me a new keyboard.