Pixelated motion on IPC-HFW4431R-Z

[rinmak]

Hi guys

I recently acquired this camera in addition to my other 7 dahua's and have just noticed that when i review recorded footage of it, most if not all motion events appear to be staggered and pixelated. Like below:



My other Dahuas are all functioning fine. I'm recording using GeniusVision x64 Community Edition but also note that I have viewed the camera via VLC using its RTSP stream and I can observe the behaviour there, so this is happening pre-NVR.

I have tried various video configurations, bit rates, i frame intervals etc and none seem to have resolved the issue. Below is my base config that I would "like" to use ideally as it is what the rest of my cameras run with no problems at all.

NOTE: I have enabled WDR as it gives a much better image quality in the half sun half shade environment this camera is in. Also the adjustable zoom is set to 0 for the widest possible view, and focus @ 300.



Just chasing some ideas from the pro's as to what the root cause of the issue could be?

TIA
Ryan

 

[nayr]

lower your noise reduction

 

[rinmak]

lower your noise reduction

Thanks nayr, is that under Camera->Conditions->Exposure->3D NR ?

If so, this was on and set at 50. I have turned it off and will test when I get home.

 

[rinmak]

Okay now what I am seeing is the camera seems to "stagger". This happens in VLC as well. The video will be fine and smooth, then stop for say .5 seconds, then smooth, then stop and so on.

Then I go to upload an example video to senvid.com, and it converts it and the result looks like the original symptom.

This to me says codec issue with the new camera? Really not sure at this stage. Ideas welcome Have had nothing but trouble with this new model Dahua. Newer is not always better folks!!

 

[nayr]

looks like packetloss (dropping frames); sure your cabling is okay? try forcing VLC to use TCP instead of UDP..

 

[rinmak]

Hmmmm quick test I did just then....

Reply from xxx.xxx.xxx.xxx: bytes=2048 time=3ms TTL=64
Reply from xxx.xxx.xxx.xxx: bytes=2048 time=3ms TTL=64
Reply from xxx.xxx.xxx.xxx: bytes=2048 time=3ms TTL=64

Ping statistics for xxx.xxx.xxx.xxx:
Packets: Sent = 384, Received = 384, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 2ms, Maximum = 109ms, Average = 3ms

Should I up the datagram size to anything specific? Also forced VLC to use TCP with --rtsp-tcp command line switch and confirmed with netstat:

TCP xxx.xxx.xxx.xxx:50910 xxx.xxx.xxx.xxx:rtsp ESTABLISHED

...but alas

The video still staggers every second or two Connected to another camera of mine in the same VLC session for shiggles and as expected its got smooth motion

 

[fenderman]

Change the encode more to h.264 not h.264h...and/or try one of the other h.264 options. Also ensure that you are not recording the substream for this camera...and match the iframe interval to the fps in the substream as well.

 

[fenderman]

Double check the cable and power..is it properly terminated..did you follow 568b standards? is it solid copper not CCA...

 

[Ryan00]

This doesn't really have anything to do with your problem but noticed you had a fps and iframe at 20 any reason why ? If I was you I would turn them down both down to 10 you will use less CPU

 

[Ryan00]

I would also change the bit rate to constant

 

[rinmak]

I'm running 568A throughout my whole system....but this shouldn't affect it should it? The other Dahuas I have seem fine.

Would I see packet loss if it was a cabling issue? Because I dont :/ Even with a datagram size of 10,000

Reply from xxx.xxx.xxx.xxx: bytes=10000 time=3ms TTL=64

Ping statistics for xxx.xxx.xxx.xxx:
Packets: Sent = 128, Received = 128, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 2ms, Maximum = 3ms, Average = 2ms

Although, I do note the highlighted differences below in switchport statistics. Does this give any clues? I'm thinking I will need to un mount the camera and plug it directly into the switch to eliminate the cable run. Shame as I'l lose the camera alignment but seems we are getting to that point in troubleshooting?

Faulty Camera....
GigabitEthernet1/0/8 is up, line protocol is up (connected)
Hardware is Gigabit Ethernet, address is xxxxxx
Description: To ipc-rearyard
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 2/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, media type is 10/100/1000BaseTX
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 1167000 bits/sec, 101 packets/sec (Note the lower packets/sec rate compared to below)
5 minute output rate 26000 bits/sec, 5 packets/sec
836490419 packets input, 1174549284330 bytes, 0 no buffer
Received 48776 broadcasts (6835 multicasts)
0 runts, 0 giants, 0 throttles
2 input errors, 2 CRC, 0 frame, 0 overrun, 0 ignored (2 CRC errors, enough for concern? Port uptime would be approx 18 hours)
0 watchdog, 6835 multicast, 0 pause input
0 input packets with dribble condition detected
23212045 packets output, 1992805451 bytes, 0 underruns
0 output errors, 0 collisions, 13 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 PAUSE output
0 output buffer failures, 0 output buffers swapped out


Known good camera....
GigabitEthernet1/0/6 is up, line protocol is up (connected)
Hardware is Gigabit Ethernet, address is xxxxxxxx
Description: To ipc-rearcorridor
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 6/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, media type is 10/100/1000BaseTX
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 2522000 bits/sec, 313 packets/sec (considerably more packets/sec from the camera on all my working cams)
5 minute output rate 32000 bits/sec, 1 packets/sec
623842701 packets input, 598382734879 bytes, 0 no buffer
Received 82035 broadcasts (37233 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 37233 multicast, 0 pause input
0 input packets with dribble condition detected
12555033 packets output, 1189970382 bytes, 0 underruns
0 output errors, 0 collisions, 1 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 PAUSE output
0 output buffer failures, 0 output buffers swapped out

 

[rinmak]

This doesn't really have anything to do with your problem but noticed you had a fps and iframe at 20 any reason why ? If I was you I would turn them down both down to 10 you will use less CPU

Thanks mate, I will try this but my other dahua's handle 20fps/20iframe just fine and I was hoping to match my existing config with this new model. One would assume its just as if not more powerful than my older models!

 

[Ryan00]

Thanks mate, I will try this but my other dahua's handle 20fps/20iframe just fine and I was hoping to match my existing config with this new model. One would assume its just as if not more powerful than my older models!

You shouldn't notice any difference between 20 or 10 at least I can't, even at 30 fps and 10 I can't tell a difference.

 

[fenderman]

Either 568a or b works...What brand of cable and how long is your run..

 

[rinmak]

The cable is this product below:

Clipsal - 2D4P6IPV3B - LAN Cable, 305m, Category 6, UTP

And the run would only be 25-30 meters at most.

The one thing that differentiates this from all my other runs is that I had to join the cable along the way as it was cut short originally when I had planned to put the camera elsewhere. I joined it by terminating it in my roof space with a cat6 keystone jack and then extended by making a patch cable to run the rest of the length.

 

[fenderman]

You gotta take the camera down and test..

 

[rinmak]

Okay so I have taken the camera down and tried it on another known working cable run, which also links to a different switch port.

Unfortunately, I still observe all the same behaviors from the camera

At this stage I'm effectively out of ideas. All I can put it down to is a faulty camera or a firmware fault.

Some points/questions....

1. Is anyone familiar with Dahua firmware that can provide a link to older/newer firmware that I could try flash it with? Its an NTSC IPC-HFW4431R-Z and its currently running 2.420.0000.21.R, Build Date: 2016-07-24

2. What effect would changing the video standard have? The camera is set as NTSC by default but I have the option to change to PAL. Wont brick the camera will it?

3. I should also mention it is running this firmware (GitHub - BotoX/DH_IPC-HX4XXX-Eos: Dahua firmware mod - ONLY FOR TRACKING CHANGES DO NOT CLONE THIS TO BUILD FIRMWARE, GITHUB BREAKS PERMISSIONS ETC.) which is a modified and re-packed version of a Chinese one to enable the english language on it as well.

 

[alastairstevenson]

Have had nothing but trouble with this new model Dahua. Newer is not always better folks!!

Was that before or after it was running the custom firmware?

3. I should also mention it is running this firmware

Perhaps the first thing that should have been mentioned.

 

[rinmak]

Unfortunately I hadn't tried to record before upgrading it. There was a bug with the snapshot.cgi web interface that forced me to upgrade practically straight out of the box. Did it, realized its a chinese only firmware and had to flash again to this modded version to correct.

Dahua Firmware Mod Kit + Modded Dahua Firmware

I had assumed it was simply my video settings doing it at first, appologies for not mentioning sooner. It honestly only just occurred to me now that we're scraping the bottom of the ideas barrel.

 

[c hris527]

Hi Guys, I have one of these and it has been a nightmare, figures it was for my personal use but the good thing it IS going back to the seller. Everything from crappy choppy video to suppose it "SMART" Ir features it has been a BIG disappointment in comparison to my other DAHUA cameras. It could be firmware but after spending over 6 hours of jerking off with this camera IM DONE. This is a Chinese camera with English firmware so who knows WTF is cooked into this but it does not work like I thought it would. I have installed so many the vari focal cameras with NO issues. The smart IR does NOT work and I have had crappy video like others have had. I have tried EVERY different setting and to be honest..Had Enough. I got mine from Amazon so the return should not be a issue.