• Hardware Platform (Jetson / GPU): GPU
• DeepStream Version: 7.1 (python)
• TensorRT Version: 10.3.0.26
• NVIDIA GPU Driver Version (valid for GPU only): 555.58.02
• Issue Type( questions, new requirements, bugs): questions
Hello. I have a few questions about working with the queue.
- Where are the frames that are in the queue stored? Are they on RAM or GPU memory?
- How do I see how many frames are in the queue? In python deepsteam. I used .add_probe for src and sink pads, and looked at the attributes current-level-time, current-level-bytes. But they always returns 0. For reading, I use nvmultiurisrcbin, and after that there is a queue and then nvinferserver.
The answer to this question depends on the type of your GstBuffer. If it is an NVMM
type buffer, the video frame is stored on the GPU memory, but the nvbufsurface is stored as a handle on the CPU. Other types of buffers are stored in RAM.
It is impossible to know exactly, current-level-bytes is 0, which means there is no delay in data processing.
Thanks for the reply. As for the problem with the current-level-bytes is 0. There must be a delay in processing the data, as messages on the triton server take a very long time to be sent. Accordingly, because of this, the queue should fill up very quickly, since nvmultiurisrcbin continues to read frames.
Please tell me how I can solve the problem with the fact that nothing adds up to the queue.
I don’t understand your intention. Besides, this question has nothing to do with DeepStream.
In fact, I tried your pipeline and got the following results
current_level_bytes 64
current_level_bytes 0
current_level_bytes 0
current_level_bytes 0
current_level_bytes 0
NvMMLiteOpen : Block : BlockType = 261
NvMMLiteBlockCreate : Block : BlockType = 261
current_level_bytes 0
current_level_bytes 0
current_level_bytes 64
deepstream_test1_app.c (11.1 KB)
A queue is the thread boundary element through which you can force the use of threads. Although triton has a delay, it does not mean that data will be cached in the queue
Thanks for the reply. And how, then, is it possible to emulate the accumulation of data in a queue?
You can simulate a slow sink, On my device, I can get the following logs:
Queue buffer count: 6
Queue buffer count: 6
Queue buffer count: 6
Queue buffer count: 6
Queue buffer count: 6
Queue buffer count: 6
import gi
gi.require_version('Gst', '1.0')
from gi.repository import Gst, GLib
Gst.init(None)
def on_pad_probe(pad, info, user_data):
queue = user_data
current_level_buffers = queue.get_property("current-level-buffers")
print(f"Queue buffer count: {current_level_buffers}")
return Gst.PadProbeReturn.OK
pipeline = Gst.parse_launch("videotestsrc ! video/x-raw,width=1920,height=1080,framerate=100/1 ! queue max-size-buffers=10 min-threshold-buffers=0 name=q0 ! ximagesink sync=true processing-deadline=1000000")
queue = pipeline.get_by_name("q0")
if not queue:
print("Could not find queue element")
exit(-1)
srcpad = queue.get_static_pad("src")
srcpad.add_probe(Gst.PadProbeType.BUFFER, on_pad_probe, queue)
pipeline.set_state(Gst.State.PLAYING)
try:
loop = GLib.MainLoop()
loop.run()
except KeyboardInterrupt:
pass
finally:
pipeline.set_state(Gst.State.NULL)
Can you share your goals? I might be able to give you better advice.