The theory is-- and its just a theory, that higher i frame intervals will reduce processing load, and lower intervals tend to clear up any processing errors. So its just another troubleshooting approach.

Others may chime in but I have had streams clear up when adjusting the iframe interval lower.

It certainly seems that way.... I would send a bug report....

Good luck!

I'm not sure if your circumstances are the same - nevertheless there are similarities where I also faced IP streams stutter. In my set-up I’m using mainly Axis equipment (Q3505, 2xQ6115 PTZ and P8221 Network I/O Audio [the main audio source from the global PA system; no other audio sources]) plus some NDI captures.
Long story short - I did a fair degree of network troubleshooting to find:

1. My Windows 10 main system has 2x Intel NIC with teaming enabled for the aggregation and redundancy. After some time I noticed that the TEAM NIC probe when retries link test gradually increased connection drop time to the extent when I could observe about a second gap across all sources. Removing TEAM from NIC and configuring LAG on the switch removed the issue.

2. All Axis streams are using RTMP/RTSP protocols. In time the individual devices started “drifting” where the internal HWC clocks are not the greatest. I start noticing that the stream buffering is trying to compensate time frame differences between devices resulting in 3-5 seconds “stream freeze”. Using ffmpeg directly with the individual sources (or VLC) I could not find a problem. After weeks of factory resets, ONVIF profiles “mix-ups”, three support tickets with Axis and disassembling Axis’ RTSP implementation I realised that my problem lies in the reliable time source for all systems taking part in the production.
Since building stratum1 NTP (GPS time source) based on the raspberry PI and using it as the main NTP server – all problems gone; including lip sync across all video+audio “stitched” production.

Cheers.

Just to point out that the Windows 10 (pro) not joined to any DC will use OOTB ntp client time sync intervals: once a week (604800 seconds).
Depending on the quality of your HWC on the motherboard you may want to change the hive's defaults. You should see the "SpecialPollInterval" key (Decimal) located at HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\W32Time\TimeProviders\NtpClient.

For me 1 day (86400 seconds) made the time keeping brick solid.

On top of the above I set:

1. DHCP for this particular machine (and all other related IP based video and audio devices) to "static reservation" + "no-expiry".
2. Separate VLAN on L2 broadcast domain (network domain, not live publishing) plus L3 routed network dedicated to broadcast role (using multicast priority).

Good luck with your troubleshooting.

Some DVRs will display a frozen image when they lose the signal. Some will freeze when the feed is noisy. If the cameras display fine on a monitor, then the cameras are not the problem.

It's possible that the DVR is simply failing, or that just those inputs are failing. Try swapping inputs of one of the "problem" cameras with one of the stable ones... see if the freezing moves with the camera, or stays with its original channel. That will help narrow down whether the problem is with the DVR itself.

Hope this will help you if still the problem remains, then consult with the CCTV installation companies nearby you or contact with technical support team.