Decoder freeze

I’m developing using SDK 32.6.1 and found the following symptoms.
When changing the system time backwards, I noticed that the decoder sometimes freezes (reproducibility is not 100%).
After the issue is reproduced, changing the time back to the current time, the decoder works fine again.
At this point, the callstack looks like this

#0 0x0000007f712402a4 in futex_wait_cancelable (private=, expected=0, futex_word=0x428af08c) at …/sysdeps/unix/sysv/linux/futex-internal.h:88
#1 __pthread_cond_wait_common (abstime=0x0, mutex=0x428af030, cond=0x428af060) at pthread_cond_wait.c:502
#2 __pthread_cond_wait (cond=0x428af060, mutex=0x428af030) at pthread_cond_wait.c:655
#3 0x0000007f6e94dfdc in ?? () from /usr/lib/aarch64-linux-gnu/tegra/
#4 0x0000007f5006cbf0 in TegraV4L2_Poll_CPlane () from /usr/lib/aarch64-linux-gnu/tegra/
#5 0x0000007f500ab2e4 in plugin_ioctl () from /usr/lib/aarch64-linux-gnu/libv4l/plugins/nv/
#6 0x0000007f7da32db0 in v4l2_ioctl () from /usr/lib/aarch64-linux-gnu/tegra/
#7 0x0000000001f3ac04 in NvV4l2ElementPlane::dqBuffer (this=0x4187d718, v4l2_buf=…, buffer=buffer@entry=0x7f0524f348, shared_buffer=shared_buffer@entry=0x0, num_retries=num_retries@entry=0)
at Sample/samples/common/classes/NvV4l2ElementPlane.cpp:126

My guess is that it’s a related issue with pthread_cond_t used in pthread_cond_wait() , pthread_cond_timedwait() between threads when changing the system time to the past (using CLOCK_REALTIME instead of CLOCK_MONOTONIC, etc.), but it’s hard to confirm as the code is not publicly available.

In this regard, I would appreciate if you could share code from,, etc. or provide guidance.

We don’t expect system being modified arbitrarily while encoding/decoding is running. Please not to do it to avoid the condition. And the latest Jetpack 4 release is 4.6.4. Would suggest use the latest version.

Thank you for your answer.

Our product is a slave device to a specific device. So if the system time of the master device changes or the time zone changes, our product will also change its system time to synchronize. Of course, this is not a frequent behavior.

I have an additional question.
Am I to understand that you do not guarantee to change the system time during encoding/decoding?
If so, am I to understand that Jetpack 4 4.6.4 does not guarantee the same?