Hi folks,
I’m recording with 4 ZED Xs on an AGX orin, ZED SDK 5.1, latest ZED X driver, etc.
I’ve been getting weird timestamp issues playing back from SVO files. The timestamps of my cameras seem to be using std::steady_clock for the first 10-20s of recording instead of std::system_clock.
According to camera_->getTimestamp(sl::TIME_REFERENCE::IMAGE) frame 2388 of my SVO is stamped 257162167000ns, which is the std::steady_clock value at that time (i.e 257.162167 seconds since boot up, which is correct for the steady clock). Frame 2389 of my SVO is stamped 172321342134234 which is the std::system_clock at that time (i.e. Sunday, November 2, 2025 1:13:52.377 PM [GMT-05:00] which is the correct system time).
The switch over happens across all 4 of my cameras at the same time, I’m recording 4 SVOs in parallel, and at the exact same time they all switch from std::steady_clock to std::system_clock.
I was looking to see if I could choose which to use (I’d rather use std::steady_clock for this anyway) and I saw this in Camera.hpp which made me think there’s something using the wrong clock somewhere:
/**
\ingroup Core_group
\brief Returns the current timestamp at the time the function is called. Can be compared to sl::Camera::getCameraTimestamp for
synchronization.
Use this function to compare the current timestamp and the camera timestamp, since they have the same reference (Computer start time).
\return The current timestamp in ns.
*/
static inline Timestamp getCurrentTimeStamp() {
Timestamp current_ts = 0ULL;
current_ts = std::chrono::duration_cast<std::chrono::nanoseconds>(std::chrono::system_clock::now().time_since_epoch()).count();
return current_ts;
}
This comment is wrong, std::system_clock is the time since the UTC epoch NOT the time since the computer started, std::steady_clock is the time since the computer started. Might not be the issue, the comment could just be wrong, but it’s suspicious given what I’m seeing.