MaxIcon

Here's the link: viewtopic.php?p=226171#p226171 On my PC, the forum software cuts off the link after the parentheses, so you can't just click on it. You have to copy and past the whole link into your browser.

Any powered mic should work; they usually require 12Vdc, so you'd need a source for that. Here's a thread on the Axis mic, which apparently requires 3Vdc: viewtopic.php?f=19&t=36699 And a general thread on mics for cameras: viewtopic.php?f=19&t=37789 You could get an inexpensive mic and supply from ebay to test it out, and you'd only be out $10 or so if it didn't work.

Switching sensitivity should take care of this, but I agree with shockwave - the day mode image looks much better than when the IR kicks in, due to the reflections from the dome. You've got plenty of light for a nice non-IR picture at 1/30 s. You might also check to see if you've got the old style IR collar that blocks a bunch of the LEDs and provides mediocre sealing. These caused a lot of IR reflection on the domes.

You may notice the hik links in the PDF above are incorrect. They've changed their website and haven't updated the docs to reflect it. Here's where you can get all the Hik software to go along with the TFTP instructions: http://www.hikvisioneurope.com/portal/index.php?dir=Z%20OLD/Technical%20Materials/Special%20Tools/TFTP-Auto-Update/

There are 3 ways to deal with the curved fish-eye effect in wide angle cams: - Switch to a longer lens or zoom out on a varifocal, which will give you more zoom and less field of view. - Get a wide angle camera that compensates in firmware for the distortion. - Switch to a compensating lens that corrects for the fish-eye effect. Most of these are C or CS mount, but someone may make them in a M12 mount. These are typically expensive.

The Hiks don't always update the client software after an upgrade, and that can cause missing menu items. It's a good idea to clear your cache and uninstall the webviewer software on the client PC. Then, when you connect, it should prompt you to re-install the web viewer.

I tested the MJPEG main stream on my Dahua 3300C, and it looked like an Andy Warhol painting of a bad acid trip. I haven't tried it on the latest firmware, but it was no good on the earlier version. Haven't tried the secondary stream.

viewtopic.php?f=19&t=36557

This may be a dumb question, but do the cams have microphones or audio inputs? The NHD-820 cams that are bundled with this NVR don't have either.

Yeah, that would be a good approach to conserve CPU. Use the D1 (or whatever) substream for motion detect and viewing/setup, and record direct to disk for the full resolution. It wouldn't be able to add overlays, but that's one of the trade-offs. If your substream was only D1 and the main stream was 1080P (or any 16:9 ratio), you wouldn't be able to do motion detect on the whole image, only the D1 portion, so having a 1/4 res substream tied to whatever your main stream was would be a useful feature. You'd still need to transcode for full-res viewing, but if you did that on a client PC, you'd avoid loading down the NVR.

If there's a reset switch that will reset it to the factory defaults, that may help, if someone put a password in before you got the camera. Otherwise, here's a list of default PW for a bunch of cameras; may be worth a try! http://zeecure.com/free-cctv-and-security-tools/complete-list-of-every-ip-camera-default-username-password-and-ip-address/ If you google sunluxy password, there are lots of threads on resetting DVR passwords; some may help with the camera.

I used the NTSC version of this release to update my HFW3300C and HFW2100N - no problems.

Good to know - thanks for the update!

Here's the repost of the first set of Dahua/Hik comparisons from cam-it: Q was kind (and trusting) enough to lend me his Hik-flashed Swann 1080p. I'll be retiring to Mexico as soon as I sell it on ebay... Anyway, I've done a few tests to see what the deal is with the 3MP setting enabled by the Hik software. While it's almost impossible to tell what's going on inside the cam, we can get some real-world results by comparing the resolution of the various settings. The result: The Hik 3MP setting isn't really 3MP. In the earlier thread, I calculated the scaling and figured it to be about 2.2 MP, scaled up by software to 3MP resolution, and I think that's still about accurate, but I'll have to think on that some more. I'm also doing a side-by-side Dahua 2MP comparison, which has been very interesting, but it'll be a few days before I have much on that. So, on to the 3MP info. First off, the Swann lens spec on the Costco website is incorrect. Whether they think it's a 4mm lens and their lens vendor is messing with them, or someone goofed up in the specs department, is hard to say, but it's clearly not 4mm, and appears to be about 3.3mm. More on that after the 3MP data. The cameras are the Swann 1080p flashed with Hik firmware, and the Dahua IPC-HFW3300C set at 1080p. All internal settings are the same - 10 fps, 10 i-frames, 4096 kb/s, constant bit rate, all image enhancements (WDR, etc) off, all settings at default. Here's the test setup. This is an ISO 12233 chart printed on a 6x3' banner, 6' away from the cams. Unfortunately, the printer was supposed to print it 4x3, scaled correctly with white space on one side for extra info, but they stretched it to fill the entire banner, and I didn't catch it until I had it for a while. So, it's not accurate for resolution testing, but is good for resolution comparisons. The frame is PVC, which I built many a structure from, large and small, back in my Burning Man years. Hik is at the top, Dahua is at the bottom. It's very windy today, so it's held down by spare propane bottles. Both are set up for nearly identical field of view. Here are the 3MP images, which show the problem - the two cameras clearly have a different field of view, even though they were matched at 1080p. First step was to compare 1080p between the Dahua and Hik. Using BI, I zoomed in to the max on different parts of the chart that showed the edges of resolution, matched it between the cams, and took screenshots. You can see that the Dahua and the Hik have pretty similar resolution at 1080p, with the Dahua having a slight edge in places and the Hik in others. I believe the Dahua has a slightly better lens, but processing also affects the images - more on the lens in another post. This is 3 different areas compared - again, Hik top, Dahua bottom: Next, I switched both to 3MP. As we saw above, the field of view is now different, which was the first clue that something was wrong with the Hik 3MP setting. To compare, I zoomed the Dahua all the way in, then zoomed the Hik so the view matched the Dahua. You can see that the Hik now has different resolution than it had at 1080p, and than the Dahua. If it was switching to a true sensor 3MP resolution, the results would be the same as the Dahua and as the previous 1080p tests, since the difference between 3MP and 1080p isn't pixels per area, but more total pixels making the image larger. Same 3 areas, different zoom due to different BI view: Finally, here are a couple of the shots side by side. The Dahua's resolution is the same on both, as it should be, regardless of the BI zoom factor, while the Hik has different resolution in 3MP than at 1080p. Presumably the Hik resolution change is due to the scaling algorithms, but again, it's hard to know what's happening inside. Anyway, for those still with me, back to the Hik lens. I measure the field of view at 10' out as 18' wide, which calculates out to about 90 degrees. Traditional lens calculators say this should be a 2.7mm lens view, but they're mostly set up for 4:3 sensors, not 1080p, so if you scale it for that, you get 3.6mm. It just happens to almost match the Dahua at the minimum lens focal length setting, which is 3.3mm, so it appears to me that the Hik lens is really around 3.3mm, maybe a bit less. I haven't looked to see if there are any markings yet...

Depending on which version of BI you tested, there were relatively recent changes to the MD algorithms to improve things like shadow rejection. I haven't updated to the newer versions on my main system, but initial reports are that they also reduce sensitivity overall when enabled, as might be expected. The downside to having a lot of variables in the motion detect settings is the amount of testing it takes to figure out what combination works best (if any). It's especially a trade-off if you want to catch night time action near the edge of your illumination yet still reject shadows, though the time-based profiles help with that as well (you can trigger them based on sunrise/sunset times for your latitude and longitude). This doesn't help for people who want to run dedicated NVRs or edge recording, or do the processing on the cameras, of course. For external inputs, BI will process alarm signals from Arduino, Sealevel, X10, and similar, though it's not very plug and play, depending on which system you choose. There are also users working with Raspberry Pi units and such. I haven't done any of this, so don't have any details on how well it works.

The latest firmware for the Dahua 2100N, 3300C, and Hik DS-2CD2032-I all only support two streams with D1 max on the second stream. That could change with any firmware release. You could try sending a request to them for this feature. Dahua doesn't seem to pay much attention, but Hik may be better.

The Hikvision manual covers a wide range of cameras, and some may have more streams available. There are also sections on audio recording, SD card playback, etc, which are available on some cams and not others.

Like everything software related, this totally depends on the software developers. I would not put any faith in them doing things correctly without testing it myself. Once tested, you can't guarantee the same results will hold for the next firmware release. Assuming no lockouts, the main thing that would stop you from bruteforcing it over the internet is response time. Using a basic dictionary attack (seeded with IP cam logins) would come first, then on to smart brute force. Your PW/second rates would be pretty much dependent on how fast the camera returned results to you, but I'd bet the rate would not be very high.

I wasn't trying to change your mind, just answering the question on what the differences were, and throwing in what I perceive to be the risks. I'm not one to judge! As long as you (and your customers, if you're commercial or corporate) understand the issues and risk assessment, it's all good. In fact, having both cameras and NVR ports forwarded allows you to view the cams directly as a backup in case the NVR has problems. It can add up to a lot of ports to manage, though. There are lots of unsecured cams out there on the 'net open for viewing. Most of them are incredibly boring, but it's always interesting to cruise them.

This is all a decision the software developers and/or marketing people make. My Vivotek IP8332s will let you set multiple streams at any selection of resolution and quality that the camera supports. They have 3 streams total, as well, and the first 2 can both be full resolution if you want. It's a trend on inexpensive cameras (and maybe more expensive ones; I don't have any) to have the substream limited to D1. They could change this in the firmware as long as they have enough CPU power to support it.

Yes, it's not really flawed, in that it's detecting motion that is really there. These are not technically false alarms, they're just not the motion most people want to detect. What you need is either the PIR based motion detection BW mentions, which detects motion using different signals (passive IR instead of pixels, which has its own advantages and drawbacks), or intelligent motion detection that allows you to fine tune the detection algorithms to detect what you consider important. For instance, Blue Iris lets you detect motion due to color changes, contrast changes, or a combination of the two, as well as letting you set the sensitivity for the size and contrast of the changes. It also will let you turn on a mode that looks for groups of pixels changing in a similar pattern, to help differentiate between random motion (noise or shadows) and objects in motion. Each of these methods has plusses and minusses. Most cameras don't have that complex a MD algorithm in place, but some may be better than others.

This depends on your definitions and on what Hik is doing at the sensor level. The 3MP mode puts out a 3MP sized image, so by that definition, yes, it's 3MP. Of course, you could take a VGA image and upscale it to 3MP to fit that definition. It's possible the 3MP is a true 3MP image, sampling one sensor pixel for each image pixel, and the 1080p image is the sampled one. If this is the case, the sensor is larger than 3MP, and the 1080p is sampling a larger-than-1080p image down to 1080p. This is a legitimate way to do these things, though most vendors don't do this. It's also possible that the 1080P is a true one-sensor-pixel = one-image-pixel image, in which case the 3MP is sampled from a smaller image. I don't know any way to determine which they're doing except by digging through their code, and that's not on my top 10 list of things to do. Here's what it boils down to, though: For the money, this is one of the best cameras in its class right now. As long as you understand the limitations of the image modes and it still fills your needs, everything's fine. If you need a larger FOV at 3MP than at 1080P, the way most cameras with similar specs do, this won't work for you. I could use the extra horizontal FOV on my 2 Hik cams, but I was aware of the limitation when I bought them, so no complaints. The other option was buying Dahua, and I've sworn off of them.

I've just learned to live with it on my Dahuas, since it doesn't affect the overall clarity. It's unpredictable when they'll have the bad color balance or not. These are personal cams, so it doesn't help to complain, but I can see how some customers might be finicky about it. Possibly Dahua will fix this in a future release, but I'm not sure anyone there is paying attention.

There are a couple of key differences: - Camera ports would have one or more ports open for each camera, so that could be 4, 8, whatever ports and logins that need to be managed. An NVR only needs one port open (sometimes a few ports, depending on what you need to do). - You have limited camera control from most NVRs, so there are fewer changes that can be done through the NVR. Some have more camera control than others, so it all depends. It's harder/impossible for someone to brick a camera through the NVR, for instance. - If you have multiple brands of cameras, you have multiple opportunities for back doors and exploits. With a single NVR, you're more likely to know all the common issues, but there may still be undocumented exploits. In either case, a lot depends on the robustness of the login and control code. Cameras and NVRs often have mediocre code running them, especially the budget ones, and especially in the security regime. This is why logging in to a PC via VNC, RDC, or similar is a safer way to control - these are generally more secure if you stick with the well-known names like TeamViewer or UltraVNC. That said, many, many people run open ports on their cameras, NVRs, etc. A lot depends on how confidential the data is and whether there are back doors in the code. Many people don't mind someone on the internet watching their driveway, but wouldn't want them to be able to see inside the house. Nobody wants a stranger to be able to brick their camera, though.

Some cameras have insecure user accounts or telnet logins that can't be disabled, so anyone who finds the camera access can mess with them over the internet. Dahua's got some well-publicized security holes. A better bet would be to have remote desktop access to the NVR (assuming PC based) and adjust camera paramters from that. Otherwise, using obscure ports can help, but if someone's focused on your IP address, port scans don't take that long.