I’m sorry, I checked again when GST_DEBUG=4, but when I turned off the printing information, I could see that the printing " In cb_newpad ",did not continue to run, and the callback printing In fakesink_src_pad_buffer_probe did not trigger. I hope you can try again.
when I use " ./deepstream-preprocess-test rtsp://127.0.0.1:8554/test 2", there is “data come” printing , when I " ./deepstream-preprocess-test rtsp://127.0.0.1:8554/test 3", there is no “data come” printing, the pipeline is not right, so please check the code and narrow down the issue.
pipeline-3.zip (1007.3 KB)
Incorrect plumbing? There is no problem with the logic of connecting pipelines. I just added one more group of queues, and I can’t find the error by checking the pipeline diagram. This is what I said before when adding many queues, pipelines are incorrect.
When you change int nDeviceNum=25 to int nDeviceNum=15 in the program, you will find that “data come” is also printed when the second parameter is 4, so I think my pipe connection logic is OK, so I suspected that there is an upper limit on the number of pipe components.
I really don’t have any clue about this problem, so I hope you can reply as soon as you have any discovery or progress. Thank you.
did you check the above pipeline-3.zip? the pipeline is wrong, no one link to queue1, but " ./deepstream-preprocess-test rtsp://127.0.0.1:8554/test 2" 's pipeline is ok.
1 Like
I checked the pipeline drawing carefully and found the problem. I printed GstIterator* pGstIterator = GST_BIN_iterate_elements (GST_BIN(pipeline)); The value of pGstIterator->size has always been 152, which I always thought was the number of components in the pipeline. It was 152 that caused the problem in my code logic. I solved this problem by reassigning. Thank you very much for your help
Glad to know you fixed it, thanks for the update!
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.