Dahua HFW2100 - what could cause this?

[mroek 0]

Hi,

 

Take a look at the attached image. It is a 100% crop from one of my HFW2100 cameras, and the snapshots are just a few minutes apart (early morning). The top part is taken prior to the bottom. As you can see, the top image is blurry and has a little less saturation than the bottom image, even though both are clearly color images.

 

What could have happened here? At first I thought the blurry image was with the IR-filter active, and that the camera for some reason had switched to color mode without moving the IR-filter out of the way. However, when I manually switch the camera to B/W (and I can hear the IR-filter moving), the image is still not nearly as blurry as the top image.

 

This was yesterday morning, and this morning I noticed the same thing, that the camera had a blurry image. I then tried manually switching it to B/W and back to color, but the image was still blurry. Then I rebooted the camera, after which the image was normal again.

[Korgoth Of Barbaria 0]

Have you tried changing bitrate from CBR to VBR?

[mroek 0]

No, I haven't. I've always thought that CBR would be the way to go.

[Korgoth Of Barbaria 0]

No, I haven't. I've always thought that CBR would be the way to go.

 

I don't have much experience witch Dahua brand (just starting with those cams) that why I'm not sure if this will help. But I had similar problem with some other brands, like GeoVision. Camera needed some more space to push data, and when there is no room, it eats detail.

[mroek 0]

Not sure I understand why that would be so, given that CBR is "constant", so whatever is encoded there should not be any more or less data to push. I'm not questioning your real life experience, it's just that I don't understand the reason why it would be so.

 

I've now tried changing from CBR to VBR (at "best" image quality), and for a static image the bitrate seems to be more or less exactly the same, around 4000 kb/s. I'd have expected the actual bit rate to drop quite a bit, but it doesn't. Image quality also seems to be pretty much identical.

[Korgoth Of Barbaria 0]

Maybe its because my english is not good as it should be

 

Its all about H.264. When there is no motion on scene and you have quite good light, bandwidth should be quite constant. But for example noise caused by lowlight, or motion will, rise that bitrate because H.264 needs more data to push. If you have constant bitrate, it cant push more than that limit so it cuts off details.

[mroek 0]

Aha, then I understand what you mean. However, if that was the case with this specific image/scene the same problem should have been present even after a reboot.

[kifaru 0]

Korgoth .....that was a very good explanation

[ssmith10pn 0]

Maybe it's not a P frame on the playback?

[mroek 0]

Maybe it's not a P frame on the playback?

Not likely, I think. I also have recordings with moving people in them, and they look normal except for the fact that everything is blurred/less detailed.

 

The live view was also the same.

[ssmith10pn 0]

The live view was also the same.

 

Ahh sounds like focus shift.

 

Try focusing the camera in low light but with no IR.

[dexterash 0]

how did you capture the images?

first one seems an extra stream capture and second a mainstream capture...

[mroek 0]

The images were captured from recordings made by Synology Surveillance Station, but I am certain that has nothing to do with it. As mentioned, the live stream was identical, no matter how I viewed it (camera web interface/rtsp/tcp 37777).

 

I am leaning towards Korgoth's explanation about image noise causing the h264 encoder to saturate the bandwidth, and thus dropping detail. Currently it is dark outside, and the camera has compensated by upping the gain quite a bit, and this causes a lot more noise, which in turn makes life difficult for the encoder. I am seeing much of the same now that I did in the posted captures, and I am going to watch closely tomorrow morning as it gets lighter outside.

[dexterash 0]

Synology Surveillance Station... what are the settings you used to it?

maybe it uses RTSP/general protocol

 

Detail dropping would result in less framerate, but main frames will be at high res... you have a low res there (or in "artefacts" at display image level)

 

Does the Synology use general RTSP or proprietary DAHUA protocol?

 

If it uses general, then you can expect errors, as in any other product delivering via RTSP.

[mroek 0]

Surveillance Station connects to the camera using Onvif (port 9988), and it does get the main stream, not the sub stream.

To reiterate: The live view was exactly the same, both in the camera web interface and in other software (LiveVue), so this has nothing to do with Surveillance Station.

[dexterash 0]

FYI, Onvif on 9988 port on DAHUA was used in a test version of the firmware.So you can't be sure on how it's connected and supported.

 

I reiterate it (): the image is the same, same colours(so no filter involed), but with a difference in resolution!

[GMaster1 0]

I think I figured it out. As mentioned, it has something to do with the gain. This camera model's gain defaults are too high for the compression it attempts. I had to put mine down to 20 in order for it to get rid of that cloudy appearance at night.

 

Here's an example showing how even 25 is too much.

 

(Not sure why the image registered as green for the duration of these example shots, but I was too lazy to do this over again in MSPaint. Also worthy to note these are not 100% samples. I zoomed in and screen shot them so you could see a better example of the detail since this cam is so far away from objects.)

 

http://i.imgur.com/P6ysszm.png

 

 

And the full screenshots:

 

Default (50):

http://i.imgur.com/WcGN0mk.jpg

 

20:

http://i.imgur.com/ScZwdyi.jpg

 

Hope this helps!

[mroek 0]

FYI, Onvif on 9988 port on DAHUA was used in a test version of the firmware.So you can't be sure on how it's connected and supported.

 

I reiterate it (): the image is the same, same colours(so no filter involed), but with a difference in resolution!

Regarding port 9988 being used in a test version, that's probably correct, but my cameras are not running a test version, they have the latest available release, which is: 2.100.0001.0.R, build : 2012-10-31. I am aware that Dahua has moved the Onvif-functionality to the web port (80) instead, but they haven't released a firmware for this model (yet) which has this change implemented. There are newer test versions for this camera, sure, but I don't have access to any of those.

 

There is a difference in effective resolution (due to the compression artifacts), but the number of pixels in the images are the same. Anyway, as GMaster1 has demonstrated, this is normal behaviour for these cameras in low light if the gain is allowed to go too high. I'm not sure I want to lower the gain, because then the images become quite dark.

[mroek 0]

I think I figured it out. As mentioned, it has something to do with the gain. This camera model's gain defaults are too high for the compression it attempts. I had to put mine down to 20 in order for it to get rid of that cloudy appearance at night.

 

[snip]

 

Hope this helps!

There really isn't that much difference in effective resolution in the 50 vs 20 gain images, but the latter is of course much darker. To show you what I mean, attached is a 100% crop from each of your images, but I have adjusted the darkest one (gain 20) in Photoshop so that it matches the overall color and luminosity of the high gain original. As you can see, there is a bit more resolution in that image, but it isn't a whole lot.

[mroek 0]

This morning the camera was back in this state (yesterday I changed the video settings to VBR and a target bit rate of 4096, just to see if that had anything to do with it).

 

What I noticed (from the live tab in the camera web interface), was that the reported bit rate was around 1700 kbps. Resolution was showed as 1280*960. What I did then was to change the bit rate to CBR (still 4096). The actual bit rate then jumped to the expected 4000-4100 kbps, but the image quality remained the same, i.e smeared details and slightly low color saturation. I tried changing bit rate (and mode) back and forth a few times, but while the actual bit rate changed, the image quality was still bad.

 

Then I tried briefly changing exposure mode to manual and then back to auto. To my surprise, that "fixed" it, and the image quality was back to normal.

 

What this shows is that the error (when present) has already been introduced before the video encoder, so the noise theory goes down the drain. This is indeed a strange issue, but I am quite convinced that it is a firmware bug, not something physical wrong with my camera. I have now seen it three times, the first time it fixed itself (which I believe it will probably always do, eventually).

[mroek 0]

Turns out that I actually caught the transition into this state on a recording. What happened was that the headlights of a neighbor's car shone into the camera, and a few seconds afterwards, the camera suddenly switches to the "low detail"-mode.

 

Not a shadow of a doubt in my mind that it is a firmware bug.

[mroek 0]

And now I have actually found a way to get the camera into this state. The same thing happens on my other cameras as well, so there is no doubt that it is a firmware bug.

 

To get the camera into this state, all it takes is to go to the "Conditions" tab, and change exposure mode to manual and 1/10000. What happens then is that the video feed first goes black (due to the short exposure time), but slowly the gain is boosted until the image has a normal brightness, but with a lot more noise, of course. A few seconds after the gain adjustment has finished, the camera suddenly enters the "low detail, low saturation mode". Setting the exposure mode back to normal fixes it.

 

I made a screencap-video of the process here:

 

 

At 09:30:26 (on the clock in the actual video) the transition to "crap"-mode happens, approximately 7 seconds after the automatic gain adjustment process has stabilized.

 

The video window is of course so small that the loss of detail is a bit difficult to see, but the drop in saturation is easy to see, so you'd just have to believe me that details are also lost. In real life, this could also happen if the camera is in low light (and gain is boosted), and a light source (car headlamp/flashlight) shines into the camera momentarily.

[Machineman 0]

I noticed several of my 1.3mp cams have similar quality and exposure re-adjusments for no reason. I supect these internal adjustments trigger motion events and is one of the reasons these cams have so many false alarms.

[ilkevinli 0]

I have seen this many times on my HFW2100 cameras. I notice it most in the mornings when the sun is rising.

[mroek 0]

I have seen this many times on my HFW2100 cameras. I notice it most in the mornings when the sun is rising.

Which firmware do you have on those cameras? If it is an older version, it means they (Dahua) haven't been able to (or tried) to fix it either, even though I am certain that it actually is a quite simple thing to fix.