Having been at this for several weeks with lots of searching and many hours of troubleshooting, I finally found an answer to this specific Dahua issue that no single post seemed to tie together accurately.
​
System:
- Dahua NVR, with native "plug and play" topology
- 2 brand new Dahua 6MP TiOC Pro cameras
- Directly connected to NVR PoE port
- Continuous 24/7 recording
Critical for this issue: I know they are brand new, so failing quartz, worn out flash memory, clock burnout, or clock component failure would be a highly unlikely cause from the get go.
Symptoms observed:
- Cameras were drifting apart by fractions of a second over a long time
- One channel was consistently running about 0.5 seconds behind the other over a 12 hour period
- Playback on that lagging channel would freeze for a moment and then fast-forward very quickly "catching up"
- Subtle "rubber banding" under very heavy motion outdoors
- One channel was just microscopically behind the other even during normal operation
This looks like an obvious NTP/RTC issue to most observers but from the data I collected over days, I don't believe that's the case for most of the issue, if at all.
My theory: this is caused by a combination of 2 separate issues:
Dahua firmware sync thresholding
Encoder pipeline overload for certain 6MP TiOC Pro profiles operating at 25fps.
PART 1: Time sync investigation
The initial troubleshooting involved a myriad of combinations:
- Enable NTP on the NVR
- Enable NTP on the cameras directly
- Use "pool.ntp.org" as a source
- Use "google.com" NTP source
- Use "NVR camera sync"
- Experiment with the intervals in the NVR sync setting
- Cold reboots performed after each change
In the end, the channels still drifted significantly over time, albeit with varying rates. It was consistent, however, that one channel was always trailing the other by a constant percentage. The drift wasn't massive, but it was still a few fractions of a second each hour.
The key takeaway here is that the magnitude was incredibly small, so a catastrophically bad oscillator or a severely failingRTC chip seems very unlikely to be the primary cause. Instead, I suspect that Dahua's firmware uses a thresholding value when checking the RTC clock. If the drift is below a certain value, the firmware treats it as "within tolerance" and doesn't actively correct the timestamp because it would theoretically destabilize the stream and GOP sync. I believe the firmware implicitly treats even micro drifts below this internal threshold as acceptable quartz tolerance and allows them to accumulate between channels over many hours.
BOGUS TIME CACHE FLUSH
At one point, I decided I wanted to force a huge deviation in timestamps to see if the system could even detect it. I disabled NTP on everything, temporarily set the system clock to be completely wrong, disabled DST, set time zone to Beijing GMT+8, and performed a full system reboot. On reboot, the cameras and NVR re-negotiated the Plug and Play connection, and performed an RTC rewrite to both cameras. It was this action that provided my first major insight: when the NVR had to "redo" the RTC, it finally synced the cameras correctly, drastically reducing long term desync. My theory is that the NVR was retaining a cached synchronized value in volatile memory, and not correcting aggressively when the drift was under the defined threshold.
PART 2: Playback catch up issue
Now that the cameras seemed to be time-syncing properly, the "catch up" issue still persisted on one of the streams: a short freeze, followed by rapid fast forwarding and re-syncing. I no longer attributed this to RTC failure at this point.
THE ACTUALBOTTLENECK
My original configuration was the default 6mp, 25fps, CBR High bitrate for thecameras.
I believe that in some hardware implementations for the 6MP TiOC Pro line, the processor is unable to sustain 25fps video, especially on Outdoor scenes. The workload:
- Motion detection (complex)
- AI event processing
- Time sync corrections (if enabled)
- Simultaneous streaming to NVR
- Recording of the video
- Streaming from NVR to client (if needed)
This looks to me like a bottleneck in the encoder. Here's what I think is happening:
Complex outdoor scene triggers heavy motion
Encoder processing demand exceeds what the processor can consistently output at 25fps
Frames are dropped by the encoder
The NVR's buffer starts to run out of valid data
Playback on the viewer shows a stutter/freeze
The NVR's buffer catches up by playing the stream back faster to compensate for the missing frames and get the current timestamp in sync again
This creates the visible "rubber band" effect.
I also suspect that the encoder latency contributes to the time sync issue as well, not a failingRTC. The delay might not be constant, but will vary depending on the workload and result in a long term micro desync.
FINAL STABLE CONFIGURATION
TIME CONFIGURATION
- Disable NTP on the cameras
- Disable NTP on the NVR after the initial, full sync described above.
- Disable DST
- One camera acts as the single time authority by its connection to the NVR
- Periodic manual sync required
VIDEO CONFIGURATION
- 6MP
- 15FPS (This made the difference)
- VBR
- Maximum Bitrate: 8192Kbps
- Compression: Standard H.265
- GOP / I Frame Interval: 30
WHY 15fps CHANGED EVERYTHING
When I dropped the framerate from 25fps down to 15fps, the workload for the encoder was cut nearly in half. Suddenly, there was no stuttering, no freeze-ups, no rubber banding on playback. The streaming stability increased dramatically, as did the ability for the system to keep the time synced up over long periods. This made me certain that the bottleneck was in the encoder throughput for these specific cameras. I am now strongly convinced that 15fps is the stable operational framerate for continuous outdoor high complexity recording for these cameras.
STORAGE
I tested storage: two 6MP cameras, at 8192Kbps VBR running for days. I estimate this will yield about 16 days of retention on a 3TB drive, which is a very acceptable trade-off for stream stability and image quality.
FINAL CONCLUSION
If you're experiencing any of these symptoms with Dahua cameras:
- Tiny but persistent channel desynchronisation
- Freezing and "catching up" behavior on playback
- Rubber banding under motion
- One channel consistently delayed by a tiny margin
- General stream instability at high FPS
Then check BOTH Dahua's time sync thresholding and your camera's encoder load. For these specific Dahua 6MP TiOC Pro cameras, the main culprit seemed to be exceeding the encoder's sustainable processing capacity at 25FPS, exacerbated by the firmware's preference for tolerating very minor micro-drift. Bringing the FPS down to 15 stabilized the system and resolved all observed issues.
