Dahua network connection saturating laptop CPU

[silencery 0]

Now I have to find a fix for the fact that the IP setting I set the camera to (and deselect DHCP) is overridden by the NVR once I hook it up to the NVR. I assigned a class 3 IP (192.168.1.xx) but the NVR automatically overrides this setting and assigns a class 1 IP (10.1.1.xx). It does not appear to be any way to turn off the DHCP function in the NVR, as I have already deselected DHCP and given the NVR a static IP in the class 3 range (192.168.1.xx). I used the configTool to assign a static IP to all the cameras before connecting them to the NVR and that turned out to be a waste of time...

 

If you want to use your own subnet or dhcp server and happen to have another POE switch, you can get around this by plugging the cameras into the switch and uplink that to your standard network. The NVR will still detect the cameras even if you're using the NVR's internet port and assigning your own IP addresses.

[MaxIcon 0]

While I'm amazed at this poor software engineering approach taken by Dahua, it is what it is, and I'm stuck with it. But your comment about the Intel chip having HD4000 video built in caught my attention. Did you mean that the Intel motherboard has the video built in, or is the i7-3770 built to handle this single core video load by itself?

 

I have an old desktop I built with as ASUS P4C 32 bit motherboard and a P5 3.2Ghz single core CPU that I retired years ago that I'm thinking may run this dahua stuff better that the new gear.

 

Certain Intel chips have video built into the CPU package. The current gen has both HD3000 and HD4000, depending on the processor level, and the HD4000 video performance is quite good for basic desktop tasks. On-CPU video will benefit a lot from being close-coupled to the CPU data bus.

 

I believe the i5-3570 is the only i5 chip with HD4000 (part of what makes it the sweet spot in price/performance), while many i7s have it. You'd have to look at their matrix to know for sure.

 

I ran some tests on an old Dell with a P4 3GHz Northwood CPU, and it choked quickly on MP cams. It was basically unusable for more than one camera.

[RickyGee 0]

THE SOLUTION: In thanks to this community and to all who helped me figure this out, I want to end this thread with the solution so that others who may find their way here might be helped.

 

It turns out that the root of all my difficulties was the built-in POE switch in the 3204V-P NVR. Despite many hours and all my attempts, the NVR would automatically assign Class One IPs (10.1.1.x) to the cameras attached, even though I had assigned static IPs in the Class Three (192.168.x.x) range to the cameras and turned off DHCP on both the cameras and the recorder. That made accessing the cameras directly after they were connected impossible. All attempts to assign a Class Three IP in the switch configuration tool (under the Advanced Network settings directly in the NVR firmware) were rejected, even though the manual shows an example with a Class Three address in the figure. Deselecting the conf_net.cfg_switch feature also would not take. When the NVR was restarted, the feature was turned back on automatically.

 

So, I shut off, deselected or disabled nearly every advanced network setting in the NVR via the internal firmware (attached monitor and mouse). I then used the ConfigTool (fixed by the explanation above) to individually assign static Class Three IPs to the cameras per my system design. Then I connected all 4 cameras and the NVR to the ports on the Zyxel POE switch, using only the network port on the NVR. I also assigned a static IP in the same range to my laptop LAN port adaptor, leaving the WiFi port adaptor set for DHCP to connect to my router and the Internet, and connected the laptop via the LAN port to the switch.

 

At this point, everything became easy; after connecting everything I could still directly access each camera and the NVR individually via the ConfigTool, the WEBSERVICE GUI, and could find and load them into the NVR firmware and the PSS software, all from the laptop.

 

After loading and testing the cameras individually into the PSS, I realized that by right clicking on the camera ID in the device block, a pop up menu (not in the manual…) would give the option of loading the extra stream rather than the main stream (not an option in the WEBSERVICE GUI). So I went into all the cameras and set the extra stream to D1, max quality (6) and max bitrate (768) and 5 fps.

 

Back in the PSS, I could now load all 4 cameras extra stream into the 4x4 view and the CPU is running at only 25%. By double clicking any one image it goes to single view and automatically changes to the main stream (1080P, 8192kbps, max quality (6) and 30fps) for full resolution view and the CPU goes to about 80%. Double clicking the single view returns the screen to multipane D1 and the CPU goes back to 25%.

 

The D1 resolution is perfectly fine for viewing 4x4 thumbnails and is visually indistinguishable from the main stream unless you zoom the image within the 4x4 view. Meanwhile, the NVR is recording all 4 channels continuously at 1080p, 30fps and displaying them on the attached monitor, with about a 1 to 1-1/2 second latency (I don’t have PTZ so the latency is not an issue).

 

So, I am happy I have a solution I can work with. I will need to acquire another Zyxel POE switch for the other zone and will avoid using Dahua NVRs with built-in POE switches for future builds. I am very happy with the NVR otherwise.

[RickyGee 0]

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.

 

Thanks, Dex for correcting my mistake. You are right. I tested my system as well and the load on the CPU seems split almost equally between the 2 cores with only about a 10% difference and near symetry, so it must be multithreading. That is good news.