we’re running into an issue where a set of buffers is looped indefinitely for a specific RSTP stream.
it doesn’t happen immediately, nor are there any messages posted when it does happen.
unfortunately trying to run it with GST_DEBUG level 5 goes too slow for a good test to take place
i’ve been adding signal and message handlers to look for GstElement activity that could help track down the cause.
the setup is…
deepstream custom app running in NVIDIA deepstream container (also used demo deepstream-app)
one instance per RTSP stream (only one stream per app instance, one app instance per container instance)
config is set to have batch size of 1 for mux and primary GIE
config is set for source latency to be 0 (same issue with latency of 100 and 200)
sources are live
sources tried - Axis q1785, VLC rtsp server
when the loop happens with an object that can be inferenced, the track ID increases which indicates the problem is before tracking.
i’ve modified the gstreamer queues to be have more capacity, and also made them leaky downstream to avoid queueing issues, still get the same result.
g_object_set(G_OBJECT(bin->dec_que), “leaky”, 2, NULL);
g_object_set(G_OBJECT(bin->dec_que), "max-size-buffers", 50, NULL);
have seen the same problem exist for both the demo deepstream-app and my custom app
does anyone have any ideas of where I should be looking to investigate this buffer looping?
i’ve added signal callbacks for the queues and they rarely get above 1 buffer in the queue
i was hoping to see an overrun on one of them.
any ideas on what else can be interrogated?
there is no queue between primary GIE and tracker so my guess is the issue is somewhere between source and tracker, downstream elements act as if they receive new data