Worlds First Review - Dahua - IPC-Color4K-X / DH-IPC-HFW5849T1-ASE-LED - Full Color 4K Camera

I've bought the "official" DH-IPC-HFW5849T1-ASE-LED from local Dahua distributor as well as a IPC-4K Turret from Andy. While the Turret images are really superb, I'm not able to adjust the Dahua to obtain something similar at night. It has the latest official firmware that is V2.840.0000000.18.R, Build Date: 2022-06-29.

Would be possible to try Andy's firmware in this camera ?
 
  • Like
Reactions: Yo Momma
I've bought the "official" DH-IPC-HFW5849T1-ASE-LED from local Dahua distributor as well as a IPC-4K Turret from Andy. While the Turret images are really superb, I'm not able to adjust the Dahua to obtain something similar at night. It has the latest official firmware that is V2.840.0000000.18.R, Build Date: 2022-06-29.

Would be possible to try Andy's firmware in this camera ?
Send your question to Andy! Andy have good service
 
I've bought the "official" DH-IPC-HFW5849T1-ASE-LED from local Dahua distributor as well as a IPC-4K Turret from Andy. While the Turret images are really superb, I'm not able to adjust the Dahua to obtain something similar at night. It has the latest official firmware that is V2.840.0000000.18.R, Build Date: 2022-06-29.

Would be possible to try Andy's firmware in this camera ?
yes, use our firmware here. Remember don't use Dahua official Firmware. Very poor. We work a lot on this version's firmware.
IPC-Color4K-X 20210908 FW | IP Cam Talk
 
So there never was a "@Wildcat" tweaked version out yet for this? Thought his review of this camera was in 2022 and he said he was going to make it better.

Wildcat has been feeding it back to Andy and Dahua. I think you'll find Andy's version is Wildcat's improved version as Dahua produces the version for Andy based on the feedback from them both.
 
Wildcat has been feeding it back to Andy and Dahua. I think you'll find Andy's version is Wildcat's improved version as Dahua produces the version for Andy based on the feedback from them both.
Wildcats review was in 2022. I didn't even have BI till Nov 2021. The FW is dated Sep of 2021?
 
its normal that after some time IVS starts to do some random alerting on Parking Detection ? When started to use a few month back all was perfect, now even after camera reboot it "detects" empty space without any real car parking and sends alert.... Firmware same by Empiretech, no any camera relocation.
 
Super frustrated here - I just picked up a 4K-X hoping to at least have reasonable close focus along with a usable speaker and microphone compared to the 4k-T where there is no speaker and using the microphone all you hear is a bunch of digital noise overpowering anything. The close focus is definitely better on the 4k-x, but that's where it ends for me. Audio playback and listening to audio is almost useless. For some reason though using the app to either "Talk with Channel" or "Talk with Device" both produce dramatically better audio.

The big issue that I'm running into is there appears to be a defect with VBR. Right after I switch to VBR from CBR, the image looks fine, but it slowly deteriorates after 30 seconds or so in what is clearly code distoration. There's no different between using H.264 or H.265 or the frame rate. Adjusting the max bit rate only helps slightly. Adjusting quality makes no difference. This issue does not occur with the 4k-T with the same settings using VBR. VBR works great in the 4k-T.

VBR 2048 3 FPS after 60s
VBR-Lawn.jpg



CBR 2048 3 FPS
CBR-Lawn.png
 
You realize the whole point of VBR is to drop the bitrate when there is no motion in a field of view, so that is correct. It could drop into the low 100's.... Some cameras may still run it higher, and others may not. When I was testing VBR on a camera I had a VBR go down into the 90s when the bitrate was set at 8192. Heck we have seen the same camera model looking at basically the same field of view behave quite differently with the same settings.

And 2048 is way too low for a 4K camera - needs to start a minimum of 10,000 and then go up and down until you don't see improvement or degradation.

Most of us run CBR to ensure we don't miss something because depending on the field of view, an object could be in and out of the field of view before the camera adjusts and ups the bitrate when using VBR...
 
Last edited:
Isn't the point of VBR to conserve bandwidth and storage, by recognizing when there's no motion? I did crank the bit rate up like you said and that did correct the issue - thanks. So, now I'm left wondering:
1. Why the 4k-T works fine with a still image and the same settings.
2. The actual bandwidth consumed with different settings. I'll have to find a tool to analyze that.
 
  • Like
Reactions: David L
Like I said, every camera algorithm is different. The 4K-T could have been looking at a different field of view maybe? Plus the 4K-T is a completely different chipset.

But even not, we have seen the same model camera set up identically set side by side with the exact same settings and produce different looking images. The sensors are so tiny that slight differences we don't perceive can drastically impact what the sensor sees. And then probably just differences in the chips as well.

VBR was much more important for conserving storage before systems would utilize substreams. Now that VMS systems utilize substreams, that is where the savings is. If you run VBR, you will have an event where the bitrate stays low too long and you miss the clean capture.
 
Yeah I can see the firmware on the 4k-X is clearly completely different than the 4K-T. Well, it has the same features, but a different GUI, so I'm guessing under the hood is vastly different including the encoding. I still think there's some sort of defect with the VBR algo in this for the image to look great for some time after resetting the image parameters, then the weird artifacts to show up only in the one area of the image after about 60s. I did test the 4k-T and the Hikvision 4k 1/1.2 turret from the same position.

The other thing I'm seeing are what look like dead pixels in the sensor. I saw an earlier discussion in this thread where someone else had this issue, but it didn't look like there was a final determination.

BadPixels.png
 
If you are running h265 that is the macroblocking effect which is why most of us use H264. Why it takes some time before the bit rate drops is simply a product of how long the firmware is programed to say there is no motion.

Yes there was a determination that those are not dead pixels, but rather it is a byproduct of the algorithm to try to maximize the image in low light situations. It is a balance of being able to eliminate them but then the overall image will be darker or simply provide more light and recognize it doesn't impact the intent of the camera which is to get a clean image of a perp.
 
If you are running h265 that is the macroblocking effect which is why most of us use H264. Why it takes some time before the bit rate drops is simply a product of how long the firmware is programed to say there is no motion.

Yes there was a determination that those are not dead pixels, but rather it is a byproduct of the algorithm to try to maximize the image in low light situations. It is a balance of being able to eliminate them but then the overall image will be darker or simply provide more light and recognize it doesn't impact the intent of the camera which is to get a clean image of a perp.
H.264H correct?