How does v4l2_buffer->timestamp to system OS timestamp

We want to get v4l2_buffer timestamp with system os. We use this follow method to update our code.

But we found there are not match. How can we get v4l2 buffer timestamp with correct system os timestamp?
(eptime us)1597886732.814339 (system os time)1597886725.256784

We still use JetPack3.3.
Is there any way to get system os timestamp directly with v4l2 buffer?

You can try to modify the VI driver to make it.

…/drivers/media/platform/tegra/camera/vi/vi4_fops.c

can you point me out how to change?
Do you have available patch?

I also search this post before, Seems this doesn’t match with my requirement?

If your problem is don’t know how to get the timestamp.
You can reference to the v4l2-ctl tools source code is public.

Current the timestamp is Monotonic mode if you want to change it you have to modify the vi4_fops.c

nvidia@nvidia-desktop:~$ v4l2-ctl --stream-mmap --stream-count=3 -d /dev/video0 --verbose
VIDIOC_QUERYCAP: ok
VIDIOC_REQBUFS: ok
VIDIOC_QUERYBUF: ok
VIDIOC_QBUF: ok
VIDIOC_QUERYBUF: ok
VIDIOC_QBUF: ok
VIDIOC_QUERYBUF: ok
VIDIOC_QBUF: ok
VIDIOC_QUERYBUF: ok
VIDIOC_QBUF: ok
VIDIOC_STREAMON: ok
        Index    : 0
        Type     : Video Capture
        Flags    : mapped
        Field    : None
        Sequence : 0
        Length   : 10450944
        Bytesused: 10450944
        Timestamp: 73428.009795s (Monotonic, End-of-Frame)

        Index    : 1
        Type     : Video Capture
        Flags    : mapped
        Field    : None
        Sequence : 1
        Length   : 10450944
        Bytesused: 10450944
        Timestamp: 73428.043126s (Monotonic, End-of-Frame)

        Index    : 2
        Type     : Video Capture
        Flags    : mapped
        Field    : None
        Sequence : 2
        Length   : 10450944
        Bytesused: 10450944
        Timestamp: 73428.076458s (Monotonic, End-of-Frame)

VIDIOC_STREAMOFF: ok

ShaneCCC I know how to get v4l2 buffer timestamp at user space just like v4l2-ctl did.
Just like I mentioned before, after add the delta between Monotonic to REALTIME for v4l2 buffer timestamp, the result doensn’t match wit system time.

clock_gettime(CLOCK_MONOTONIC, &vsTime);
clock_gettime(CLOCK_REALTIME, &realTime);                                                                                                                                                                   

 long uptime_ms = vsTime.tv_sec* 1000 + (long)  round( vsTime.tv_nsec/ 1000000.0);

 long epoch_ms = realTime.tv_sec* 1000 + (long)  round( realTime.tv_nsec/ 1000000.0);
long epochtime_ms = epoch_ms - uptime_ms;

Then we add this delta for v4l2 buffer timestamp

      ep_ts= buf.timestamp.tv_usec + buf.timestamp.tv_sec*1000000;
      ep_ts = ep_ts + (epochtime_ms * 1000);

This ep_ts doesn’t match with gettimeofday, over than 12 seconds.
First question is why there are 12 seconds diff?
Second question is how can I modify vi4_fops.c to match with gettimeofday?

You may need to change the clock_gettime to others API can get the system time that match your request.

So far we didn’t find any available API to replace clock_gettime.
Do you have any suggesting?

How can I modify vi4_fops.c if we want to make v4l2 buffer to system time directly?

If there’s no any API, I would think you can have a check the delta of the current timestamp with system time for it.

I already use delta (like my previous example code) to match with system stamp, but the result seems doesn’t match…

“According to [4], the TSC is started during boot around 7 seconds before the kernel starts. Often, it is desired to measure the latency between the start of frame event on the VI to the moment when the frame is available on a userspace application.”

7 seconds before kernel starts?

it also mentiond a workaround has been added to Jetpack 4.2 in order to adjust the CHANSEL_PXL_SOF timestamp to be in sync with CLOCK_MONOTONIC.

Can you point me out this workaround, we wan to apply this workaround to our JetPack with patch.

I would suggest to update to latest BSP instead of apply the patch from J4.x base to J3.x base
Their kernel and code base are totally different may have problem to apply it to from k4.9 to k4.4