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 (6.0 KB)

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?

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

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.

Hi again! For us it is very important to use nvv4l2decoder in our pipeline after seeking, so I found a tricky solution for the problem: I use filesrc location=video.mkv ! matroskademux name=demuxer demuxer.video_0 ! identity name=tmp ! fakesink name=fakesink for seek to closest key frame (before target time point) and at GST_SEGMENT_EVENT I change the pipeline dynamically (via blocking pad callback) to filesrc location=video.mkv ! matroskademux name=demuxer demuxer.video_0 ! identity name=tmp ! nvv4l2decoder ! nvvidconv ! video/x-raw ! appsink name=sink emit-signals=true sync=false. BUT there is another problem:

NvMMLiteOpen : Block : BlockType = 280 
NVMEDIA: Reading vendor.tegra.display-size : status: 6 
NvMMLiteBlockCreate : Block : BlockType = 280 
VP9: Warning! Resolution change is happening on Non-Key frame, Use SetMaxRes attribute...
VP9 : KeyFrameResolution = (0, 0), Non-Key Frame Resolution = (1920, 1080) 
Error in ParseUncompressedVP9

And it also produces deadlock. It happens much-much rarely then previous problem, but it is still a problem. I can’t understand why it happens, because, if I understand rightly, key frame must be pushed to pipeline directly after GST_EVENT_SEGMENT. And why vp9 key frame (in case of error) is (0, 0)? It happens even if I explicitly set caps for nvv4l2decoder during dynamic pipeline change.

Bellow you can find modified minimal example (with dynamic pipeline change): (9.9 KB)

We are still checking this. On Jetpack 4.6, this is still an issue. Please wait for next release.