dexterash

Missed that point. Doesn't it complain about maximum incoming bandwidth? I don't think it's usual to let you use/plugin cameras with a total bandwidth higher than supported. How about setting cameras at 1080p, rather than 3Mp?

What computer power can handle 16 FullHD streams? As in playing 16 FullHD movies at the same time? Your best bet, for now, is to get a switch only for the cameras and the NVR, with a high internal switching bandwidth/rate.

How are the status LEDs of your switch? Does the camera power/connect at all?

Yet, 1/3 of your image is useless... Do you think you will ever have any motion or something good to record in that 1/3 part of the image that is a vertical, white, static wall?

No offense, but since when PoE switches assign IP addresses? If the NVR is PoE, the NVR will assign IPs!

TI's DaVinci series are kind of old, yet popular. Implementing new SoCs means a lot of work, since you have to make something (very) stable and secure. It's not an easy job. I doubt a router can have enough horsepower to manage the recordings - meaning taking them from the LAN and "dump" them on attached USB storage. Secondly, you need and easy, powerful and fast way to search through recordings - again, not an easy task. And the biggest problem is reliabilty/prioritisation: you NEED the recordings - it's not something like "Ok, the page didn't load. Let's refresh the page." or "Reset the router". Routers suffer from the same "symptoms" as the IP Camera does - SoCs pushed to maximum. NVRs also, NASes also. Putting them to do mutiple jobs will result in problems. Even latest NASes from Synology (for example), if you let them do multiple jobs - let's say a simple webserver, a mail server, storage and Antivirus Scans you'll see a very big drop in performance.

Not a very big surprise! All IP cameras ran on Linux even in the under 2008 days, when they weren't so popular. Also, it's not just a trick of coding, rather a problem with the SoCs (alias the combo of CPU+RAM) inside the cameras that make your wanted functions hard to implement or even impossible. Writing to a NAS/FTP/NFS server can take as many CPU cycles (power) as the cycles used by the CPU to compress the data for SD Cards (which is one of the most "hard" things to do and usually gets the SoCs to a high limit). Trust your feelings - if it was so simple, why didn't they implement it? The simple answer: because it's nearly impossible with a low CPU/SoC driven to it's max capabilities - hence the "chineese" price.

In an usual/good setup, NVRs connect to cameras, not otherwise. So, at first, you'll have to figure your needs, find a NVR that can suit your needs - in resolution, number of channels and framerate/fluency - and search for cameras that are compatible with that NVR (usually, a trusty NVR manufacturer will list that; also, a very good starting point is to look for cameras that have the same manufacturer as the NVR). Usually features are equal between a good WiFi camera and a wired one.

Better ask directly DAHUA. They are good asian-wise language speakers.

Or maybe 32k... But I still wonder... Can the reflection in a one, 1x1 , black pixel be enhanced up to a level that can be transformed into a real picture, using digital zoom on recordings?

If your camera doesn't support NAS/NFS/FTP connection, there isn't much you can do. The "workaround" would be that the Linksys would connect to the camera, but I doubt your or any current model does this.

DVRs record only analog, "BNC-type" cameras. NVRs record IP-Cameras - either Ethernet cabled or WiFi. PCs and other computers can be used to record cameras, but they are a flaky/non-stable solution. What happens if your PC hangs or reboots when it should be recording an important event? So the best way is with NVRs. But, for the ideea's sake, beware of WiFi cameras - they can become a nightmare if anyone would enter/hack into your wireless network. From security devices they will transform into silent, peek devices.

As a side note, this is one of the reasons why it's recommended to use a NVR rather then a NAS for video storage. NVRs (usually) offer all sorts of functions to get to the right recording, at the right time.

Very Good Point. I'm a DAHUA fan, but I can state this: all DAHUA DVR's/NVR'S have software watchdogs - meaning if you somehow manage to kill the software that is behind these products, they will reboot (interval ranges from 2 to 5 minutes) if the software hangs/isn't present. They use off-embedded hardware electronics for this. I can give more details about this feature, but I don't like to make it very public so it can be used as a tool for others. Actually, a security video system is as stable as it's components - or the lowest link. Get a low quality/doubtfull link and the whole chain is useless.

What NVR? RAW means uncompressed video and is usually very big. At least, just like a BMP file.

Hello Analog/HDCVI Megapixel or IP? What's the max resolution? What protocol for PTZ? Cheers!

Since it has to do with the hardware, you can't do much. You can check some different AWB/exposure settings that might lower that effect, but there isn't any magic solution and you might get to other problems. Your best bet is to change/try different(as in better) lens.

I was just trying to envision the problem and if this kind of solution is what you are looking for. A 1920x1080 or a 1280x720 one can, usually, take up to 1MBps (8Mbps) if it's using H.264 (not MPEG4/MJPEG) compression and the max quality settting. Newer ones are lowered to approx 3Mbps(400KBps), but you'll get a quality loss. There can be an out-of-box solution, but the image stiching has to be done hardware-wise (as in optically aligning the cameras). We' re looking for a solution to efficiently software crop&re-stream a part of a stream, but that's not an easy option. Yes, that is the camera. I've just used it to be sure we're talking about the same concept. No, the camera itself doesn't have this feature - nor does any hardware that we've worked with. You're very right - it would involve a server between. Digging after a solution, but a bandwidth limit could give us a clue what should we be after to obtain - and also an implementation case. Cheers!

HDMI port is one, Analog TV OUT port - BNC Connector marked as Video Out - is a different one. Manuals are generic for these products, since the product line is very dynamic, trying to keep up with the latest technologies available. The eSATA feature I cannot confirm for now (bad memory), but the TV OUT one is a sure thing. L.E. S/N will not change on update. Also, if the firmware is bad and the update is done via the official way, the worst it could happen is that you'll get an error, but the NVR will not update.

First of all, I would test a low-latency/close to real-time soluton, like a PAL Camera + DVR or an HDCVI Camera + DVR. Secondly, I suppose that you should tune the H.264 codec parameters and 3rd you should use a dedicated client software (something especially written for this kind of solution), probably using a SDK. But I don't think you'll get a 100% at .5 second accuracy. Another approach would be to find another way to sync them, not through time (maybe frame counting or something like that) or a fast device that will snapshot at a (very) precise time. FTP and RTSP don't think will help you too much.

Something like this? What would be a target bandwidth?

If you have TV OUT and an eSATA connector, it's a 5208. If not, it's 3208.

Depends on location. Some of them are the S/N of the motherboards, not the product itself.

DAHUA's new models have the NAS option, including NFS mount. But I would recommend to go on the DVR to NVR (actually NVR to DVR) way, since the solution is close to realtime and no file open/file closed operations are made that could delay data backup.

Just one simple question: are you sure it is able to stream 4K via IP?