Is this a bug in function`reset_source_pipeline` in deepstream source codes?

[zhy2022]

Please provide complete information as applicable to your setup.

• Hardware Platform (Jetson / GPU)
GPU

• DeepStream Version
6.1.1

• TensorRT Version
8.4

• NVIDIA GPU Driver Version (valid for GPU only)
525.60.13

• Issue Type( questions, new requirements, bugs)
questions

I’m reading deepstream’s source code. In function reset_source_pipeline in file deepstream_source_bin.c, there is a piece of code as follows:

  if (src_bin->parser != NULL) {
    if (!gst_element_send_event (GST_ELEMENT(src_bin->parser),
        gst_nvevent_new_stream_reset(0)))
      GST_ERROR_OBJECT (src_bin->parser, "Interrupted, Reconnection event not sent");
  }

function gst_nvevent_new_stream_reset defines in gst-nvevent.h:

/**
 * Creates a "custom reset" event for the specified source.
 *
 * @param[in] source_id     Source ID of the stream for which reset is to be sent;
 *                          also the pad ID  of the sinkpad of the
 *                          Gst-nvstreammux plugin for which
 *                          the source is configured.
 * @return  A pointer to the event corresponding to request if sucxessful,
 *  or NULL otherwise.
 */
GstEvent * gst_nvevent_new_stream_reset (guint source_id);

My question is, is it a BUG to pass 0 as argument to gst_nvevent_new_stream_reset in reset_source_pipeline? Should it be the pad index of streammux which current rtsp source linked to?

Thanks for answering!

[yuweiw]

Thanks for your topic, we’ll check it later. So far, we have verified that it does not affect the reconnection of rtsp.

[zhy2022]

OK. I see no usage of nv RESET event in DS open sourced codes. It seems “pad add / delete / EOS” events matter more.

[yuweiw]

It is used in some of our non-open source code. But when we use it, we’ll get the real source-id first and set the right parameters.