Minor bug in nvstreamdemux FPS handling

We’re using Deepstream 5.1 and noticed a minor bug in the initial caps negotiation of different streams coming out of nvstreamdemux.

Simple setup to reproduce is:

When nvstreammux receives a CAPS event from either of the streams, it will push it further into nvstreamdemux. nvstreamdemux will then push it to BOTH of the streams, even if it doesn’t yet know the framerate of the other stream.

When nvstreamdemux receives the stream-frame-rate query for the other stream, it will push a second CAPS there, now with the correct framerate (triggering a renegotiation).

It would be nice if this could be fixed, and streamdemux waited for the stream-frame-rate to send CAPS to a stream. Not only would it prevent an unnecessary renegotiation on pipeline startup; it would also eliminate racy behaviour (this renegotiation only happens when the CAPS event reaches streamdemux before the query for each stream).

I’d fix it myself but (to my knowledge) there’s no source available.

[related to: Nvstreammux different stream FPS not handled correctly]

Thank you so much for your detailed report!

We will check internally and fix it.

1 Like

Has this now been resolved in Deepstream 6?

Not yet, we may plan it in next release.

Fixed in DeepStream 6.1