Deadlock when try to seek in pipeline

Sometimes when I try to call gst_element_seek_simple for pipeline that contains nvv* elements (nvvidconv and nvv4l2decoder) I got deadlock. During the call pipeline in PAUSED state, but I use GST_SEEK_FLAG_FLUSH for prevent problem that described here: Position tracking and seeking. Bellow you will find archive with minimal example, instructions, some notes and backtrace that I prepared for you

seek_bug_min_ex.zip (6.0 KB)

Hi,
Please help share your release version:

$ head -1 /etc/nv_tegra_release

For information, does it happen if you do seeking in PLAYING state? Or deadlock only occurs in PAUSED state?

tegra release:

# R32 (release), REVISION: 4.4, GCID: 23942405, BOARD: t186ref, EABI: aarch64, DATE: Fri Oct 16 19:37:08 UTC 2020

Also I tested the minimal example with pipeline in PLAYING state and it also deadlocked at seeking

Also looks like the problem never happens if we have only one working gst pipeline with nvv* elements on device

UDP, nope, I’m wrong. It also happens with one pipeline too (I started one instance of minimal example on my device and after ~2 hours I got deadlock)

could you reproduce that problem?

Hi,
It looks to be same as
gst-play freeze on seek

We are still checking it. Are you able to increase interval time between seek operation? It should be more stable than continuous seek.

Increasing interval don’t fix the problem completely. Our application must works long time and start many seeking operations (one per time), so it is critical to us when it freezes

Also, sometimes (very rarely) we have situation when pipeline doesn’t freezes on seeking, but freezes other pipeline (completely independent, with nvv* elements) that don’t uses seeking, just write some video. Assume the problem linked to seeking in first pipeline, but, unfortunately, problem happens very rarely, so I can’t create minimal example for reproduce it

1 Like

Hi,
I encountered the same situation in my application.
At this time, “GST_MESSAGE_QOS” is issued by v4l2decoder.
Also, omxh264dec does not cause this deadlock.