Info regarding the `new-streammux`'s ability to dynamically add/delete sources

Please provide complete information as applicable to your setup.

• Hardware Platform (GPU) T4
• DeepStream Version 6.3
• TensorRT Version: 8.6
• NVIDIA GPU Driver Version (valid for GPU only): 525.85.12
• Issue Type( questions, new requirements, bugs): questions

I just learnt about the new nvstreammux link and its ability to dynamically add/remove sources

The muxer supports addition and deletion of sources at run time. When the muxer receives a buffer from a new source, it sends a GST_NVEVENT_PAD_ADDED event. When a muxer sink pad is removed, the muxer sends a GST_NVEVENT_PAD_DELETED event. Both events contain the source ID of the source being added or removed (see sources/includes/gst-nvevent.h ). Downstream elements can reconfigure when they receive these events. Additionally, the muxer also sends a GST_NVEVENT_STREAM_EOS to indicate EOS from the source.

But there is no explanation on it. Can someone give me an example on how it works?

I have currently implemented this by removing and adding the pad from the uridecodebin for the newly added/removed source. I check the source removal by polling its FPS. I am curious how the new-streammux can help me :)

The sentences from the document just describes how to add new stream when create the pipeline in the beginning.

You can remove and add sources with new streammux just as the nvstreammux. The only thing is to make sure there is always one stream living in the pipeline and DeepStream SDK FAQ - Intelligent Video Analytics / DeepStream SDK - NVIDIA Developer Forums

You can add a Probe to the source-pad (output) of the nvstreammux plugin – or any other plugin pad downstream of the streammux – with a GstPadProbeType of GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM.

Your registered callback will be called with each event that flows over the source pad.

I have a C++ version of the callback that looks for streammux events as follows:

    GstPadProbeReturn StreamEventPadProbeEventHandler::HandlePadData(
        GstPadProbeInfo* pInfo)
    {
        LOCK_MUTEX_FOR_CURRENT_SCOPE(&m_padHandlerMutex);

        if (!m_isEnabled)
        {
            return GST_PAD_PROBE_OK;
        }
        
        uint streamEvent(0);
        uint streamId(0);
        GstEvent *event = (GstEvent*)pInfo->data;

        if ((uint)GST_EVENT_TYPE(event) == (uint)GST_NVEVENT_PAD_ADDED)
        {
            gst_nvevent_parse_pad_added(event, &streamId);
            LOG_INFO("GST_NVEVENT_PAD_ADDED received for stream-id="
                << streamId);
            streamEvent = DSL_PPH_EVENT_STREAM_ADDED;
        }
        else if ((uint)GST_EVENT_TYPE(event) == (uint)GST_NVEVENT_PAD_DELETED)
        {
            gst_nvevent_parse_pad_deleted(event, &streamId);
            LOG_INFO("GST_NVEVENT_PAD_DELETED received for stream-id="
                << streamId);
            streamEvent = DSL_PPH_EVENT_STREAM_DELETED;
        }
        else if ((uint)GST_EVENT_TYPE(event) == (uint)GST_NVEVENT_STREAM_EOS)
        {
            gst_nvevent_parse_stream_eos(event, &streamId);
            LOG_INFO("DSL_PPH_EVENT_STREAM_ENDED received for stream-id="
                << streamId);
            streamEvent = DSL_PPH_EVENT_STREAM_ENDED;
        }
        // It's not a stream event so bail out.
        else
        {
            return GST_PAD_PROBE_OK;
        }
        
        // It is a stream event so call the client handler.
        try
        {
            return (GstPadProbeReturn)m_clientHandler(streamEvent, 
                streamId, m_clientData);
        }
        catch(...)
        {
            LOG_ERROR("Stream Event Pad ProbeHandler '" << GetName() 
                << "' threw an exception calling client listener");
            return GST_PAD_PROBE_REMOVE;
        }
    }

Note that the GST_EVENT_TYPE and NVIDIA’s GstNvEventType define different enum types so you will need to cast on comparison.

Fortunately, this functionality is available with the old streammux plugin… as it’s unclear if the new streammux is usable… see Pipelines with new nvstreammux and nvstreamdemux fail to play correctly in DS 6.3

Regards,
Robert.

1 Like

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