Thomas

The way computers handle multiple "servers" on the same machine is by the use of Ports. Web traffic defaults to port 80, so just put the IP address into your web browser and you'll be good to go.

Dell pulls out that stick every six months to rattle at Intel over pricing. They've done it for the last ten years.

Yes. You simply stream out the video as you encode it. Pelco does it and I'm fairly sure GE does it as well. But the comment about HTTP isn't anywhere near correct. Unless the cameras share a common manufactor, like Vivotek and D-Link for instance, the cameras will operate in a completely differant manner. Even variations in the firmware can cause issues. What your saying is akin to "All PTZs accept RS-485 so there for any DVR can talk to any PTZ with one protocol." It's not true. Software writen for Axis cameras will not function with Vivotek. Software writen for Vivotek will not fuction with Toshiba's cameras. This is one of the major problems with IP cameras. There is no standard. And yet marketing people pump out "It's all on the network!" as if that means everything will talk to each other. Wireless Eye, I do have to point out that every programatic feature you cite can be done in the analog side. That's the joy of software.

Given that I just deleted nine or so threads in which you spammed the exact same thing, you will understand that we have some problems beliving you aren't a spammer.

The Codec is just a standard. I can tell the codec to be really aggressive in encoding (smaller file size, poorer image quality) or I can be less aggressive in encoding (larger file size, better image). Not all H.264 video is going to be the same. There isn't a flat standard for X video quality, it's all about what the codec is set to. It's quite possible that all of the H.264 video that Rory has seen is crap and yet Direct TV's isn't. DirectTV may be using much, much less aggressive encoding then most DVR's using it.

Details? Is it a research project? An implementation? For school? For work?

which ones? Generally your statements on physical security of DVRs/NVRs. All DVR's and NVR's have a single cable that can be tampered with to make them into expensive bricks. The power cable can be removed from the wall/box and that's all she wrote for it.

We do that now with Analog DVR's. We perfer to do a Client/Server set up but you can do Master/slave. I perfer to avoid single failure points. We use a seperate utility that we wrote for the moving of the files. We do it as a seperate application because it allows us to move the CPU overhead from trimming framerates and reencoding to a differant machine. Everything an NVR does is at the software level. It may sit on an embeded device but the software is the important part. But any feature it does can be done if other software is writen to have that feature. There is no mystical thing that NVR software does. We have it easier in that we do a PC based solution so we can take advantage of some underlieing Windows API's to handle things like SANs. But in your Pelco DVR example, the only reason the Pelco DVR can't do it is because Pelco hasn't writen the code. Not that it's impossible, it's just a feature that's not implemented. And some of Rory's examples are really stretching it as well. Both of you frankly are at opposite ends of the zealotry spectrum. And in many ways you both are wrong about the capabilities of the other side, as well as it's limitations. This thread is very close to wandering into the Mac vs. Windows vs. Linux vs. OS/2 vs. VMS arguements.

Live as in what is happening now, or live as in 30 fps?

It's a classic scam. The check will bounce.

If you absolutely have to have phone support then you may want to call the manufacturer. But to be frank there are maybe two of us on this board that can begin to configure setting up a Cisco router and have experance setting up an IOS based router.

I may be confused but the framerate is a factor of the card for Geovision, not the software.

It depends on the signal strength of the camera and local sources of "noise". With 80% shielding your going to have issues over longer distances. Cable is going to be the absolute toughest thing to replace, and you never really know if something will get rerouted, or a new interferance source will be moved. I would just stick with the 95% braid.

I'm wrong. They don't have a linux verison.

Off of the top of my head, the only two linux based products for PC based DVR's that I know of is Zoneminder and Luxriot.

The search on it is limited. You generally have to know what time something happened in.

The PoE standards suffer from voltage drop, like any other method of pushing power. But you'll reach the max limit of Cat5 before that becomes an issue.

Shipping paperwork headaches. And some items aren't legal for import, or have special duties on them, etc...

I have no idea who you are refering to but generally a hybrid system does analog and IP based cameras.

It depends on the codecs used, methods, etc. But you're going to eat the some overhead for it.

This is often cited but untrue. On the server end the software is still going to have to recode the stream to be stored. There is no CPU savings.

Axis allows IP camera software to be set to grab a differant stream then what is shown via the web. The cameras were set for low resolution on the camera but the software was told to grab the high resolution images. And Axis allows for this.

I was assuming Raid 0 or JBOD for such a set up. At which point the loss of a single disk is just as bad.

Emulation tends to be slower. There are some programs that add some of the window's API layers (Wine and WineX or what ever they call it now) but given the nature of the directX calls made you're pretty unlikely to get it to work.

Depends on the mean failure time. 3 x 160's can have a worse average failure time then 1 500 GB drive.