Stream ID not found when removing stream for ReID features

Please provide complete information as applicable to your setup.

• Hardware Platform (Jetson / GPU)
• DeepStream Version
• NVIDIA GPU Driver Version (valid for GPU only)
• Issue Type( questions, new requirements, bugs)
• 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:

    gst_element_set_state (srcbin, GST_STATE_NULL);
    g_snprintf (pad_name, 15, "sink_%u", bin->sourceId);
    sinkpad = gst_element_get_static_pad (m_streammux, pad_name);

    GstPad *sinkpad = gst_element_get_static_pad (m_streammux, pad_name);
    if(sinkpad) {
        gst_pad_send_event (sinkpad, gst_event_new_eos ());
        gst_pad_send_event (sinkpad, gst_event_new_flush_stop (FALSE));
        gst_element_release_request_pad (m_streammux, sinkpad);
        gst_object_unref (sinkpad);

    gst_bin_remove (GST_BIN (m_pipeline), bin->srcbin);

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?

Can you reproduce the issue with: deepstream_reference_apps/runtime_source_add_delete at master · NVIDIA-AI-IOT/deepstream_reference_apps · GitHub ?

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? (9.6 KB)
It can be compiled and launched in

What is the mean of “too early”, do you mean the interval of addSource() and removeSource() is short? e.g. 100ms.

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.

Can you help to conform: after one object of the video source passed through nvtracker, you can release the video source pad safely?

Can you use NvDCF tracker in your project?

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.

GstPadProbeReturn gie_tracker_processing_done_buf_prob (GstPad * pad, GstPadProbeInfo * info, gpointer u_data)
    GstBuffer *buf = (GstBuffer *) info->data;
    NvDsBatchMeta *batch_meta = gst_buffer_get_nvds_batch_meta (buf);
    if (!batch_meta) {
        return GST_PAD_PROBE_OK;

    for (NvDsMetaList * l_frame = batch_meta->frame_meta_list; l_frame != NULL;l_frame = l_frame->next) {
        NvDsFrameMeta *frame_meta = (NvDsFrameMeta *)l_frame->data;
        int objectCount = 0;
        for (NvDsMetaList * l_obj = frame_meta->obj_meta_list; l_obj != NULL;l_obj = l_obj->next) {
        if(objectCount > 0) {
            g_print("track object from source %d\n", frame_meta->source_id);
    return GST_PAD_PROBE_OK;

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?

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.