Inconsistent timestamps #94

nh236 · 2024-11-05T09:59:53Z

Hi,

first of all, thanks for providing and continuously updating this code base!

I have an Orbbec Femto Bolt, firmware version 1.1.2 and the timestamps seem to be handled differently than in the Azure Kinect. I don't know if this on purpose, but the "old" way seemed more plausible to me. Some of my code (for the Azure Kinect) depends on this, which is why I'd like to ask you to clarify if the current status is the way it is intented to be, or if there is a chance this will be fixed to be like it was the Azure Kinect.

the "start_timestamp_offset" for the Femto Bolt is very big (in the order of minutes) and seems to change with each recording. With the Azure Kinect, this used to be some milliseconds, and consistent across recordings. (If I remember correctly, the value changed once after some firmware update, but stayed consistent ever since).
When I load the Femto Bolt recording with the old (Microsoft) Azure Kinect Viewer, the start_offset_timestamp is different compared to when I load the same recording with the OrbbecSDK-K4A-Wrapper k4aviewer (and even negative). The timestamp of an Azure Kinect recording displays correctly in both viewers.
The timestamp of the first frame in a recording used to be similar to the start_timestamp_offset in Azure Kinect. Now, the current frame timestamp seems very extreme (value of 1730796756988167 in the screenshot below) and I don't see any relation to the start_timestamp_offset. This is similar for recordings and live streaming.

To Reproduce