Thomas

No, you're not going to get it to do that. Some of it is limitations in the applications you describe, some of it is the card. But why would you even want to do that when there is cheaper hardware for those tasks?

Most are, but that doesn't mean you're going to write in that format, and many NVR's will decode the stream to run motion detection then re-encode. Damn waste of processing power, if you ask me. It is also likely to produce exponential coding errors into the video. Processing should be done in the camera. It just proves my contention that IP is not quite ready for prime time. Processing power is cheap and constantly growing. Motion detection on the camera side sucks, and as more advanced analytics become standard, the cameras simply can not keep up in terms of processing power. Where as Intel and AMD will gladly keep scaling up chip speed to increase processing power.

What encoder? Aren't megapixel camera outputs already encoded? Most are, but that doesn't mean you're going to write in that format, and many NVR's will decode the stream to run motion detection then re-encode. Depends on the software on the NVR end.

It depends heavily on the encoder used along with what the quality settings are.

Most modern PoE equipment will do a handshake to determine what voltage is actually needed. You generally do not need extra equipment.

No. That would cause no end of problems.

Are you trying to track down the codecs? Or are you trying to make Geovision work with other hardware?

With a router set up, no you can't do that. But you can run all of your cables to the same point and simply plug them into the video server and that into the router. The only real difference is you plug into the video server rather then the router.

That would be advertising. Try a banner ad.

Flir has some stuff for this, but your going to pay some serious money for this.

Just follow a port forwarding guide for 192.168.X.X and substitute the correct numbers. 10.XXX.XXX.XXX is just another set of private IP addresses for larger LANs. But that's it.

The section of town I'm in lucked out. Mostly fallen trees in the area. Around us? Not so good. But I have power back now.

Ugh, that's such a bad camera. I've gotten a chance to play with it and it's not very impressive and even less so at it's price point. I'd go with the housing they recommend for it, it will fit in some of the generic housings but you won't be able to use the PoE to power the housing. You chose poorly.

The sound of popping transformers does more to harm your sanity then the sound of the wind. And that is all I have to say about that.

Yep, I spotted the problem with the system. You're not going to get a facial ID at 90' with wide angle lens. Thomas, Do you mean to say that it is not possible to do with megapixel cams? A facial ID? No, it's not currently feasible with current technology and extremely unlikely to be possible with the next generation of camera technology. I'm not trying to be a jerk, but I believe your problem here is unrealistic expectations. A facial ID requires the face to take up a fairly large number of pixels and even with larger resolutions you're not scaling up enough to get a facial ID at that distance. Quite often, megapixel cameras will give you a greater range in which you can get that kind of ID, but 90' with a large FoV is still in the mythical "CSI" tech level.

Google's white paper on the subject disagrees with you. Activity doesn't appear to have much impact on life span of a drive except in early life and late life of the drive. Also boys and girls, the Google white paper showed that there wasn't much difference at all between failure rates of various manufacturers. They've only gone through a hundred thousand or so drives of various sizes and manufacturers. Some of the more interesting bits: 1.SCSI, SATA and IDE all have similar failure rates. Which kills the conventional wisdom that SCSI gives better life time support. 2. SMART is a only slightly useful in determining failure rates. 3. Activity and temperature do not have the ties to drive failure that people expected. 4. Failure rate among drive manufactures tends to be fairly similar, within margin of error.

Well that somewhat defeats all the goodness of embedded but retains all the bad. Inversely I don't think anything says you can't run a RTOS like QNX on cheap and readily available x86 hardware. Which although doesn't fit that definition (and many other people's I'm sure) ~could~ actually be the best of both worlds. RTOS stability and cheap readily available hardware. There is in fact a community supported set of drivers for basic x86 support. for QNX. I'm not sure why you'd use that combination but it's doable. For x86 I'd just use something like LynxOS.

Yep, I spotted the problem with the system. You're not going to get a facial ID at 90' with wide angle lens.

I believe Geovision has an option to add IP cameras. If I'm not mistaken (and i may be) it will cost you more. But before you jump into the deep end, lets look at what you're trying to view. What is acceptable image quality for you? At ten yards what do you expect to be able to make out? At thirty yards, what do you expect to be able to see?

The system would have to be a hybrid system, capable of supporting both types of cameras. And you wouldn't connect it to the card itself, you would connect to the network. If you want to be a little more specific I can give a better answer.

Remember boys and girls, linking to pirated software is against the rules.

Most of the major manufacturers put them on their websites or FTP sites. Put in the model number and filetype:pdf into google and you'll find them.

Vulnerabilities are all in how you define them. Take Apache (and it's most likely going to have on an embedded unit) for instance. It's a fairly secure application if configured correctly. The major problem is that unless you really know what you're doing with it, it's amazingly hard to configure correctly. And problems from poor configuration aren't generally listed as a vulnerability because if you configured it wrong, that's not a program fault, or a code fault, it's a user fault. And reflashing a system may not be an option open to you. If the malicious code decides to overwrite the chip with zero's then the machine is bricked. The serial port is going to be useless. If you load a corrupted firmware, then your most likely going to brick the system. If you have a tech who screws up and loads the wrong firmware altogether, you have a good chance of bricking the system. You aren't going to remove the chip, so for a bricked system you're looking at a motherboard replacement. Which is cheaper, a hard drive or a motherboard. And keep in mind, I know who you use, and I know they aren't charging what the motherboard costs on newegg. So by perfering to use an OS on a chip you don't gain any security. You do add some extra chances to fail, and your requiring a more expensive replacement part to fix it if it does fail. And, with the networking setup you describe, would a windows based machine be vulnerable? Not really, that's a fairly locked down box.

Neither. They aren't very good and I'd spend a little bit more to put together a decent system.