time system about videoimucapture-android HOT 5 CLOSED

Hi,
The time is in ns, that is correct.
It is not absolute time, only relative. For absolute time see the time variable in the VideoCaptureData message from the protobuf output. It will be according to the smartphone local timezone.

I hope that answers you question.

Best regards,
David

from videoimucapture-android.

thanks for the answer!
After I search for some infomation about proto and "google.protobuf.Timestamp", There are stills some point I am not sure.

Is the time of the APP output. pd3 file relative time? i thank the file recording.propot only use to read the .pd3 file and not change absolute time to relative. So i wanna know how APP get the absolute time and the algorithm that change absolute to relative, I can't find this in the source code file.

thanks for your patience.

from videoimucapture-android.

Could you explain your use case? Not sure I understand your question.
The current code use 2 time sources:

• At the start of the recording, the current world time is captured using currentTimeMillis which is converted to a date-time format and stored as time in VideoCaptureData.
• For each camera frame we store a timestamp as time_ns in VideoFrameMetaData which is nano-seconds since boot. As long as your Android device supports it, see SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME. The value of this is also stored in the protobuf file here.

So in case you need the exact world time for each image you have to calculate the offset between the world time given by currentTimeMillis and the time since reboot given by elapsedRealTimeNanos, which is not done in the current code.
See here for more on time functions.

You may however approximate the offset by using the world time of the start of the recording VideoCaptureData.time and the timestamp of the first video frame VideoCaptureData.video_meta[0].time_ns. The error will then be the time between the start of the recording thread and the start of camera capture, which will depend on the device. I'm guessing anything from a few ms to 1 second, but this is just a wild guess, I haven't tested the delay.

It may be worth checking the first timestamp of the IMU instead, since this should be quicker to start and has a higher sampling frequency. Then you want to check VideoCaptureData.imu[0].time_ns instead.

from videoimucapture-android.

I plan to intergrate with gnss so I may need a absolute time.
I think my problem is solved, thanks a lot for your answer!
Thanks!

from videoimucapture-android.

Good luck with your project!

from videoimucapture-android.