Please provide complete information as applicable to your setup.
• Hardware Platform (Jetson / GPU)
Jetson Xaiver NX • DeepStream Version
DeepStream 6.2 • JetPack Version (valid for Jetson only)
JetPack5.1 • TensorRT Version
TensorRT 8.5.2.2 • NVIDIA GPU Driver Version (valid for GPU only) • Issue Type( questions, new requirements, bugs)
questions :
I try to add the setting of frame-interval in sink and rtsp-reconnect-attempts in souce, but got the warning info when running the code:
for the setting of rtsp-reconnect-attempts in source, I want to ensure the main procedure can be worked normally if any sources were not correct connected and kept reconnecting.
And I check the source code of deepstream_source_bin.c at /opt/nvidia/deepstream/deepstream-6.2/sources/apps/apps-common/src, it seems do not contains this parameter, but just rtsp-reconnect-interval?
Could you attach the whole config file you are using?
Also you can try to upgrade your DeepStream to our latest version: 7.1. We have added that on that version.
OK. Since this part is open source, you can find the source code and add that yourself.
parse_source_yaml in the deepstream\sources\apps\apps-common\src\deepstream-yaml\deepstream_source_yaml.cpp
parse_sink_yaml in the deepstream\sources\apps\apps-common\src\deepstream-yaml\deepstream_sink_yaml.cpp
I’m not ensure the setting of msg_conv_frame_interval in the deepstream_app_config.yml would be used and activated in the code…pls help to recheck.
For the setting of rtsp-reconnect-attempts, I can find it have been parsed in the code of deepstream_source_yaml.cpp, but it do not used in the code of deepstream_source_bin.c in dp6.2.
for the setting of msg-conv-frame-interval, I mean it seems the main code of deepstream_parallel_infer_app.cpp do not used the correcting value to control the frequency of msg. pls refer to the following snapshoot:
for the setting of rtsp-reconnect-attempts, I found it should be activated with the key of rtsp-reconnect-interval. And I just replace the relevant code in deepstream_source_bin.c as below:
About the frame_interval in the source code, this controls the interval at the app level. About how to control that in the plugin, you can also refer to our source code deepstream\sources\gst-plugins\gst-nvmsgconv.
2.About the rtsp-reconnect-attempts issue, have you run the make clean first? If not, your changes may not have taken effect. It is recommended that you change the log print to confirm that your changes are effective like below.
cout << "[WARNING] ###Test### Unknown param found in source : " << paramKey << endl;
I’m not clear about the frame-interval setting. Do you mean there are two position settings which can control the msg frequecy? But as the code snapshoot, the msg frequency only controlled by the app level?
I have run the make clean first but still useless. It seems the setting still not be activated. I will check again.
The frame_interval in the app level can control the interval of the msg in the app. But the msg-conv-frame-interval in the config file control the interval of the msg in the plugin.
Please refer to our source code I attached before deepstream\sources\gst-plugins\gst-nvmsgconv.
......
if (self->msg2pNewApi) {
//generate payload at frameInterval(ex: every 30th frame)
if (self->frameInterval
&& (((NvDsFrameMeta *) frame_meta)->frame_num %
self->frameInterval))
continue;
......
Noted with thanks. It means the msg frequency would be contolled by these two settings. The frame-interval would control the msg building and the msg-conv-frame-interval would control the sending frequency.
setting two cameras to check whether the setting is effected or not , then run the procedure and got the following result: (one of cameras works normally, and the other do not connect)
In the reconnection scenario, the rtsp connection must be successful, but no data is available. The rtsp did not connect successfully in your scenario, so it just reported an connection error. To reconnect, you need to create a successful session first.
But we found the main procedure would be run successfully for deepstream5.1 with same setting. We just want to maintain the main procedure if any of cameras online, because some cameras maybe turn on with a delay.
This error is reported from the gstrtspsrc.c from the log you attached. This part is the source code for the Gstreamer. It is possible that the error was not reported in the old Gstreamer version, but the new version reported this error now.
You can refer to our code to try to handle this error yourself.