dvarapala

Sounds like you got old stock. Fortunately you can download the latest HikVision firmware and reflash the units yourself.

You, sir, are an inspiration. " title="Applause" />

The tinting idea may or may not work, depending on which wavelengths the tint you used filters out. Chances are if it makes the red glow go away then it's filtering IR light; less light means less usable image from your camera. Do let us know how well it works and which kind of tint you used.

I've run into an issue with the Swann 825CAM bullets I recently bought from Costco. Periodically they generate "smeared" frames that look like the attached image. This happens on both cameras in 3MP mode using both UDP and TCP transports; I tried switching one to 1080P mode and so far no smeared frames, so it may be an issue with the 3MP capture mode. Needless to day, these occasional smeared frames wreak havoc with motion detection, generating several false positives every hour. I recall seeing a Swann tech support rep hanging around the forum a while back; if you're still out there I'd appreciate hearing from you. Anyone else experiencing this issue?

These cameras drop-shipped direct from Swann in SoCal with 5.0.0 firmware on them. After some more investigation, this appears to be a dropped-packet issue. Not only does reducing the resolution reduce the problem, but moving the cam from one PoE switch to another also helps; apparently my little Trendnet TPE-S44 PoE switch is starting to give up the ghost. I turned on debug logging in ZoneMinder (which uses the FFMPEG libraries to decode H.264 streams) and I'm seeing a ton of lost RTP packet errors. Apparently if the packet loss is sufficiently large it overwhelms FFMPEG's ability to conceal the errors, resulting in the garbage frames. One common solution to this sort of problem is to use TCP as the transport layer. Unfortunately this camera doesn't seem to support this option; although FFMPEG is configured to use TCP if available, the stream still ends up coming across via UDP packets. Hopefully Swann/Hikvision will add this in a future FW release. In the meantime, I'm going to hack the FFMPEG code to simply discard any corrupted frames (i.e. frames with too many missing RTP packets) rather than deliver them to the application. When doing motion detection, it's better to have no frame at all than to have a garbage frame where 70% of the pixels are different from the previous frame. Update: The lost RTP packet issue turns out to be a bug in the FFMPEG library that ZoneMinder uses to decode H.264 video streams. Apparently there was also a change in the method needed in order to force the RTP packets to be carried over TCP; in the past, you could append a "?tcp" to the end of the RTSP URI to force FFMPEG to use TCP for the stream, but that no longer has any effect. It now requires a code change to switch over to TCP. However, once I made the change, the smeared frames disappeared completely. Now I'm off to order more of these awesome little cameras.

Cost issues aside, there is also the matter of bandwidth and the quality of the data connection. I have a Galaxy Note 3 with a quad-core processor and 4G cellular data, and I see all kinds of problems when I access my cameras remotely. The frame rate is like a slide show, and the connection drops frequently. In the real world, even the much-ballyhooed 4G isn't up to the task of linking a remote IP camera. However, it's no surprise that this sort of BS fantasy would show up on eHow. Any self-proclaimed "expert" can just make **** up and post it and eHow doesn't care - they make their ad revenue whether the information they provide is any good or not, so why would they invest any resources in verifying any of the information they host? This is why whenever anything from eHow come up in a Google search, I won't even bother to click on them anymore (unless I'm in the mood for a good laugh).

My point is simply this: is a camera claims that it is capable of capturing in a certain resolution at a certain frame rate and providing a MJPEG stream from that captured video, then it is unacceptable for that camera to be dropping frames. In other words, the manufacturer shouldn't make claims that the camera's microcontroller cannot back up.

I have a IP8332 which exhibits the same issue. At 30fps I can see frames being dropped, with noticeable jumps every second or two; if I drop the rate down to 15fps it's no longer noticeable. Admittedly this camera is getting a little long in the tooth, but none of my Axis cameras of the same vintage have this problem (and they'd better not, since they cost 2-3 times as much ). Irrelevant. The camera should not be dropping frames irrespective of the chosen format. I see frames being dropped when viewing the stream directly from the camera in a web browser, so clearly HD performance is not a contributing factor.

That's fine as far as it goes, but the typical scenario in my household is my wife forgets to close the garage door while I'm off at work, so without an asynchronous alert of some sort that door might stay open for hours before I happen to notice it. Some cameras that have discrete inputs as well as relay outputs, in which case you can install a standard alarm system magnetic contact switch to your garage door and connect that to the camera's discrete input, then have the camera (or your VMS) send you an email or text message when the door is left open too long. This would prompt you to log in to your camera and close the door if needed.

You hand-waved on a pretty important detail there, my friend. So how will you know when the garage door has been left open? Do you have to keep logging on to your garage camera every few minutes to see if it's open or not?

Actually, Hikvision is the only manufacturer I know of that has that annoying requirement. I have IP cameras from Dahua, Axis, Vivotek, Linksys, Panasonic, and Arecont Vision, and none of them need any sort of a browser plug-in to configure the camera.

I don't have the cameras in front of me right now, but it's the same "weatherproof" connector that was posted here before.

Hey guys, Late Monday night I ordered a pair of the 3MP Swann bullets from Costco. They shipped out yesterday and arrived today (I live less than an hour away from the Swann warehouse). My units have a newer model number (825 vs. 820) and came with 5.0.0 firmware already flashed on them. They support the 3MP resolution setting right out of the box, so no need to risk bricking them by trying to reflash. Unfortunately, this version of firmware still lacks the option to disable the built-in IR LEDs. Other than that these are great little cameras (and I do mean little - they are amazingly small, about the same size as my Dahua eyeball camera).

...or if you brick it during a botched firmware upgrade.

Maybe, but I tried different kernel versions and still experienced the lockup, and the same kernel works fine with all the other drives in that system. If there is a bug, it's amazingly specific to WD RED 3TB drives. Unlikely, because the conditions and software have not changed; all I did was replace the reds with 7200RPM Seagate Barracudas. Mostly luck, plus some educated guesswork.

Irrelevant unless your cameras are directly connected to the Internet, which only an idiot would do. People with functioning brains put their IP cameras on a separate, dedicated network, isolated both from their other internal network(s) as well as the Internet using firewalls. It should also be noted that, if you take an analog CCTV system and put your DVR on the Internet to allow remove viewing, your DVR is every bit as vulnerable to being hacked as an IP system's NVR. OTOH, if you put your NVR/DVR behind a firewall, and only allow access to it from the Internet via a VPN, that's about as secure as remote access gets. Bottom line, the premise of your original post is clearly false.

Funny you should mention those drives. I bought 4 of those exact drives (2 for my Synology NAS, and 2 for my ZoneMinder server machine). Every 2 weeks or so the ZoneMinder box would lock up completely, requiring a hard reset to recover. From the crash dump information the kernel was somewhere deep inside the filesystem code at the time, accessing one of the WD reds. On a hunch, I replaced the 2 WD reds with Seagates, and voila! Not one problem since. I took one of those reds and put it into my desktop machine and it's been working fine so far; in addition, the 2 in my Synology NAS have been working fine for months. In both cases, the drives are used for bulk storage of ripped DVDs and video data. My conclusion is that the WD red drives are fine when used as storage drives but have problems when subjected to the constant 24/7/52 pounding of multiple IP camera streams being continually written to disk.

First of all, you post comes off as the paranoid ravings of a luddite who doesn't understand - and is deathly afraid of - the technology. But maybe my impression is incorrect; perhaps if you provided some verifiable facts to back up your claims you might be more convincing. Hundreds? Really? OK, name 5. Provide verifiable citations. Your post reminds me of Aesop's Fable about the Fox and the Grapes...

IIRC I paid around $800 for mine maybe 2 years ago. Worth every penny! Agreed. Unfortunately I have some special circumstances where I need to keep as low a profile as possible, and 850nm LEDs are extremely noticeable - especially super-bright ones like those on the Raymax. Even the 940nm LEDs are visible if you're looking right at the face of the iluminator. Angle is especially important for software OCR. For Human Character Recognition you can deal with more skew. However, some vehicles like pickup trucks with the license plate recessed into the rear bumper or SUVs with a big spare tire mounted on the back can block your line-of-sight unless you have a straight-on view. Care to mention which software you use and how much it costs?

I have captured plates from clear across the cul-de-sac, probably 60-70 feet, even at night.

That is awesome! " title="Applause" />

With a little simple surgery you can remove the IR LEDs from the Dahua eyeball cameras. http://www.dahuasecurity.com/products/ipc-hdw2100-195.html

Sorry to say it, but you're SOL on the plates or the perps' faces. However, if you ever see that car again it should be easy to recognize. Your mailbox post is an ideal mounting location, at least from a visual perspective. Two cameras, one camera pointing in each direction, will give you clear shots of every vehicle's license plate. You'll need cameras that can be configured with a fixed shutter speed of 1/500th or 1/1000th of a second to capture passing plates without motion blur. And lots and lots of light; adding IR illuminators and "long-pass" filters that block visible light will help to capture plates at night, assuming the plates are retro-reflective. If you do mount some equipment in that location, one thing to be concerned about is damage due to vandalism or accident. You'll want to take steps to protect your cameras so that the perps can't run over your post with their car or knock it over with a baseball bat. Something along the lines of "decorative" boulders or maybe some concrete bollards. You might also want to take advantage of the shrubbery and use it to help conceal your cams; perps can't vandalize your equipment if they don't know it's there. Alternatively, you could mount cameras with longer lenses further back, perhaps even on your house itself. My own LP cam is mounted about 15' from the street with ~40 degree viewing angle, and most plates are clearly legible despite the skew.

My DIY LP cam setup consists of [*] An Arecont Vision AV1310DN 1.3MP IP camera with a 1/2" sensor (set to permanent night mode) [*] 25mm Computar megapixel manual iris lens [*] 37mm IR filter (blocks visible light) [*] RayMax RM100 940nm IR illuminator (to make reflective plates legible at night) Total cost ~$US1300 This setup has been working well for a couple of years now. The only weaknesses are 1) non-reflective plates are illegible at night, and 2) because the manual iris lens has a fixed aperture a plate can get overexposed when bright sunlight is shining from exactly the right angle. I figure 2) could be overcome with an auto-iris lens, but since the AV1310DN does not support auto-iris lenses I would need a new camera as well as a new lens, so that experiment has been put on the back burner.