Frame timestamp is sometimes greater than the current timestamp

Answered

Mat L

April 26, 2021 13:03 Edited

Hi,

As I did not enable the "trust camera timestamp" option, I assume the frame timestamp visible from the plugin is a timestamp set by the server when it receives the frame.

Why then is it possible that sometimes the frame timestamp is greater than the current timestamp? Does the server use a different clock? Or are my assumptions wrong?

The following lines define the timestamps I'm talking about.

using namespace std::chrono;
auto current_timestamp_ms = duration_cast<milliseconds>(system_clock::now().time_since_epoch()).count();

int64_t frame_timestamp_ms = videoFrame->timestampUs()/1000;

0

• 

  Andrey Terentyev

  • Network Optix team

  April 26, 2021 16:12 Edited

  Hello Mat,

  Why then is it possible that sometimes the frame timestamp is greater than the current timestamp? Does the server use a different clock? Or are my assumptions wrong?

  That's possible because the Server time is system-wide synchronized. See "System Administration" -> "Time Synchronization". The timestamps of frames are of this synchronized time.
  This Server (i.e. system-wide synchronized) time can be different in a way you've faced from the OS current time returned by the system_clock::now().time_since_epoch()

  1
• 

  Mat L

  April 26, 2021 16:53

  Thanks Andrey.
  
  I will disable any synchronization by NX Witness and will let chrony handle the synchronization between servers.

  0
• 

  Mat L

  April 26, 2021 21:27 Edited

  Well, I disabled "synchronize time with the Internet" (and selected "do not sync time between servers") and I still see the same issue.
  
  Here is some simple test code that outputs negative values:

  bool DeviceAgent::pushUncompressedVideoFrame(const IUncompressedVideoFrame* videoFrame)
  {
      auto current_ts = duration_cast<microseconds>(system_clock::now().time_since_epoch()).count();
      int64_t frame_ts = videoFrame->timestampUs();
  
      spdlog::debug("offset: {}", current_ts-frame_ts);
  
      return true;
  }

  0
• 

  Andrey Terentyev

  • Network Optix team

  April 28, 2021 14:51

  Mat,

  Even in this case there is a default acceptable deviation of 200ms.

  Can you give a bigger picture, please? What is your scenario, objective?

  1
• 

  Mat L

  May 07, 2021 15:56 Edited

  Andrey,
  
  I wanted to achieve two things:
  1) estimate the end-to-end delay from frame capture by the cameras to the end of frame processing;
  2) reject frames that were too old in order to avoid keeping too many unprocessed frames in memory ("It's a good policy in general to drop all frames which are older than 300 ms." at https://support.networkoptix.com/hc/en-us/articles/360023748494-9-Important-Technical-Considerations-w-Nx-Meta).
  
  In the end, I chose to implement the second point with a proper queue (with a sensible size limit), which is a cleaner solution.
  For the first point, I decreased the value of  syncTimeEpsilon in the advanced settings ("Sync time epsilon. New value is not applied if time detla less than epsilon" - default: 200 ms, as you said).
  Should I expect unexpected trouble from tweaking this setting?

  0
• 

  Andrey Terentyev

  • Network Optix team

  June 02, 2021 15:16

  Hi Mat,

  Should I expect unexpected trouble from tweaking this setting?

  You should not, but you have to make sure this value is set the same on all Servers of a System.

  1
• 

  Mat L

  June 02, 2021 15:17

  Great.
  Thanks for you help, I consider this solved.

  0

Please sign in to leave a comment.