Re-creating the same pipeline as deepstream-app will result in an error.

I created the same pipeline as the deepstream-app provided in deepstream-v3.0.

And I confirmed that there is no problem with the configuration as a .dot file.

The configuration is roughly as follows.

rtspsrc-decodebin-tee-queue-nvstreammux-pgie-nvtracker-sgie-nvstreamtiler-nvosd-appsink
|
-queue-fakesink

However, in the case of rtsp, it was determined that the configuration might fail due to an invalid address or connection failure.

So I implemented it to remove and re-create an existing pipeline when eos or an error message appears.

When I put the correct address, I noticed that the appsink comes up with an image.

However, if you enter an invalid address, an error occurs when you recreate the pipeline.

The following message appears to be an error on the nvinfer side.

Using TRT model serialized engine /home/gamsi/test/test_pipeline/conf/…/models/1st/resnet10.caffemodel_b30_int8.engine crypto flags(0)
Cuda error in file src/implicit_gemm.cu at line 648: invalid resource handle
Test_GStreamer: cuda/customWinogradConvActLayer.cpp:240: virtual void nvinfer1::rt::cuda::WinogradConvActLayer::allocateResources(const nvinfer1::rt::CommonContext&): Assertion `convolutions.back().get()’ failed.
Aborted (core dumped)

Removing the nvinfer module will not cause an error during regeneration.

How can I make the entire pipeline neat again?

I have found the answer to the same problem on the site below.

https://devtalk.nvidia.com/default/topic/1038648/deepstream-for-tesla/gstreamer-pipeline-recreation-leads-to-segfault-if-the-pipeline-contains-nvinfer-node/

You must first create the entire pipeline once and then modify it in such a way as to adjust the pipeline state on EOS or in the event of an error.

I did not check the actual image, but it looks like the log is working properly.

Looks like the problem is not completely resolved.

After disconnecting and reconnecting the network cable, we confirmed that a reconnection occurred.

However, if an EOS message is received, it will receive the SDP information, but the actual data will not come in and will continue to attempt to reconnect.

(I’ve streamlined the file to the VLC server and identified a problem when it reaches the end of the file.)

Is there a way to solve this problem?

I think I found a solution.

I tried using the gst_pad_add_probe function to connect the probe to the next element in rtspsrc and set it to not process the eos message.