Thomas

Yes. There are throughput issues when dealing with standard PCI busses. it's not very hard to reach them. Moving to the PCI-E bus allows for greater use of software compression, a better choice in the long term over hardware compression.

With NVRs it is very easy to add a more powerful processor, more memory, and/or more harddrives. What happens if you have a 16 channel DVR that is full and you want to add one more camera? This is something that is very easy and much cheaper with a NVR. Everybody talks about bandwith issues but if you design your network properly and use managed switches you will not have issues. And most PC based dvr cards allow for expansion via another board or daughter card. And most of the time a card that allows for 8 or 16 channel growth is going to be cheaper then a single license of the of IP camera software. And the bandwidth issue is still an issue when you start talking about enterprise level installations. I can and have done the network design for 500 camera IP camera installs and you still have to be careful to watch for choke points and a cluster of NVRs can be your choke point there.

Why spend the money for analog cctv cable when you can only use it for analog cameras. Me and my customers would rather put that money into a better network that will be more useful. Are you subnetting the cameras at least or are you seriously putting them on the same network as normal traffic?

You verify the checksum to make sure of few things: 1. First that you are working with the correct firmware the to right device. 2. That the firmware file itself hasn't been corrupted. 3. That the firmware hasn't been compromised in anyway.

You say it's only during certain times of day. Would there be a bit of machinery who's on and off time corresponds to those periods or is there a radio antenna anywhere near that camera?

No, it's like any other set of tools. For some jobs a DVR is the correct choice, for other jobs an NVR is the right choice. For instance, how many cameras, what kind of budget, and what kind of infrastructure do you have?

Generally you use one or two pairs of 18(2) to run the signal to the PTZ depending on the camera.

And who makes them?

It looks like it's accepting a standard composite input. They make BNC to Composite converters and that should work. Have you tried looking at the settings inside the DVR?

The only difference is the kind of input needed. And getting an IP camera stream from the camera itself and handing it off to remote users is one of the dumbest programing issues on the IP camera side. First it's a waist of bandwidth, one that gets worse when you start looking at large mega-pixel cameras. Feeding multiple 2200 x 1650 streams to a remote user who can't even see those images on their monitor is dumb. Downscale and make an actual good use of digital zoom. Second, it's insecure as all fuck. It means your cameras are on the same network. Which means they are vulnerable to exploits. Ask Axis how they feel about cross-site scripting vulnerabilities. It's been an issue for them in the past.

What kind of systems? Are you talking about a single LAN, a WAN or do you have 22 locations?

Do you do any of your own market research at all?

Matrox. It wasn't a spelling error, it's the name of the company.

I'm game. I'll start playing with ftp this week. I have it sending me mail attachments when it triggers an event... and I can access it from work via TCP/UDP... but ftp is something I haven't played with yet. I see another post out with one person trying to pull ftp from the pc, rather than push. That sounds interesting, and one would think it would be possible. For every action, there is an equal and opposite reaction. I'll keep everyone posted on my trials. Good luck, Odd Ballz Testing AVC760M It sounds like it's configured as a push client. And for FTP it's almost always going to be a TCP connection. UDP isn't for situations in which packet loss would important.

I was referring the the graphics card company that specializes more niche graphics cards. They have card systems in place that already do 8+ monitor outputs.

Matrox actually has a number of solutions for driving large numbers of monitors. They have one very sweet system that's used for large scale displays for things like control rooms. And it supports standard PCI slots or PCI-E slots.

Oh, but no way to view it natively on the Iphone? This is what caught my attention on their IP7138 page: http://www.vivotek.com/products/cameras/network_camera_ip7138.php Damned if I know then. Their SDK didn't mention it in the last revision I saw.

Do you know why that is? Vivotek claims 3G support. Unless they've made radical changes to how they stream video in the last two months, they use an active-x control for viewing. Which isn't going to work on a Iphone.

I'm not quite sure what you mean with the question.

Having taken apart a couple of Axis cameras, I can assure you that there is a separate encoder chip handling the encoding at least on older cameras.

Yes and no. The short answer is no. The slightly longer answer is that as long as your equipment is putting out fairly clean power you won't introduce cross talk which would slow the speed of the connection down.

You do realize that IP cameras run into limitations on the NVR side when it comes to scaling? There are limits to processing power and bandwith. And at the same time you can design Analog systems to scale fairly well with the network.

The spec actually calls for 22 to 24 AWG wire.

Except that even following a number of standards doesn't necessarily mean that intergration of a product is trivial. I'll cite MPEG-4 again. The following manufactures are all large players in the industry: 1. Axis 2. Sony 3. Panasonic 4. Toshiba. All of the above use a standard web server platform streaming MPEG-4. Not one of them is compatible from an API standard. All of them require completely different solutions to allow capture of the MPEG-4 stream. These different solutions are not a matter of hours to implement but a matter of days or weeks depending on what structure you already have. In all cases, all of the above manufactures follow the standards completely and to the letter. To say that standards exist and that companies don't use them and it's their fault is silly. All of the manufacturers above followed standards. But because there are no common API to detail a common set of standards to be used in the industry you end up with no interoperability among cameras. When ever you imply that there are a set of standards used by the IP camera industry to allow for interoperability, you are confusing the end user and the installer. Simply building on existing standards or even having a common pool of standards does not instantly create interoperability.