I have a pipeline with multiple input bins. In the input bin rtspsrc buffers goes to tee which will copy buffers to the first branch having decodebin. The seconf copy goes to the branch having splitmuxsink. Like queue → splitmuxsink.
Splitmuxsink requires EOS to finish the last segment. The problem is that when i send EOS to queue pad of this branch, the EOS gets into the Bus. Than all the elements in the pipeline knows that there is a EOS requested.
This leads to the problem that nvstreammux element reports EOS received and reject that input branch.
I am curious if it is possible to isolate EOS event.
Also I tried splitmuxsink split-now with a little waiting afterwards. But that did not work to fix the last segment.
Pushing an EOS event just into the queue ! splitmuxsink branch sounds like the right thing to do in your case in principle.
Sinks will post an EOS message on the bus when they receive an EOS event and have output all pending data (e.g. an audiosink could still have a few milliseconds of audio buffered internally when the EOS event comes in).
That EOS message from the sink might then be intercepted by the pipeline or bin, since by default pipelines and bins have special handling for EOS and will only post/forward the EOS message if all sinks in a bin/pipeline have posted an EOS message.
You can, however, still be notified when the one sink posts an EOS message. That can be done by setting the message-forward property to true on the pipeline/bin, then your application will get a special element message from the splitmuxsink with the EOS wrapped inside it. That way you can now that the splitmuxsink has finished writing everything out to file, in case you want to remove the branch or so.
So in your case there shouldn’t be an EOS message making it through to the application because the other branch is still running.
The reason this happens is probably (I’m guessing here) that you didn’t unlink the queue from the tee before pushing in the EOS event. When an EOS event travels through the pipeline, the pads will be flagged as being in EOS state, so they will refuse further data, and that will tell the upstream elements (tee, source) to go EOS as well. If you unlink the queue first, that should not happen hopefully and the other branches should continue as normal.
By default bins (and the top-level pipeline, which is a special bin subclass) have special handling for EOS messages: They will “aggregate” EOS messages, so that only when all sinks have posted an EOS message the EOS will be forwarded to the parent bin and eventually to the application.
You can set the message-forward=true property on the pipeline (and intermediary bins, if any), then the EOS event from the recording branch sink will be forwarded to the application anyway, wrapped inside an element message.