Removing deleted sources & source_ids from frame_meta information

Accelerated Computing Intelligent Video Analytics DeepStream SDK
1

• Jetson Xavier NX
• DeepStream 6.0
• Jetpack 4.6
• Issue Type: Question

Hi

I have a pipeline for handling rtsp feeds based on deepstream-test3 app, with the ability to delete and add new sources as per deepstream_test_rt_src_add_del.c. I use the src_pad_buffer_probe function to track detections and note the frame_meta’s source_id so I can perform further logic as per the corresponding rtsp stream’s id.

I notice though that after deleting a video stream and adding another, instead of the feed number remaining constant, it gets incremented as noted by the source_ids being picked up in the probe. I was of the mind that using the stop_release_source function would completely remove the source from the pipeline. How do I completely delete the rtsp source so that the probe is working with the current number of rtsp streams? Or is this not the proper way of handling streams? Maybe I’m required to refresh the buffer?

Thanks!

3

The source_id coms from the number of the nvstreammux’s pad. You need to control the number of the nvstreammux’s pad to keep the same source_id.

4

@yuweiw May you please explain, I’m not sure I understand
If I have three sources and delete one, do you mean I should refresh the nvstreammux to reflect this change? Is there a sample app that maybe shows how to execute this?

5

Like deepstream-test3, the soure_id is determined by the i value below:

    g_snprintf (pad_name, 15, "sink_%u", i);
    sinkpad = gst_element_get_request_pad (streammux, pad_name);
6

Do you mean if I want to remove a source wholly from the system, I am required to delete its sinkpad as well? I thought this is what these lines in the stop_release_source function were doing:

    case GST_STATE_CHANGE_SUCCESS:
        g_print("STATE CHANGE SUCCESS\n\n");
        g_snprintf(pad_name, PAD_NAME_SIZE - 1, "sink_%u", source_id);
        sinkpad = gst_element_get_static_pad(streammux, pad_name);
        ...
        gst_element_release_request_pad(streammux, sinkpad);
        g_print("STATE CHANGE SUCCESS %p\n\n", sinkpad);
        gst_object_unref(sinkpad);
        gst_bin_remove(GST_BIN(pipeline), g_source_bin_list[source_id]);
        source_id--;
        g_num_sources--;
        break;

This is what I currently have, and yet, after deleting sources and adding new ones, the frame_meta source_ids do not reflect this change. Meaning if I initially had 3 sources and deleted the 3rd, then added a new one, the source_id would reflect as the 4th. It would not take the place of the one just deleted.

7

@yuweiw @Fiona.Chen, do you mean something else?

8

To simplify the analysis, we will first reproduce your question using the following code runtime_source_add_delete.
What value do you want source_id to correspond to? Could you provide a detailed description of your needs?

9

@yuweiw I want the frame_meta’s source_id to identify the order of the streams in the pipeline. For example: source_id 0 for the 1st stream, source_id 1 for the 2nd etc.
This is what I am trying to do: I want to be able to delete a stream and have it completely removed from the system. What I would like to know is if there is a way to make the order of source_id reflect this. For example, say I delete the 2nd stream with source_id 1. If now I add a 3rd stream, why shouldn’t it assume source_id 1 of the frame object? Since there are only two streams currently in the pipeline. Or is this not the ideal approach for this situation? Is there another attribute instead of source_id that identifies the order of the stream in the pipeline?

10

And does the deleted source still take up some kind of logical memory? Does it still exist at any level in the pipeline?

11

As I attached before, this is the source id. This is defined and controlled by yourself. In our demo code, the source is deleted randomly. You need to delete by yourself.
And you shoudn’t add the probe after the nvtiler plugin. It will broke the batch.

12
  • When you delete a source like that, is it totally removed from the pipeline?
  • I added the probe on the source of the pgie. I learnt this after reading other forum posts concerning its correct positioning. Is this incorrect?
13

Yes. You have removed the source bin with gst_bin_remove (GST_BIN (pipeline), g_source_bin_list[source_id]);.

Yes, add the probe after the pgie is right.

14

Thanks @yuweiw,
We kept seeing dark blocks in the tiler after sources were deleted, so we weren’t sure if the deleted sources still somehow took up memory or not.

15

Ok, the plugin has been removed. But there still dark blocks in the window. It’s controlled by the tiler plugin.

16

Can I remove these dark blocks without bringing down the pipeline, maybe by refreshing the tiler somehow? Thanks

17

Temporarily we don’t support dynamic remove the black window in the tiler plugin.

18

Thanks for all your help
I’ll be closing the issue now

19

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