RunRaid, said I was going to post some other thoughts in efforts to help, well its a long post incoming
Some questions embedded as well
First up, certainly not seen any issues with live view stuttering across the number of 5842s I’ve tested in both turret and bullet cam. If issues have been seen with cams (of any range) over the years then generally (unless day-0 FW, more on this below) in my experience its related to infrastructure, recording platform, device for viewing, app OR in some cases (can affect cams in general) multi stream related (i.e sending 3 streams out to different platforms while also trying to view live) and even then only if bitrate is high on all streams and a number of operations are happening live.
Other Considerations
One thing to consider is that sometimes it’s not just how hard the cam is working itself BUT how or what is accessing it while its doing these tasks. In your case don’t forget you also have this being accessed by a NAS/HA unit which is accessing your cam multiple times per minute based on the logs and that access can also get in the way of an already highly loaded cam that may be processing other operations at the same time. The cam still has to process platform access and authentication when connected this way and can add to the strain. These new 4K’s pack a lot of processing in and skirt close to the edge in some use cases depending on what you have on scene, rules, SMD + IVS etc and then the platform (or multiple platform) access too. Combine all of this AND want to watch a 4K live stream at good bitrate and you might see intermittent glitches. What are you using to view the Live View, app, browser (if so which one) ? Are you viewing on a hard wired connected system OR over WiFi to phone, tablet etc ?
Continuing from above, its definitely worth (as you add more cams and especially those higher MP/bitrate cams) auditing your infrastructure. Forget VPN for a sec and let’s focus on the local connect you mention. What switch(es) are you using and are they managed or dumb ? If managed then there’s a lot more that can be looked at of course (good thing). Is your infrastructure flat or more segmented (either physically through other switches or through VLANs etc) ? Any QOS in place ? What does throughput look like to and from the endpoint, in this case from the device you are viewing from back to the switch, from device to cam, from recording platform (NVR, NVR platform, NAS etc) to cam ? Any packet loss seen from the switch for this cam ? If viewing across WiFi what is signal strength and how is the AP connected (mesh or hard wired backhaul etc with what number of hops to switch where cams are present) ? While it may seem like overkill when adding just another cam to the mix, it’s worth checking and keeping an eye on as you expand/replace.
Live View vs Recorded Image
Another thing to keep in mind is that while Live View is certainly useful, remember that the key in any security system is the recorded image. Unless you are manually controlling a cam in a live environment such as real-time security applications or using PTZs with joysticks etc for critical track work. Other than that, the main concern is that the recorded and processed image/clip (in the case of special applications like Face Recognition or ANPR etc) is intact (non glitched, non-skipped). You’ll primarily be relying on captured image review so ensuring that it is robust is always critical and number 1 priority. Therefore unless recorded image is impacted then I wouldn't be as concerned. From a sub stream perspective there really isn’t any reason to go above 704x480 as generally you’re using it just for reduced size, quick live view and thats it. So one test I would recommend is to drop to 704x480 (can even leave it at 30fps as that shouldn't cause any strain at this resolution) on H.264H (not H.265) and see if thats choppy (go low first then increase from there). Sticking with this subject for a mother minute. If you reduce your main bitrate (main stream) to 4096 for another test + then set your sub stream to 2 at 1080 and are still seeing choppiness, then something else is going on in your system for sure !
Anti Alias
You asked about Anti Alias above. The AA algorithm for any of these cams is in back end code (for good reason) and for the most part has been pretty solidly deployed across the portfolio in testing. The AA algorithm assists with issues such as step laddering, jaggies (caused by compression and noise) + effects such as moire patterns etc. Therefore due to the real-time nature required of the processing of live image is why its algorithm based and not presented to the user. AA usually leads to a
slightly softer image overall when it’s too aggressively applied but I don’t believe that issue is present on these cams tested. With regards to the image differences, the 5842 does feature slightly more chromatic aberration which you may be noticing more along edges (seen as slight fringe) and if seen, is generally more at a distance and in high contrasting areas. There are exceptions, usually seen on v1.0 or day-0 FW releases and in some cases need tweaks (as I fed back on the Color4K-X initially) due to different optics, SOC pairings needing changes over ‘standard’ cams utilizing the same chipset range. The VOLT based Color4K-X was a perfect example as it shared the chip with the 5442 BUT featured brand new optics and custom algorithms (that are not addressed to the 5442) which needed more tweaking than using the ‘generic’ code base for the VOLT range. This was exacerbated further due to the more shallow DOF offered by the paired optics on the Color4K-X. Glad to report this feedback was implemented and the resulting image is much better in release version than it was at test (but thats why we test
).
Onto the 5831s. They were never bad cams (some loved them, some hated them) but to be honest the 1831/2831s were better still IMO
and still hold up well today. Regardless of cam choice though, on the topic of older cams, a word of caution with regards to FW support. Older models do get dropped from support relatively quickly these days unless a) it’s is security related issue (CVE etc) and even then only to a point or b) where a shared chipset is still supported. Again just a caution especially if you look to purchase a large number of older units.
Lets revisit the Color4K-X for a sec. Andy mentioned the Color4K-X which is another amazing camera (check out my review on this one) BUT again you have to make sure it’s right for your install location. It needs light (small but decent amount to truly make it shine as I showed) but you also have to take into account the more shallow DOF that I mentioned above which if planned and installed for correctly, will not be an issue but for those with longer FOV’s (expecting near to far focal range sharpness) its something to be aware of as I’ve mentioned before.
Chip Changes
With regards to chip shortages, there could be a difference (un-documented) based on manufacture date and availability BUT generally it would have to be in spec of the overall design otherwise it would usually be classed as a 2nd series (S2) version etc and would represent a permanent change in the cams going forward from that manufacture date.
When Expanding The System
Lastly, as you look to expand/replace your setup I would strongly recommend that for the darker areas you either a) look to augment light (always the best option wherever possible and as mentioned above allows you to expand to 4K-X as an option) and b) consider the bullet variants because as I said, you gain 2 extra IR LED’s but critically the ability to dial in IR for near/far situations which certainly help a lot IF you have locations where IR throw is needed further out and/or you have foreground objects causing IR splash back.
In Summary
Either way, the choice is yours for final cam pick and the beauty right now is their is a lot of great, complimentary options across the Dahua portfolio as I’ve written about previously. With that said I certainly wouldn’t write off the 5842s as they are a great cam with a lot of power but as always have to be selected for the location and FOV accordingly. Not every cam will work in all situations as myself and others call out but install location is a critical part of cam selection. Either way, regardless of choice, I would/have and will always advise you do NOT use Auto/Default settings on any cam in any situation
. Also, by now I think/hope you know that regardless of what cam(s) / system(s) you end up on, if you need help then always feel free to reach out and I’m happy to help where I can.
HTH
