MaxIcon

So the 720p and 1080p have different FOVs? Dahua did that in older cams, but I thought they quit in the newer ones and scaled them to match. Customers complain about this, so most cams join the pixels these days to scale the image. Vendors need to publish the actual FOV for every resolution to avoid these misunderstandings.

A big problem with cell phone cams, aside from what others have mentioned, is that the sensors and lenses are tiny, so low light performance is terrible. You can test this for yourself on a dark street with your cell. Many apps, like Blue Iris, will take very low rate snapshots, 1 per minute or whatever, and upload them to an FTP server. You're still limited to the camera resolution, though, and the costs will be well above your budget because of the hardware. BI can use phones as a video source, but I'm not sure if it can grab the still photos. Best bet in your budget range would be to find a sensor module or phone with the resolution you need, connect it to a Raspberry Pi or Arduino, and write the code to make it do what you need. This saves money because you don't have to pay for someone else to do the development work.

Remember that linear resolution is what counts in resolving details. 1920 x 1080 = 2.1MP 2992 x 1680 = 5.0MP, 2.4x the area resolution of 1080p Linear resolution increase from 1080p to this 5MP resolution, assuming the same FOV: 2992/1920 or 1680/1080 = 1.6x increase When it comes to reading text or identifying features, you really only get 1.6x the linear resolution, even though the area resolution increase is 2.5x (which is 1.6 x 1.6). To get 2x the linear increase for 2x the detail, you'd need 3840 x 2160, or 7.5MP; call it 8MP to make it easy. At this point, the latency issues are going to be in decoding the images, since that increases with total resolution, not linear resolution. By the time you have 8 5MP cams, you'll have a much larger decoding load than the same number of 1080p cams, or a lot more 2MP cams for the same total MP. Also, from a practical perspective, 5 1080p cams can give much better coverage than 2 5MP cams, since you can select more areas of interest with more cams. This has always been a flaw in the "1 1MP cam = 4 D1 cams" argument. Like everything in cams, it's a set of trade-offs.

When you switch between wide screen (16:9) and old school (4:3), you'll always have a different FOV in one axis or another, unless they compress or stretch one of the views. For example, on the Dahua 2100: 720p is 1280×720 (on all cams, since 720p is a standard) 1.3MP is 1280×960 (not a standard, so some 1.3MP cams have different resolutions) Both images show the same 1280 pixels for the width, but the 1.3MP has an extra 120 pixels each on the top and the bottom, and you see more FOV. They could use the same FOV for both, but the 1.3MP would be stretched vertically to fit the same view into more pixels, throwing away the real extra pixels. Most cams these days use the same FOV for all 4:3 settings (1.3MP, 3MP) and the same FOV for all 16:9 settings (720p and 1080p). How the 5MP will display will depend on the resolution. Divide the horizontal resolution by the vertical resolution to figure it the aspect ratio for your cam's 5MP setting: 1280/720 = 1.78 (same as 16/9) 1280/960 = 1.33 (same as 4/3)

OK, I'm a math guy, but you guys are chasing the wrong ghost here, and it's taking you down the rabbit hole. The issue isn't so much sensor size as it is M12 lens image circle size. As BW stated earlier, you can install 3 different 4mm (or whatever) lenses on the same cam and get 3 different FOVs. The old FOV calculators don't really work with IP cams and M12 lenses. It's almost impossible to tell what your final FOV will be without putting the lens on and measuring it. Vendors need to spec this stuff in more detail; some do now. Even the vendor numbers aren't always accurate, and they often don't spec the different aspect ratios, like 4:3 vs 16:9, but will only spec one. Also, the image sensor size isn't the real size, but what they call a "class" or "optical format" size, left over from when image sensors were mounted in glass vacuum tubes, and the size referred to the tube ID. The diagonal for a 1/3" image sensor is closer to 1/4" in the real world. You can get these numbers from the spec sheet for the sensor, but you can approximate them by multiplying the sensor size by 2/3. Finally, most modern sensors aren't square, so the relationship between the real diagonal size and the real x and y size will depend on the actual sensor die and number of pixels (not always the same as the resolution; there are usually more pixels than the resolution spec). So, before you can compare sensor X to sensor Y, you need the spec sheet on each to get the real numbers. Here's an example. The Aptina AR0330 sensor, used in the Hik 2032 camera, is a 1/3" sensor. Per the data sheet: Optical format: 1/3-inch (6.0 mm) Entire Array: 6.09mm (this is about 0.24") Still Image: 5.63mm (4:3) HD Image: 5.82mm (16:9) (you can use the aspect ratio and trig to calculate the x and y dimensions) Active pixels: 2304(H) x 1536(V): (entire array): 5.07mm(H) x 3.38mm(V) 2048(H) x 1536(V) (4:3, still mode) 2304(H) x 1296(V) (16:9, sHD mode)

I've set up a Hik 2032 bullet for LP capture testing, and the longest lens I could fit is 12mm; longer lenses won't fit in the case. Domes would have the same problem. Generally, you'll need a box cam, enclosure, and appropriate lens. My Hik works at about 50' in the daytime, but at night illumination is an issue. The on-cam IR is totally ineffective, and lighting varies so much on plates that you'd need a dedicated high power source for reliability. Buellwinkle's LP capture setup uses an expensive IR illuminator and a high shutter speed, I believe.

I don't run dedicated NVRs any more, but can answer a few of the questions: There's no quality difference in which port you plug in to, as it's all network data. There are benefits to running the cams on your network, as you can manage them more easily. The NVR will assign its own IP addresses, and you have to jump through minor hoops to directly access cams on the NVR through your network. They both make good quality gear for the money, and are the current sweet spot for price/performance if you don't need the high end. I have both Dahua and Hik, and would buy Hik over Dahua without a doubt. Others like Dahua more. Best bet is to read up on reviews and differences. Hik's also a good bit cheaper if you buy from China, but warranty support (due to high shipping costs) and language versions (fixable with the CBX mod) can be an issue. The general recommendation these days is to go for turrets instead of domes, to avoid the IR reflection issues that domes can be prone to. I believe Hik's ahead in the turret market, but I don't follow Dahua much these days. Dahua's support is among the worst I've ever experienced, but I didn't pay the premium for authorized dealers. Hik lets anyone download the firmware, but you either have to buy US region cams or pay a bit extra for the CBX mod to convert Chinese cams to US cams. Both have lots of community support on a variety of forums, but Hik support is still a good bit stronger than Dahua support. Others will have to suggest the appropriate vendors. If I were to buy 8 cams today, I'd get them from AliExpress, using a vendor from the board recommendations, and would spend some of the savings on a spare cam or two in lieu of warranty support.

I've done some recent testing on this on a Hik 2032, and found that low light details show up better in color compared to BW if there's no IR. This is mainly due to increased contrast, since there are more variations in a color image. When converted to BW, many colors map to the same shades of grey, losing any differences between them. I also have some older Vivotek IP8332 cams that I keep in color at night, even with IR, for the same reason. I get slightly better sensitivity and a fair bit better contrast and detail. It may vary depending on the camera you run.

Just to emphasize what Boogieman said, you should look at turrets instead of domes unless you want it less obvious where the cam is pointing. Domes are more prone to IR reflection issues, which can be quite a headache. You're better off with multiple fixed cams than pan tilt unless you have a big budget.

It's hard to say for sure without more data. If the wires are undersize or poor quality and the run is long, you're more likely to have problems, but if they're good quality and/or your run is shorter, you should be OK. Many people have run passive POE for years with no issues, as johnnycw mentioned. If there's a lot of power dissipation along the wires, you'll likely have trouble with the cam, especially when the LEDs come on at night. Large power drops cause the voltage at the camera end to drop, which can make it stop working, so that's likely to happen long before you see any damage from overheating. Best bet for measuring the power is to get a device like the Kill A Watt. Plug the power supply into it without the cam connected, note how much it draws, then connect the cam, and you'll know how much power the cam uses, amd can then calculate the current. It's unlikely they'd give you a 12W supply for a 12W cam. These Chinese wall-warts can be notoriously unreliable, and it's always a good idea to over-spec them. LED power draw depends on a bunch of things. You can't know the power of the LEDs without measuring it on the board, but with 42 of them, they're guaranteed to be low power, probably under 0.1W each. I'd suggest hooking it up with a passive injector pair and see how it does.

In general, larger wires are better, and Cat6 is better than Cat5 for POE. In practice, it's not a big deal if you're using 802.3af POE. If you're using power injectors, it's a bigger problem, as you noted, because of the high current at lower voltages. The 802.3af 15.4W spec is at the switch end; the spec for the device end is 12.95W, which takes into account worst-case Cat5 spec cable resistance over 100M. Some cams pull this much power, but using Cat6 reduces the loss in the cable and gives a bit more headroom. You do want to avoid copper-coated aluminum wiring, which you'll find in bottom end cables.

This should be good. Most lenses have image circles a fair bit larger than the sensor they're rated for, and 1/2.8 sensor cams tend to use 1/3" lenses in general. I tried to test some 1/3" M12 lenses on a 1/2" sensor cam to measure the image circle, but it was just too big, and I only had vignetting on one side of the sensor. You won't know for sure until you try, but I'd guess you won't see a problem.

I've never run a Dahua NVR, and can't answer on how well it handles the streams, but others here have them and I haven't heard much about long delays like this. Maybe someone who's used this NVR can chime in. Network processing is definitely part of the CPU load. How each machine handles this depends on how they wrote the code; some are better than others. Many NVRs have similar hardware and are limited by the firmware to how many cams they can record; this is just something the vendors do. There might not be much difference except for POE ports and network boards. If it's a 4 channel NVR, that's all it will record or display due to firmware settings. Try one channel and see if it improves. You might also check to see if there's newer firmware available. Dahua firmware can be tough to find if your vendor doesn't support it.

The Vivotek image of the 3D Glasses box is 180 pixels wide, while the Sony is 200 pixels wide. That's pretty close, and if anything, the Sony should slightly give better detail with the slightly higher PPI resolution, but it's too washed out. The Vivotek is the only one where the detail on the box behind the light is relatively clear. The small text on the Diablo box is definitely clearer on the Sony, possibly because of the higher PPI resolution in less challenging light area. I'm not saying one camera's better than the other in general, but for WDR performance, I don't think I've seen anything better than the Vivotek in that price range.

As Q and Boogieman suggest, your best bet is using a passive POE injector/extractor set. Whatever you put in one end comes out the other, so you can use your existing power supplies. Yes, you can do this manually by breaking out the appropriate pins and connecting them to the appropriate size power supply jacks, but passive injectors are cheap.

Hard to say for sure, as different manufacturers code things differently. Some NVRs write the incoming H264 stream directly to the disk to save CPU, while others re-encode. If the NVR adds info, like timestamps, it has to re-encode. If it's an inexpensive NVR, the CPU may not have the power to process a lot of data quickly, or it may not be processing the data into network packets quickly. Which stream it sends out also depends on how the software is written. If it's sending out the same resolution, it may not re-encode, but if it's sending out a substream, it may be re-encoding that, or it may be getting it from the camera. Do you also have a 10 second delay if you view the camera's output directly, rather than through the NVR? You could also disable all the cams but 1, and if the performance improves, you may be CPU limited. What kind of NVR and cams are they?

In the second set, the Vivotek comes out ahead of the Sony, and appears to have a much better WDR compression. The Avigilon colors look good, but the details are not good compared to the Sony or Vivotek. I look at how well you can read the text, which is a pretty key indicator of how well the details resolve from the shadows. On the Vivotek, you can not only read the text in the shadows clearly, but you can see the structure of the lightbulb as well. This is pretty impressive WDR. Maybe not too real-world, but it sure handled the extremes nicely. The Vivotek is half the resolution of the Sony, but is half the price as well.

Nice comparison! The Sony's the clear winner in resolvable detail, and the Vivotek's second best, with better colors but a little less detail. Avigilon's not too good, and ACTi is useless.

An easy way to measure this is to use the cam's web interface to save a screen shot, and open that up in MS Paint (assuming you're using Windows). Click the select tool and draw a rectangle around the object, and it'll show you how many pixels it is on the bottom of the screen. ID'ing people at night is tricky. Too far and the noise and low contrast obscures them, too close and they get washed out by the IR, unless you have smart IR. Longer exposure times help with IQ but give motion blur. Night mode loses a lot of contrast due to the BW image. Color's better, but needs more white light. A faster cam (1/2" sensor and fast lens) can help, but costs a lot more. The best affordable solution is better lighting, but that, along with the multiple cams you'll end up with, will definitely have the neighbors talking!

Marketing decisions by cam companies can be a little confusing, apparently to the marketing people as well as the customer. I'd guess that 1080p is a good trigger phrase, since everyone knows 1080p is good. However, there are cams that claim to have higher MP sensors but only support 1080p output, so you'd have to look closely at the specs to know for sure. The specs should include a full set of resolution settings and the frame rates you can get at these settings. Deception and murkiness are common in the cam world, especially at the lower end, so buyer beware. Assuming you can record at the higher MP settings, you can zoom in for more detail. If you can't record above 1080p, it doesn't matter much what the sensor resolution is in terms of real-world results. In general, avoid no-name cams. If they're not a well-known company with a good website and good customer support, including firmware downloads, you're liable to regret saving a few bucks.

What makes a Hikvision a Raptor is that it's part of their 2CD2XXX line, though they're moving away from that branding on the European portal and in their recent marketing material. I haven't checked the US download site. Other cameras use the Raptor name as part of their branding because it implies high speed, low drag, bad-boy performance. Raptor is used as a name for trucks, pharmaceuticals, tools, hard drives, sports teams, financial services, games, knives, guns, you name it. The Latin means "thief", but modern usage is for birds of prey (like hawks and such), and many associate it with velociraptors from Jurassic Park. The branding is all just marketing, though.

Blue Iris likes a lot of CPU, and how much it takes would depend on the resolution and frame rate. Best bet is to check over at the BI community forum at cam-it.org, where there's lots of info on how to get the best performance. A modern i5 or i7 should be able to handle 8 x 3MP cams if you don't go too high on the frame rate. I run an i5-3570k with 9 cams, 13MP, 10 fps, and it could probably handle another 3MP cam. I don't run direct to disk, which reduces CPU load, but someone who does could tell you how much it'll help. Another option is Milestone Xprotect, which doesn't require as much CPU power but costs more for the software, which may even out. Both BI and Xprotect are available as demo or free versions, so best bet is to fire them up and see which one you like.

Raptor is Hik's marketing name for that series of cameras. If that's what it's an acronym for, it's just breathless marketing - more funny than anything. Hik also has the downloads available under that marketing name - no credentials required.

A low bit rate won't show any problems on static scenes, or if there's not a lot of detail. When there's a lot of motion and a lot of detail, you're more likely to see pixelization or blockiness if your bit rate is too low. If you don't see any change when bit rate is changed, you probably have VBR enabled. Typically, the bit rate setting will be the max bit rate, and it'll bump up when you've got lots of changing pixels. Some cams will display bit rate on the web view. I use Blue Iris, which shows it in real time for each cam, but in MB/s, not Mb/sec, so you have to multiply by 8 to bet to Mb/s. You can install the demo version of BI to watch the cams. Likewise, installing Process Explorer will let you graph bit rate over time, but it shows aggregate bit rate for network usage, rather than breaking them out as individual cams. Hik's recommending that high a bit rate because of your 25 fps setting. The first step to reducing it, if either network traffic or stored file size are a concern, would be to drop your frame rate. Many people run 10-15 fps for surveillance.