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

Please provide complete information as applicable to your setup.

• Hardware Platform (Jetson / GPU)

• DeepStream Version

• TensorRT Version

• NVIDIA GPU Driver Version (valid for GPU only)

• Issue Type( questions, new requirements, bugs)

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_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!

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

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

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.

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