dvarapala

I will second the nomination for Axis. My first IP camera, purchased in 2010, was an Axis outdoor dome, and it's been running without a glitch ever since. Since then I have purchased several others, most recently a P5635-E, and am quite happy with all of them. There are cheaper brands, and I own several of them. In my experience, Axis is worth the extra cost.

For the past few weeks I've been playing around with OpenALPR (http://www.openalpr.com/) and integrating it with my ZoneMinder (http://www.zoneminder.com/) system with good results. I don't get much vehicle traffic near my house, so to get some sample data I set up a camera with a good zoom lens and aimed it at a busy intersection about a block away. Although the placement is far from optimal, with the view partially blocked by trees, there is still a small peephole where passing cars are visible and plates can be recognized. Despite this handicap, the recognition works surprisingly well. Compiling the OpenALPR source was pretty straightforward; the hardest part was tracking down compatible versions of the various libraries that OpenALPR depends on. The result is a library and a C++ class that you can include in your own programs. ZoneMinder provides a "trigger" process that external software can connect to and receive notifications whenever motion is detected on a camera. I wrote a small daemon that connects to ZoneMinder's trigger daemon and, when it receives a notification that motion has been detected on the LP camera, it retrieves the frames with motion from ZoneMinder's database and runs them through OpenALPR for analysis. When you pass an image frame the OpenALPR it returns to you a list of possible matches along with a confidence estimate. For example, a plate like 5KNP922 might return 5XNP922, 5KMP922, 5KWP922, 5XNP922, 5KNP927, and 5KNP922 as potential matches, with no easy way to determine which one is correct. Obviously this would be problematic for a "big brother" type application which wants to track every passing vehicle. This was less problematic in my application because I have a database of "known" license plates that the software can query; if one of the candidates detected by OpenALPR exists in my database, it is considered a positive match and the presence of the vehicle is logged. While the possibility of a false positive exists (for example, if both "5KNP922" and "5XNP922" are present in my database, my log would contain entries for both vehicles even though only one of them was actually present), this probability is acceptably low for "hobbyist" purposes. And again, my camera setup is far from optimal; with proper placement there would undoubtedly be less fuzziness in the results. OpenALPR takes significant CPU time to analyze a frame, so I run it in the background at low priority so as not to interfere with ZoneMinder's normal activity; frames with detected motion are queued up by a foreground thread. ZoneMinder's motion detection culls out most of the frames, so a passing vehicle might result in only a dozen or so frames being analyzed, which is quite manageable. It usually takes 5-10 seconds from the initial motion detection to determine a match. My test camera has a view of an intersection where cars are making a left turn. The camera is focused on the apex of the turn, where the back of the car is parallel with the focal plane of the camera. Thus each passing car produces a series of frames where the plate is at various angles WRT to the camera, with a couple of straight-on frames in the middle of the sequence. From this setup it is very apparent that the recognition is sensitive to the angle of the plate with respect to the camera; there is a fairly narrow range outside of a straight-on view where the recognition will still work, but outside of that the recognition fails even though the plate is still perfectly legible to a human. In addition, OpenALPR seems to have an easier time with light-colored vehicles. This may be because the plates appear as dark characters on a white background, so a light-colored car may blend in to the background better. My next step will be to optimize my camera placement.

If not, the OP can always buy an Axis.

I've used both, but my phone (a Galaxy Note 3) is easier to handle. The main problem is using it outdoors in sunlight. I generally wait until evening when the screen is easier to see, but I've also considered just throwing a blanket over my head.

FWIW, on a LAN it probably matters little which transport (TCP/UDP) you use. You probably have a gigabit of bandwidth, and full-duplex links between each camera and the switch hence no collisions or packet loss. What's undoubtedly causing the delay you're seeing is the CODEC. CODECs like H.264 minimize network bandwidth by doing lots of processing, and each stage of that processing requires buffering, which adds noticeable latency. This is why I always prefer MJPEG streams over H.264 when the camera gives me a choice. Bandwidth is not an issue on my dedicated gigabit LAN, and the latency with MJPEG is minimal. On my Hikvision cameras, which don't offer an MJPEG option at 1080P resolution, There is a noticeable delay of 2-3 seconds between the Hiks and my MJPEG cameras. If the latency bothers you, try switching your cameras to MJPEG mode.

That's been my experience as well. If something goes wrong with my Dahua or Hikvision cameras, their pricing is such that I can simply throw them away and not feel too bad about it. In my experience Axis is still head and shoulders above ACTi. The Axis cameras I own simply work - no surprises, no hassles. My very first IP camera was an Axis vandal dome, and that camera is still in service today almost 5 years later without a single problem. I can't say the same for the ACTi cameras I own. The overall quality of the ACTi image is noticeably lower, and there are strange quirks and bugs which range from annoyances to outright showstoppers. When I went to ACTI's web site to report these bugs, they wanted me to jump through a bunch of hoops and send them copies of invoices and such. I can understand requiring that for a warranty repair, but to report a firmware bug? When you report a bug to Microsoft do you have to FAX them copies of your sales receipt to prove that your copy of Windows is legitimate? As a hobbyist, I can afford to put with with a certain level of BS in order to save some money. However, if I needed reliable cameras to protect my business, I would spend the extra money for Axis every time.

The main differences between a regular IP camera and one marketed for license plate capture is usually the lens and a special filter that blocks most visible light while allowing infrared wavelengths to pass. I'm using a regular IP box camera, a 25mm lens, and a threaded filter that screws onto the end of the lens, all mounted inside a standard outdoor camera housing. The illuminator is a RayMax RM100C, the "covert" version which emits 940nm light and is less noticeable to the naked eye than the standard 850nm illuminators. This setup produces excellent results as long as the plates are retro-reflective (e.g. California). Some states (e.g. Nevada) are using a different type of plate which appears completely blank using this type of setup. I would love to know what equipment ALPR companies sell for use in Nevada and other non-reflective-plate states.

So you're saying that if I license their software it will do real-time lookups in the DMV database? What information will I get? Registered owner name and address? Make/model/color of the vehicle? Will they do it for anyone with the $$$, or only for "authorized" agencies?

Perhaps it's because most residential installations are mounted up in places like eaves which are usually painted white? A white camera blends in naturally on a house with white trim. I second the recommendation for the Kyrlon Camo ultra-flat spray paint. I have painted several of my outdoor cam housings and this paint holds up quite well.

You're right, that camera is not "vandal-resistant" in any way. Your best bet would be to replace it with a "vandal dome" unit which is specifically designed to resist attempts to knock it down. Prepare to spend more money, of course... Alternatively, mount your existing camera way up high, well out of reach.

Haven't you ever watched 24? CTU already has the ability to remotely tap into any CCTV camera anywhere in the country.

Kawboy posting that link is a non-issue. There is free open-source software available now that can scan the entire Internet in mere minutes. Any cameras that are out there have already been found many times over.

Nagios can certainly do that, and you can't beat the price.

Normally any software which can take advantage of multiple cores will automatically use all available cores without any special action on your part. Are you sure there are 8 cores actually available on PC #2? For example an i5 without HyperThreading will only have 4 cores available for software to use. If the CPU is an i7, maybe the BIOS in PC #2 has a setting that disables HyperThreading? Also, are you running the same Geovision software on both systems? Same version? All configuration settings the same?

On the strength of positive reviews, I just ordered an ACTi KCM-5611 IP cam. The camera acquires an IP address via DHCP, and I can capture video from it, but I am unable to log on to the camera's web server, and the "IP Utility" software that ACTi provides doesn't even start up correctly. When I go to the camera's web server, I get an empty page: The IP Utility fails with this error dialog: After dismissing that, it hangs forever on this screen: The camera is never detected. There is an SSH server on the camera, but it doesn't recognize the default Admin credentials. Anyone know what the login is for SSH? So far I'm not real impressed with ACTi... I own about a dozen IP cameras from a bunch of different manufacturers, and this one is giving me the most trouble by far.

In my ongoing experiments with capturing license plates I have been looking for a camera that can do a better job than my current LP cam, an Arecont Vision AV1310DN. To that end, I recently purchased an ACTi KCM-5611 and swapped it in place of the Arecont. On paper this camera sounds great: good low-light performance, remote focus and zoom, relatively compact size. The results were surprising: From the same location, using the same exposure settings and the same RayMax RM100 illuminator, the ACTi didn't even come close. During the day the picture was fantastic, but at night it went to complete crap: low contrast and so much noise that many plates were illegible. But the final nail in the ACTi's coffin was the frame rate: for reasons as yet unknown, this camera often delivers frames in a very bursty fashion; while the overall frame rate might average out to 30fps, the actual rate varies wildly from one second to the next. It might deliver 15 frames one second and then 45 frames over the next. This is plainly visible even when connecting directly to the camera using Internet Exploder (which ACTi forces me to use, since it doesn't appear to support any other browsers - but that's another rant ). Since my VMS records the timestamps of each captured frame and calculates the inter-frame deltas when playing them back, the same burstiness is aggrivatingly evident during playback as well. Sometimes the frame rate is stable, such as in "day" mode with the exposure set to auto or immediately after rebooring the camera, but to capture blur-free license plates at night I need a fixed shutter speed of 1/1000th or 1/500th and that setting seems to bring out this frame rate bug. I have a total of 14 IP cameras from several manufacturers, and none of them have given me the problems that this ACTi has. Needless to say, the Arecont Vision has been swapped back in and the ACTi is destined for more mundane duty elsewhere in my system. Here are a couple of frame captures so you can see what I mean. Again, these are with comparable exposure settings, from the same mounting location, and using the same IR illuminator.

Sort of. The ACTi camera I have is running an SSH daemon, and you can log on to it using the default credentials (note that the 'a' in "admin" must be lower-case) but after accepting your login it just hangs (at least mine does). IOW it's pretty much useless. There is a fairly complete list available on their web site. Search for a .pdf file named something like "ACTi_Camera_URL_Commands_".

Doesn't help. Script kiddies doing port scans will usually scan more than just port 80. My web server ports are up in the high end of the range, and I still see script-kiddie probes every night in my logwatch reports. A better option would be to enable as much security on incoming connections as possible. Digest authentication is a good start; requiring all connections to use https and validating the client-side certiicates is even better.

I'm sure you're aware that Google has a fleet of cars which drive around taking video and sniffing WiFi; if not, read more about it here. Among the WiFi data that Google collected is the MAC address and geographic location of every WiFi access point they encountered during their Wardriving. This data is available to anyone via Google's geolocation API. Thus, if a Black Hat can somehow determine the MAC address of the WiFi access point at your home, he can find out exactly where that access point is located to within a few feet. To see one way it can be done, watch this: tRJMIMBVqFI I register my domains through namecheap.com, and they provide DDNS for all of my domains at no extra charge. Rock solid as well.

After much futzing with the settings in Internet Exploder (which I don't ordinarily use) I was finally able to configure the camera. For the benefit of any future explorers who are trying to resolve similar issues, I basically enabled anything I could find related to running ActiveX controls and anything related to "compatibility" modes. Of course, doing this leaves your computer open to all sorts of security exploits, so be sure to restore the original settings prior to surfing the Internet. If anyone from ACTi is reading this and gives a dang, you really need to stop drinking the Microsoft Kool-Aid and come up with a more portable way for users to configure your cameras. This may come as a shock to you, but not everyone runs Windows, and not everyone wants to use Internet Explorer. I realize you feel the marketing need to make your embedded web pages look nice and pretty, but there are better ways to accomplish this - just look at Axis, HikVision, Dahua, or just about any of your other competitors to see how this can be done without any of that ActiveX bull****. Your current method is not only non-portable, but when it fails to work it gives absolutely no indication as to why it's not working, which is frustrating your customers to the point of madness. Configuration issues aside, this seems like a really nice camera; however, I'm definitely going to have to think long and hard before purchasing another ACTi product.

I only wish it were that easy. Different types of cable have different diameters and require different RJ-45 connectors to crimp successfully. As an example, the crimp-on connectors that work fine for regular indoor cat5e simply will not work with the outdoor direct-burial cat5e that I bought. The shielding and extra insulation make the diameter of the cable just too thick to fit physically into the connector. I ended up doing what the OP did and punching the cable down to a keystone and using a short patch cable to go from the keystone jack to the camera. l-com.com makes some nice little single-keystone bezels with screw mounting holes that you can snap the keystone into if, like me, you don't want to just leave the keystone dangling loose inside the junction box.

^this, especially any seller associated with AliBaba. I've heard so many horror stories about AliBaba and its derivatives that I would not touch them with a 10 foot pole.

Regarding browsers, I tried Internet Exploder, Chrome, and Firefox (all latest versions) under Windows. Tried running them "As Administrator" and in "XP Compatibility Mode" with no success. I tried Firefox from a Linux machine. I tried Firefox, and Chrome on my Android tablet. I even tried the browser on my Kindle Fire. All result in the same empty web page. My guess is the web pages need some sort of ActiveX control in order to function, and that control is not able to run. The IP Utility appears to require the same ActiveX control, so if you can't run the ActiveX control you have no recourse. Really annoying and lame! All those people who run OSes other than Windows (MacOS, Linux) are SOL right from the git-go. I also discovered that the SSH login wants a lower-case 'a' in the username (i.e. "admin" not "Admin" as the documentation suggests), but once you're logged in it simply hangs forever - alas, no help there. I've come to appreciate my Axis cams a lot more in recent weeks. Axis might cost more, but that extra money allows you to avoid a LOT of hassle.

This would be easy to do with an embedded microcontroller experimenter board like the Arduino. Hobby servos are easily controlled by PWM outputs from the microcontroller, and you can send commands to the microcontroller from just about anything you want (via Ethernet, USB, or even a standard CCTV PTZ joystick over RS-485 using Pelco protocol if you so desire). The only catch is you're going to have to write the software yourself (or pay someone to do it for you). The Arduinos are designed for use by artists, so they're about as easy to program as embedded systems get, and might be within your capabilities. Just for fun, I used an embedded microcontroller (not an Arduino) to control a hobby servo with a Mobius action cam mounted on top and slapped the whole contraption on my car dashboard to use as a dashcam; I programmed the servo to track the angle of the steering wheel, so that the camera would point towards the direction the car was turning. It was pretty easy to do.

In America, that story would end with "You're under arrest, Mr. Jones, for filing a false police report." In addition, Mr. Jones would end up with a longer prison sentence than the burglar.