Please provide complete information as applicable to your setup.
• Hardware Platform (Jetson / GPU) GPU • DeepStream Version 6.3 • NVIDIA GPU Driver Version (valid for GPU only) 535.113.01 • Issue Type( questions, new requirements, bugs) questions • Language python
My pipeline is able to dynamically add/remove sink when new source is added/removed. Refer to this question, I create a similar pipeline with some modification for my own problem, but in overview, it is quite similar.
…-> queue → nvstreamdemux → (queue → nvosd → nvvideoconvert → capsfilter → x264enc → h264parse → muxer → splitmuxsink). The subgraph inside the round brackets is wrapped as a sink_bin, this part will be created when new video is added, and removed when the video is done.
The problem is when doing following steps:
The pipeline starts running with video 1, an output video is created.
After a few seconds, video 2 is added, new output video is created.
When the video 1 is done, bus_call gets an EOS event for video 1.
When the video 2 is done, bus_call gets two more EOS events(one for the video 1 and one for the video 2).
My expectation are:
When the video 2 is done, only EOS event of the video 2 is gotten in bus_call.
For video 1, new output videos must be created every 10 seconds(b/c I use splitmuxsink with max-size-time = 10_000000000), however, only until the video 2 is done, remaining videos are created for video 1.
What could be the root cause of this? If you guys need more information, please let me know.
Thank you.
I am sorry that I cannot show the project.
The basic idea is when new source is added, I create new sink_bin, then linking sink_pad of the bin with streamdemux source pad. Upon completion of the source, I perform a reversal by unlinking then release source pad of the streamdemux.
If possible, can you provide some suggestions/assumptions on those issues?
In theory, you need to ensure that the sink_id of the streammux and source_id of the streamdemux from the same source can correspond. Since your project is not publicly available, could you provide a simple demo to reproduce the issue you described?
Hi @yuweiw
Attached, you will find both the main file and the log. Please help me to modify the URIs of the two videos(search TODO 1) and the config for PGIE(TODO 2) before running the main file.
As you will see in the log file, the message “Got EOS events from stream_id: 0” appears not only one time. Besides, output videos for video 1 is not generated enough.
I use the deepstream:6.3-triton-multiarch docker. This is my log. I cannot reproduce the issue you mentioned. demo.log (69.1 KB)
Can you simplify your code and keep only the core logic? This makes it easier for us to analyze that. Thanks
Hi @yuweiw,
Thank you for following up with me. The current pipeline contains only necessary parts to reproduce the issue.
Your resource seems strong so it finishes the pipeline before this condition(line 535) met: if GLOBAL_CNT == 20:
Can you please help me to set lower value, e.g. if GLOBAL_CNT == 5:, so that it adds the second source to the running pipeline.
Recently, after more investigation, I suspect that the issue comes from splitmuxsink element. When one source is finished and the other is running, it kept posting eos event on the bus everytime splitmuxsink of the remaining source triggers new segment.
If the issue comes from splitmuxsink, You may need to file a topic to the Gstreamer forum. This plugin is a native plugin of Gstreamer. How do you confirm that this eos is from splixmuxsink? If you can identify it, you can do some special processing in the buscall.
Hi @yuweiw,
after one stream finished, the frequency of eos events sent to the bus appears proportionally with the split_max_time of remaining sink. Can we conclude that the splitmuxsink is the root cause?
I also tried setting the remaining sink’s state to NULL when the first stream finished, then set back to PLAYING, now the eos message is gone, but it does not produce output videos anymore.
There is no update from you for a period, assuming this is not an issue anymore. Hence we are closing this topic. If need further support, please open a new one. Thanks
When you say eos, are you referring to the Gst.MessageType.EOS or stream-eos？ If the eos message means Gst.MessageType.EOS, the splitmuxsink maybe the root cause. But if it’s stream-eos, the root cause should not be related to splitmuxsink.