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
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.
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):
seek_bug_min_ex_mod.zip (9.9 KB)
Hi,
We are still checking this. On Jetpack 4.6, this is still an issue. Please wait for next release.
Please try Jetpack 4.6.1
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.