Early EOS when dynamically adding and removing streams

Accelerated Computing Intelligent Video Analytics DeepStream SDK
1

I found the example with dynamically adding and removing streams helpful, but going beyond the example I have found problems. Here’s what I’m doing and seeing:

  1. set up a single stream with the following config: uridecodebin → nvstreammux → testsink.
  2. put a probe on the testsink to see how many frames are processed.
  3. when the stream is completed, remove the uridecodebin and release the nvstreammux pad (pad 0) after sending a stop flush event as in the example code.
  4. Create a new uridecodebin, recreate the nvstreammux pad (pad 0) and connect the uridecodebin to it.
  5. only one frame is processed before an eos is seen for the source.

The only solution that I’ve come up with is to destroy and recreate the nvstreammux element every time I hook up the new source.

Any ideas? Even when I try setting nvstreammux to a Null state and back to playing, it still does this. Clearly the internal state isn’t being cleared properly when it is set to a Null state.

2

Will try to repro and check it internally and give you response, it would be better if you can share your code.

3

Here is some more information. I do have to tear down and recreate the nvstreammux or else it sends the EOS immediately on subsequent streams after the first one.

Then I noticed that the EOS is being sent for the second stream too early still, but if I listen for the Deepstream EOS message (number 102918) in the last sink element and close down the stream on that, then all of the frames are processed. By the way, I also have a nvstreamdemux on the other side of my infer element(s) and then I listen on the sink of the corresponding stream.

Here are some other strange things that I’ve noticed though:

  1. EOS is received in the bus multiple times per stream when multiple streams are hooked up. It seems to match with how many streams are attached at the time. This isn’t so hard to work around, but it was unexpected.
  2. 1 or 2 streams at a time seems to work pretty well. 3 and especially 4 streams are when things start failing. I no longer get a bus EOS event for one of the streams when I have 4 streams attached. I get crashes if I trigger shutting down the stream based on the EOS in the sink.
  3. some settings of batch-size in nvstreammux cause problems to occur. Even with a passthrough (videoconverter) in place of my infer element, I get problems with setting the batch-size on streammux. A batch-size of 1 or 2 with one stream set up seems to work, but a batch-size of 4 causes it to start processing, but deadlocks after a few frames (4) are processed. I’ve tried larger values of the batch-size and they also seem to deadlock after 4 frames. I just looked through the examples in the Deepstream SDK and they all appear to have a batch-size of 1 for the nvstreammux element. Have larger values been tested? I have a fakesink in place of my regular sink in this case to eliminate that as a possible issue. The stream is uridecodebin → nvstreammux → videoconverter (instead of nvinfer) → nvstreamdemux → fakesink. The batched-push-timeout is set to 40000 microseconds.

I’ll try to come up with some example code, but my current code uses Rust bindings and has some other elements like pulling from and pushing to external message queues.

For now, it looks like I’m stuck with 1 or 2 streams at a time for now with a batch-size of 1 and setting up and tearing down the nvstreammux element every time. Any ideas?

Also, is there any way for me to sign an NDA and help fix these issues?

4

Hey customer,
Would you mind to share me with your code, you can send me a private message.

5

Hi notmuchtotell,

We haven’t heard back from you in a couple weeks, so marking this topic closed.
Please open a new forum issue when you are ready and we’ll pick it up there.