Please provide complete information as applicable to your setup.
• Hardware Platform (Jetson / GPU)
GPU • DeepStream Version
6.2 • NVIDIA GPU Driver Version (valid for GPU only)
525.105.17 • Issue Type( questions, new requirements, bugs)
questions • How to reproduce the issue ? (This is for bugs. Including which sample app is using, the configuration files content, the command line used and other details for reproducing)
I have pipeline with a nvinfer followed by a nvtracker, when dynamiclly stop and delete a source, sometimes there would be errors like this:
!![Exception] Stream ID not found when removing stream for ReID features
An exception occurred. Stream ID not found when removing stream for ReID features
gstnvtracker: Fail to remove stream 43.
When it occured, the pipeline would be corrupted. I want to know how this happens.
Here’s some code about how I deletea source:
And as long as I don’t call gst_element_release_request_pad () when delete the source, then evertything will be fine. It seems that if I call gst_element_release_request_pad () too early, the source will be occupied by tracker and cause problems above. The question is, when should I call this function( I don’t know when the tracker will be done with the source and I don’t find any signals or callbacks) and how to release source gracefully?
Unfortunately, it can only be reproduced by a large number of rtsp streams(like 50). Could you find 50 rtsp streams and try to reproduce it with my code?
If I don’t call gst_element_release_request_pad () or wait for some time before calling gst_element_release_request_pad () , the issue will not happen. According to the log: “Stream ID not found when removing stream for ReID features”, I guess when I tried to remove sink pad from streammuxer, it was still occupied by tracker, so when tracker tried to remove stream, the stream had been removed by gst_element_release_request_pad. The question is I don’t know when is the proper time to release source.
I don’t sure what you mean, it only occurs when a lot of sources are stopped at the same time, and some of the sources can’t be removed randomly. And each source produces object and has been passed through nvtracker before removed.
I added some print in the source code posted before.
Here are two log files, log2.txt is the result without calling gst_element_release_request_pad. log.txt (17.4 KB) log2.txt (19.7 KB)
I tried config_tracker_NvDCF_accuracy.yml, but it triggered " NvBufSurfTransform failed with error -3" easily, so I don’t know if it’s Ok to use NvDCF tracker.
There is no update from you for a period, assuming this is not an issue anymore. Hence we are closing this topic. If need further support, please open a new one. Thanks
Can you wait until one gstbuffer output from nvstreammux?