dexterash

I wouldn't compare portable/user-interactive/seldom used technology with 24/7 running technology. Why? Let's see: -if a router stops, you can reset it since, usually, it's in your house; -if a DSLR will give an error writing on card, you would just see that imediatly and replace the card; -if a portable camera will have any error, you will retry until correcting the error What happens in (real) security vs personal/portable products: -they are made to work 24/7 -they are made to "auto-work" - without any user prompt/interferance -they will self-correct their errors/hardware errors and will alert/report; in fact, most errors are or solved or reported by the equipment -they are designed to be scalable -they are designed to serve more then one purpose or one user, at a time -they are designed to work in hostile enviroments... how often would you expose your camera to rain or direct sunlight or... L.E: @GMaster: encoding is (at max) 30-50% of an IP camera's job, and, usually, it's done at a dedicated processor level

Well, isn't it enough that people brick DVRs&others through web/net updates? Should they brick products via low-level flashing too (which is 95% unrecoverable without desoldering SoCs)? This is from my personal experience with people updating DAHUA's products... 90% don't know what they do, but think they will get a better product (like a software update will ever sky-rocket a hardware's performance...).

Opening a port is done by a service/server listening to that port. (or a firewall rule) When he said "open up all ports out of frustration" I supposed he said DMZed the IP. Later observation: Port forwarding works, if it's done in a RTFM way. For example, never forward in TCP+UDP mode if port is TCP asigned.

You didn't specify if you want to directly access DAHUA or use a Milestone/other client? What cameras? How many channels do you want to see?

I suppose he was referring to DMZ. Anyway, DMZ only works on one IP, so that's not a big issue.

Of course you can telnet into the camera, but the "scariest" thing you could do is to delete all configs (you cannot change passwords easily - they are hashed and salted as i do remember; on DVRs, they sure are). A company installing these cameras should use dedicated IPs or, even better, VLANS or any sort of separation (even IP filtering, since it's supported by all devices). Newer versions will support also MAC filtering. DAHUA supports very well their resellers. They do not support end-users. It's a scary job to support all (lack of knowledge, a bunch of options on devices, solutions to implement, ways of interconnecting etc). Your source for firmware should be your seller, whomever that is.

So and so, since: -888888 and 666666 are only "local" users, so no access from Internet -telnet is only vulnerable if you forward telnet's port... but this can happen to 50% of the embedded systems out there -OnVif bugs were in a test version, but people used it as a release -captcha is Ok, but, for example, you can't brute force a DAHUA since after 3 atempts it will block the user for a period of time or until reset; and, of course, as you do know, there are already captcha-bypassing algos But mostly problems do appear due to bad usage/user involvement: Wireless IP security should be a NO from start (but they all users want this, since most hate cables runing through their houses), changing default passwords should be the first thing you do when you install a camera(and this should happen to anything password-protected) and there are more... Of course, bugs are and can be in any system. (for example, how buggy is a Windows based DVR/surveillance system?)

IMHO: this should be done via dedicated software/solution, since there are many posibilities/configuration combinations/etc. It's hard to integrate every client's request in a "general" software. If all options are left open (so they can be configured), would be a pain in the ... to configure the solution. For example, let's say a software will integrate all the posibilities/combinations/options etc. Usually, no more than 2-10% of them will be used by the client/user. So we have 90-98% of "bloatware" around.

Also B/W requires less amount of processing power.

There are several SDKs available for ANPR. So writing a software to use integrated with a SDK from a camera manufacturer isn't an yearly job, but: -you depend on the quality of the ANPR engine -you still have to solve some issues and, probably, customize the engine

Before any installation, I would test it to find out how it performs in those conditions.

I know, but using advanced video analytics this can be changed and obtain an image closer to real one. The angle was like this because the camera was mounted on a car (yes, the image was obtained while in motion - both our car and the car in the image)

I was pointing out the need to use a dedicated camera, since not all cameras can help in making ANPR. Software is in development, in-house made, for using with this camera.

Yes, I had the same question. Is there a way to permanently commit the routing tables, i.e. maybe with a startup script? Nope, read-only filesystem... also no startup script, unless one reverese-enginere the full firmware (of a security system, btw ).

During daylight, it might/should work... But how about night? Attached is a LPR camera snapshot. That's my point

Some of the cameras that are talking about here. At daylight, with no highway speeds, any camera should/could take a pic of a car's plate number (trigerring it's another subject). I was just courious how things go on during low light/night light.

I'm courious of any footage during night, front capture (headlights on). Has anyone got any samples?

I've tested it now. As you can see, it's multithread (at least, equal CPU usage when started to decode) Streams are from 2 remote MP Speed Domes, 1 remote MP 3200 and some channels of a D1 DVR. System I've used: Dell XPS430 with Q8300 CPU (C2Q@2.5), 6 GB RAM, ATI RADEON HD2600PRO and Win 7 64 Ultimate.

I'm sure it depends on your source, if it's an official DAHUA one or ....

This works until reboot...

Have you tried the latest version of PSS(available @DAHUA's site)?

also "initialize and script activex controls not marked as safe" to prompt

1)Can be run on any version, but it's best to be installed on 32 version using admin rights 2)Can be run 1+2- they are not designed for a 64 arch; they will not run on an 64-only system; they rely on Windows compatibility to run them in 32 mode 3)yes and no; DAV is a file format with a header containing parts of that stream 4)same as 1,2... As an overall, these systems are not designed to harnest the power of the GPU (most modern movie players do that), so they rely on CPU (as in "software decoding"). If you wonder why, I can tell you that there are dedicated solutions to decode&display the stream - one of them is your NVR. Also, the whole system can function and can be used with no PCs at all, even if you scale up the system. Doing this using only dedicated hardware makes a robust system. Solutions are provided, as an alternative, for PCs(like PSS)&other devices(like mobile devices), but that doesn't make them a primary device/robust device.

I doubt you will get it out from that state... it's software bricked

Brand/Supplier of cameras?