Inconsistency between reported dropped frames and timestamps?

Inconsistency between reported dropped frames and timestamps?


I have been doing zed2i recordings to svo files, and we need to precisely detect the number of dropped frames. To do so, we process the svo file and use the provided zed.get_frame_dropped_count() function.

To double check, we also request the frame timestamp (using zed.get_timestamp(sl.TIME_REFERENCE.IMAGE)), and we noticed that the timestamp we get when the SDK detects dropped frames seems not to be consistent with the dropped frames count.

I’m showing next a real example in which I include the current frame_number (as reported by zed.get_svo_position()), the current_time_stamp, the difference between the current and previously
reported time stamps (in ms, to check that they correspond to the 30 FPS I am using), and the reported dropped frames count.

Frame_number Current_time_stamp(ns) Current_time_stamp-Previous_time_stamp(ms) Dropped_frames_count
747 1680014737633503640 33.432 0
748 1680014737666791640 33.288 0
749 1680014737733789640 66.998 2

As you can see for frame 749, the system reports 2 dropped frames, but the timestamp suggests that there is only one dropped frame,
as the difference with respect to the previous timestamp is 66ms, instead of the expected 99ms (2 dropped frames plus the current frame which is obviously not dropped).
This behaviour happens all along the file in which we have 2 reported dropped frames in 5 ocasions.

I have other cases in which this does not happen:

Frame_number Current_time_stamp(ns) Current_time_stamp-Previous_time_stamp(ms) Dropped_frames_count
149 1680014247452259559 33.501 0
150 1680014247652757559 200.498 5

In this example, 200ms corresponds to a time difference of 6 frames (5 dropped frames plus the current non-dropped frame), which is fine to me.

Have any of you noticed such behaviour? Could you please think of any explanation for this? Am I correctly interpreting the provided dropped frames count and/or the expected difference in
consecutive reported timestamps?

Thank you very much in advance for your time,


PS: I’m using Zed SDK 3.8 for python in an ubuntu 22.04 box.

Hi @JaviMaciasG
welcome to the Stereolabs community.
We noted this behavior, we will try to replicate it and fix it if required.
Can you please share the SVO with us (you can send it privately to citing this thread)?

Sure @Myzhar , I just sent it to your support email address.

From the description of the issue and your knowledge of the behavior, do you already know if the problem is in the provided dropped frames count or in the timestamps? It would be helpful to know in advance so that we can go on with our development taking this into account.

Looking forward to your reply, thank you very much,


Hi @JaviMaciasG
I suspect it’s a “simple” approximation error in how we calculate the dropped frame number in the SDK.
It will be fixed soon.