Issues about Sensor image Timestamp

I have two camera sensor, the first device is mono sensor and other is color sensor.
We use the same extern gpio trigger source for those sensor.
For the mono sensor,we use the v4l2 app to get image data and sensor timestamp.
For the color sensor,We use the tegra_multimedia_api to get image data and timestamp.
We see one strange thins, there are ~28 second difference between two time stamps:

S3d_CameraImageColor timestamp:352093 ms
S3d_CameraImageMono  timestamp:324461 ms

For V4L2 and tegra_multimedia_api way, the timestamp use the same time reference?
Would you please help me resolve the issues?
We use the Jetpack3.3 L4T R28.2.1

Also, tegra_multimedia_api support get bayer format raw data from sensor?

hello 27653276,

you may refer to Camera Architecture Stack, your two applications going through different software blocks.

you may have some implementation in the VI drives to overwrite the timestamp,
please also refer to similar topics for timestamp synchronization issues, Topic 1047944, Topic 1046381, and Topic 1038131.

Hi JerryChange,

I follow your suggestion on Topic 1038131 #14 :

please have modification in below VI driver function, and update the timestamp with linux kernel function.
static bool vi_notify_wait(...)
    *ts = ns_to_timespec((s64)status.sof_ts);


*ts = ns_to_timespec((s64)status.sof_ts);
*ts = current_kernel_time();
By debug message output, the timestamp still is not correctly.
with my understand, V4L2 timestamp come from RTCPU, Is it correctly?
May I know how does argus api get the timestamp? it is using the linux kernel time function?


change ns_to_timespec((s64)status.sof_ts); to ktime_get_ts(ts),
Now the diff is about 1 ms.
I 'm confused that why the argus api don’t use the same timestamp as v4l2 buffer timestamp(sof_ts) from RTCPU.


May I know how are you extracting the timestamp in your tegra_multimedia_api app? In my setup, I get RTCPU timestamps close to those obtained with v4l2 by enabling metadata and extracting the timestamp in an argus app.

Maybe the time difference between v4l2 and the timestamps you report may come from the difference between RTCPU time and system time, I’ve seen this on Jetpack 3.x, similar to the issue reported in this post:

hi all,

there’s a known issue that RTCPU and system clocks did not synchronize.
we’ll have change to expose time delta in sysfs for the next public release (i.e. l4t-r32.2)

Hi jcaballero,

My tegra_multimedia_api app is also using the metadata to get time stamp.
May I know what’s the Jetpack and L4t version that you are using?
Also, I notice that There are another way to get timestamp.

IFrame *iFrame = interface_cast<IFrame>(frame);

I 'm not sure whether that’s the same way as metadata?


In Jetpack 3.x, I do see the issue Jerry mentioned (around 5s sometimes more, difference between RTCPU and system clock timestamps), but there doesn’t seem to be a synchronization difference this big on Jetpack 4.2.

Since the source of v4l2 timestamps is RTCPU, if multimedia_api uses system clock to timestamp, this may be one source of the big difference you see between the timestamps. Is the difference always 28s? Does it change after rebooting and testing again? I’ve seen that the time difference between the clocks changes between boots.

I get under 1s difference between the timestamps of a v4l2 app and a multimedia_api app capturing with two cameras approx. the same time instant (for instance, the instant when a led is turned off), with Jetpack 4.2 (L4T 32.1), however, I’m not using any external gpio triggers.