• Hardware Platform (Jetson / GPU): GPU
• DeepStream Version 7.1
• TensorRT Version Automatic Through Docker
• NVIDIA GPU Driver Version (valid for GPU only) 550.67
• Issue Type( questions, new requirements, bugs) Question
In servicemaker python, how can I connect a probe? I want to perform functionality similar to “.connect” from non-service maker deepstream.
In particular I would like to add a probe on “pad-added” from “nvurisrcbin”.
I am aware that nvmultiurisrcbin exists, but unfortunately it cannot negotiate caps correctly with my source RTSP live stream so I am attempting to use the “pad-added” probe on “nvurisrcbin” to debug.
The Pipeline APIs version.
I can see the documentation for the attach function, but wasn’t sure how this can pick up gstreamer signals such as “on_pad_added”.
It is not able to be implemented in python API level. The signal handling should be implemented in c++ level based on Service Maker for C/C++ Developers — DeepStream documentation.
You can refer to the implementation of smart_recording_signal: /opt/nvidia/deepstream/deepstream/service-maker/sources/modules/smart_recording_signal
Then the python API can get the customized signal handling as a service maker factory. What is a Deepstream Service Maker Plugin — DeepStream documentation
Please refer to how smart_recording_signal is used in deepstream-test5 sample: /opt/nvidia/deepstream/deepstream/service-maker/sources/apps/python/pipeline_api/deepstream_test5_app
Thanks! I’ll give that a shot.
Out of interest my original error when using the “nvmultiurisrcbin” is this:
Debug info: gstdsnvurisrcbin.cpp(1529): watch_source_status (): /GstPipeline:RGB/GstDsNvMultiUriBin:source/GstBin:source_creator/GstDsNvUriSrcBin:dsnvurisrcbin0
Failed to query video capabilities: Invalid argument
This occurs when my live RTSP source flips from offline to online.
Am I correct that it will not be possible to use nvmultiurisrcbin for this purpose and I’ll need to manually create a probe for a set of nvurisrcbins? Before switching to servicemaker we used the “on_pad_added” probe to handle this.
What kind of offline/online?
There is already reconnection mechanism inside nvmulturisrcbin for the data stream stop scenario. If the “offline” and “online” are not caused by data stream stop, you may need to identify the root cause and use the corresponding method to handle the case. What did you do with "on_pad_added” probe?
As in I have a server with an RTSP stream and deepstream is expecting a stream from that server from a specific uri/port. The servicemaker pipeline successfully turns on and awaits input from the correct port. When I turn the server on I immediately get the following error:
0:00:31.242773838 1 0x7f7acc000eb0 INFO GST_EVENT gstevent.c:892:gst_event_new_caps: creating caps event video/x-h264, stream-format=(string)byte-stream, alignment=(string)au, level=(string)4, profile=(string)high, pixel-aspect-ratio=(fraction)1/1, width=(int)1920, height=(int)1080, framerate=(fraction)10/1, chroma-format=(string)4:2:0, bit-depth-luma=(uint)8, bit-depth-chroma=(uint)8, colorimetry=(string)bt709, parsed=(boolean)true
0:00:31.242798129 1 0x7f7acc000eb0 INFO GST_PADS gstpad.c:4357:gst_pad_peer_query:<‘’:decodepad1> pad has no peer
0:00:31.242803838 1 0x7f7acc000eb0 INFO basetransform gstbasetransform.c:1325:gst_base_transform_setcaps: reuse caps
gstelementfactory.c:489:gst_element_factory_create_with_properties: creating element “nvv4l2decoder”
0:00:31.243048844 1 0x7f7acc000eb0 INFO GST_ELEMENT_PADS gstelement.c:759:gst_element_add_pad:GstVideoDecoder@0x7f7a74037770 adding pad ‘sink’
0:00:31.243057161 1 0x7f7acc000eb0 INFO GST_ELEMENT_PADS gstelement.c:759:gst_element_add_pad:GstVideoDecoder@0x7f7a74037770 adding pad ‘src’
0:00:31.243102437 1 0x7f7acc000eb0 INFO GST_PADS gstpad.c:2382:gst_pad_link_prepare: trying to link capsfilter1:src and nvv4l2decoder1:sink
0:00:31.243106677 1 0x7f7acc000eb0 INFO GST_PADS gstpad.c:2590:gst_pad_link_full: linked capsfilter1:src and nvv4l2decoder1:sink, successful
0:00:31.243108575 1 0x7f7acc000eb0 INFO GST_EVENT gstevent.c:1660:gst_event_new_reconfigure: creating reconfigure event
Failed to query video capabilities: Invalid argument
0:00:31.243635631 1 0x7f7acc000eb0 INFO v4l2 v4l2_calls.c:637:gst_v4l2_open:nvv4l2decoder1:sink Opened device ‘’ (/dev/nvidia0) successfully
0:00:31.243648796 1 0x7f7acc000eb0 INFO v4l2 v4l2_calls.c:738:gst_v4l2_dup:nvv4l2decoder1:src Cloned device ‘’ (/dev/nvidia0) successfully
I would expect nvmultiurisrcbin to work natively, especially as the caps seem to be correctly found, but maybe I’m missing something.
Regarding the probe progress, I was trying to use on_pad_added to assign caps directly. I also got an error in that direction, but I would be open to using either the multisrcbin or the probe to get it working.
The error indicates that a null signal is not supported by the object (there are two spaces after signal in the error), but I’m not sure why its trying to handle a null signal. Here’s the full error:
0:00:03.910380559 1 0x55fa9daab8a0 INFO GST_PLUGIN_LOADING gstplugin.c:987:_priv_gst_plugin_load_file_for_registry: plugin “/usr/lib/x86_64-linux-gnu/gstreamer-1.0/deepstream/libon_pad_added_plugin.so” loaded
signal is not supported by the object
Plugin on_pad_added_plugin initialized
namespace deepstream {
static void on_pad_added(GstElement* element, GstPad* pad, gpointer user_data) {
gchar* pad_name = gst_pad_get_name(pad);
g_print("Success!");
g_free(pad_name);
// For now just print if we get here
}
static const SignalHandler::Callback callbacks[] = {
{"pad-added", (void*)on_pad_added}
};
class OnPadAddedHandler :
public SignalHandler::IActionProvider {
public:
virtual const SignalHandler::Callback* getCallbacks() {
return &callbacks[0];
}
};
DS_CUSTOM_PLUGIN_DEFINE(on_pad_added_plugin, "Plugin that listens to pad-added signal and logs pad names", "0.1", "Proprietary")
#define FACTORY_NAME "on_pad_added_plugin"
DS_CUSTOM_FACTORY_DEFINE_WITH_SIGNALS(
FACTORY_NAME,
"Plugin that listens to pad-added signal and logs pad names",
"Signal",
"Plugin that listens to pad-added signal and logs pad names",
"Testing",
"pad-added",
SignalHandler,
OnPadAddedHandler
)
}
Any help with either direction would be massively appreciated, thanks!
What will you do with “pad-added” callback to resolve such error?
Likely check if the ghost pad contains NVMM memory features then assign the caps manually if it does.
But neither approach seems to work at all for me. For the two separate approaches I tried above:
- Is this a known error with nvmultiurisrcbin that requires some additional set up?
- For the custom plugin what does “signal is not supported by the object” mean? Why are there two spaces after the signal implying a null signal is being used. Does the OnPadAddedHandler code look correct?
The caps should be set during negotiation stage. If the caps can’t be set correct automatically, the issue still exists even you set the caps manually.
Can you tell us how you offline and online your rtsp source? Shut down and turn on the RTSP server directly?
The entire thing runs in a docker container. The deepstream pipeline is expecting a feed from a specific port.
The RTSP video is supplied by a testmate application that will launch at the same time as the deepstream container. Once both containers have started I click play on the RTSP feed in deepstream. I never shut down the stream after it is active, and this method worked previously in 7.0 without servicemaker.
Just for additional context, its not just ghost pad linking, since nvmultiurisrcbin does not appear to be working for my purpose, I’m looking to link nvurisrcbin to a nvv4l2decoder.
To do this I need to dynamically link pads using a plugin. However I am still getting the error
Plugin on_pad_added_plugin initialized
signal is not supported by the object
Here’s my plugin:
#include <iostream>
#include "plugin.h"
#include "custom_factory.hpp"
#include "common_factory.hpp"
#include "signal_handler.hpp"
#include "gst-nvdssr.h"
using namespace std;
namespace deepstream {
static void on_pad_added(GstElement* element, GstPad* pad, gpointer user_data) {
gchar* pad_name = gst_pad_get_name(pad);
g_print("Success!");
g_free(pad_name);
// For now just print if we get here, will add actual logic once it builds correctly
}
static const SignalHandler::Callback callbacks[] = {
{"pad-added", (void*)on_pad_added},
{"", (void*) nullptr}
};
class OnPadAddedHandler :
public SignalHandler::IActionProvider {
public:
virtual const SignalHandler::Callback* getCallbacks() {
return &callbacks[0];
}
};
DS_CUSTOM_PLUGIN_DEFINE(on_pad_added_plugin, "Plugin that listens to pad-added signal and logs pad names", "0.1", "Proprietary")
#define FACTORY_NAME "on_pad_added_plugin"
DS_CUSTOM_FACTORY_DEFINE_WITH_SIGNALS(
FACTORY_NAME,
"Plugin that listens to pad-added signal and logs pad names",
"Signal",
"Plugin that listens to pad-added signal and logs pad names",
"Testing",
"pad-added",
SignalHandler,
OnPadAddedHandler
)
}
Does my wrapper plugin code look correct? Can you tell why I might be getting “signall null is not supported by the object null” ?