Playback and recording speeds differ

[rickoh6w-cloud]

The video recording is too fast.

[matteius]

You need to provide more evidence, camera models, how its configured etc ... I have no evidence of this happening.

[rickoh6w-cloud]

example of a recording.
Live speed is normal, but the recording is too fast.
Pay attention to the time speed displayed in the bottom-left corner of the recording.
https://github.com/user-attachments/assets/aa268dba-1040-41e9-8f99-1776ab7254df
https://github.com/user-attachments/assets/c1af9bd3-b545-42bb-b446-a6b08b112861
https://github.com/user-attachments/assets/d0fa4005-d640-4efb-ac39-3d5b1a6474ec

[rickoh6w-cloud]

I suspect this issue occurs when there is a time difference between the CCTV and the LightNVR server.

[matteius]

Thanks for the samples. I downloaded and inspected all three, and they confirm accelerated video timing in the MP4 files themselves.

• Each video track contains 253 frames and lasts 21.143 seconds, while the burned-in camera clock advances about 30 seconds from the first frame to the last. That is roughly 1.42× playback speed.
• The audio tracks last about 30 seconds. This explains why the overall file duration looks normal even though the video plays too quickly.
• All three have the same video timestamp spacing: mostly 83.333 ms between frames, with occasional 88.333 ms intervals.

A fixed difference between the camera and server clocks would shift the time reference; it would not by itself explain this sustained speed difference. An incorrect media timestamp rate could explain it.

Timestamp rescaling is one area we checked. The earlier rescaling bug in #581 was fixed in 757df426, included since 0.41.3. I also ran the first sample through the current continuous recorder with normal and non-reduced input time bases, including an added 24-hour media timestamp offset. All runs preserved every video presentation timestamp, with no additional acceleration. The existing timestamp and segment-boundary tests pass as well. This does not rule out a problem with the incoming stream's timestamps, its declared time base, or the version you are running.

Please provide:

1. Your LightNVR version and installation method.
2. The camera model/firmware and configured frame rate, including any variable frame rate or smart codec settings.
3. Whether this is continuous or motion/detection recording, and whether go2rtc is copying or transcoding the video. Please include the effective source configuration with credentials removed.
4. If possible, short stream-copy recordings taken directly from the camera and from go2rtc's RTSP output, with the camera clock visible, for comparison with a new LightNVR recording.

Comparing those captures will help locate where the video timing changes. If the camera and go2rtc captures preserve timing but LightNVR does not, recorder debug logs containing Video packet time base and any timestamp-repair messages would be the next useful evidence.