Please provide complete information as applicable to your setup.
• Hardware Platform (Jetson / GPU) GPU • DeepStream Version 6.1 • JetPack Version (valid for Jetson only) • TensorRT Version 8.2.5-1+cuda11.4 • NVIDIA GPU Driver Version (valid for GPU only) 510.68.02 • Issue Type( questions, new requirements, bugs) questions • How to reproduce the issue ? (This is for bugs. Including which sample app is using, the configuration files content, the command line used and other details for reproducing)
When running deepstream-app with hikivision camera，i set pipeline-recreate-sec=5 . And after 5 seconds, the pipeline would recreate . But there comes a question, when i run with h264 file, the pipelien can recreate correctly. When i set 1 hikivision camera, the pipeline recreate raised core dump at gst_element_get_static_pad.
Here is the bt info:
if use one source and one sink, dose deepstream-app crashed again?
from the logs, there is rtspserver error “rtspserver rtsp-server.c:928:gst_rtsp_server_create_socket:GstRTSPServer@0x557e7739b640e[00m failed to create socket”,
can you try sink type=3? please refer to source30_1080p_dec_infer-resnet_tiled_display_int8.txt, it should not the camera’s issue if sink type=3 works.
please try different rtsp-port if type=4 because binding port failed in the logs.
Only one file source and one sink can recreate normally. One rtsp source and one file sink will core dump at gst_element_get_static_pad like aforementioned.
Here is the config file:
I found a new question, running with a file source and a file sink, i set pipeline-recreate-sec=5, it will core dump without gdb. When i gdb the deepstream-app with pipeline-recreate-sec=5 ,it can run normally. And running with –gst-debug-level=4, it also can run normally.
So i edit pipeline-recreate-sec=10, it can run normally without gdb. Does the pipeline-recreate-sec influence the recreate result? In other word, does this means i can`t recreate the pipeline frequently? Or it may lead to some mistake.
please set engine path in config_infer_primary_yoloV5.txt, otherwise it will create engine every time it runs.
if did not set pipeline-recreate-sec, dose “set a rtsp source and a file sink” run ok, I found error “gstrtspsrc.c:6563:gst_rtspsrc_send:<src_elem0>e[00m error: Option not supported (551)” in the log oneHikivisionOneFileSink.zip.
I can’t reproduce this issue by deepstream native Primary_Detector model, here is the cfg: c.txt (1.3 KB)
i set model_engine_file in config_infer_primary_yolov5.txt
Set hikivision rtsp source and a file sink, the pipeline can run normally. I google the error “Option not supported(551)”, it says the hikivision don`t support pause ability. When invoke gst_element_set_state(PAUSED), it will send the pause command to the camera.
multiuri is not rtsp type.
from log oneHikivisionOneFileSink.zip, there is “Recreate pipeline” but no “can’t set pipeline to playing state”, please add more logs in recreate_pipeline_thread_func to check which line will trigger crash.
From log oneHikivisionOneFileSink.zip, there is “Recreate pipeline” but no “can’t set pipeline to playing state”, it crashed at the first recreate, from the crash stack, it crashed in cb_newpad of deepstream_source_bin.c, it seemed one thread is using object while other thread is destroying. why do you need to set pipeline-recreate-sec=5, please set it to 10 to work around.
Cause i wrap the deepstream with grpc, thus the program can interact with a java web service. It can start to ai-analysis when java service send a start command . And it can stop ai-analysis when java service send a stop command.
To implement this command, i refer to the recreate_pipeline_thread_func. When start ai-analysis, i invoke create_pipeline and set the pipeline to playing state. When stop ai-analysis, i invoke destroy_pipeline_func.
To ensure the interface work normally, i should test the recreate_pipeline_thread_func first.
After adding logs in cb_rtspsrc_select_stream, at the first time, it will create bin->depay, after recreating pipeline, it did not enter cb_rtspsrc_select_stream, so the application crashed in cb_newpad3 because bin->depay is invalid.
AppCtx is global variable, NvDsSrcBin’s depay is not set to NULL after destroying pipeline, NvDsSrcBin’s depay will not be created again after new creating pipeline, as a result, the application crashed in cb_newpad3 because bin->depay is invalid.
set NvDsSrcBin’s depay to NULL in destroy_pipeline.
I make a simple test, if the bin->depay is old. It can also invoke gst_element_get_static_pad（） correctly. So Why the program core dump at gst_ele_get_static_pad funcion?
Here is the test code:
loop = g_main_loop_new(NULL, FALSE);
with this fix “set NvDsSrcBin’s depay to NULL in destroy_pipeline”, will your code crash again(RTSP source)?
after destroying pipeline, NvDsSrcBin’s depay will be freed, but it was not set to NULL, so it is a wild pointer.
Another quesiton, i want to know how to trigger the rtspsrc select-stream signal.The doc says “Emitted before the client decides to configure the stream num with caps.” But in deepstream , i can`t find any code about set caps to rtspsrc element. Thanks.