From a safety perspective, I was asked if there are any queues involved in the processing of v4l2 frames on the Jetson platform. I receive frames in userspace in a queue of 4. Are there any other queues involved in the processing?
Best regards,
Johannes
hello busch.johannes,
yes, VI driver queue frames internally, and it by default release buffer N at N+2 frame start event.
What do you mean by “by default”? Can I change this behavior to release frames earlier?
Does this mean by default there is a queue of 2 frames, correct?
Best regards,
Johannes
hello busch.johannes,
may I know what’s the real use-case, please share some description for reference.
Yes of course!
we are receiving frames with V4L2 in a real-time safety-critical application.
So we need to reduce the latency as much as possible with the Jetson system.
The team responsible for the safety asked about queues in the pipeline because queues can be traps for frames coming delayed or the same frame being presented multiple times in a state of failure. Queues are not a problem I guess, but at least they need to know about it.
can you accept this latency?
Latency is critical, so if there is a way to increase it, please let me know!
We already are pretty low when it comes to latency, but if it would be possible to reduce by one frame for example, this would be a huge step.
hello busch.johannes,
Xavier is using VI-5 kernel driver,
public_sources/source/public/kernel/nvidia/drivers/media/platform/tegra/camera/vi/vi5_fops.c
you may dig into VI-5 driver, Xavier series using two threads approach to capture a frame, for example, vi5_capture_enqueue and vi5_capture_dequeue.
finally, it’s calling vi5_release_buffer to write an image buffer to user-space… vb2_buffer_done().
compare to TX2 (vi-4) and Nano (vi-2) series, it’s already optimized.
Thanks for pointing out the important functions. I took a look at it and I think I understand most parts of it.
What I did not get yet, is where the N+2 release comes from. Using queues does not automatically mean we have this latency, and I do not see any holding back frames.
The dequeue is read out right away when there is a new buffer and new buffers seem to be enqueued right away when available.
Can you point out where the N+2 exactly comes from?
Best regards,
Johannes
my bad, actually it’s from my memory… Xavier series should be optimized to eliminate this latency.
Okay! Thanks for clarifying!
Let me know if in the future there are still options for improvement I can look into :)
Best regards,
Johannes
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.