Faster camera rendering than Gstreamer


Looking to render a camera stream as fast as physically possible on the TX2i. At the moment, I have a bare bones program that uses the V4L2 API to grab frames and display them in a window using GLFW3 and OpenGL. Even with this simple program, my latency is about 2 or 3 frames behind Gstreamer using nvarguscamerasrc.

Should I be expecting my program to be faster than Gstreamer, or is that too optimistic? Is the argus pipeline faster than V4L2? Does gstreamer double buffer, like GLFW typically does?

Executing ‘sudo jetson_clocks’ brings GPU to max clocks, which should benefit the rendering through GLFW3 and OpenGL. Please have a try.

I have indeed tried jetson_clocks, but it does not improve the performance. Gstreamer latency comes in around 60-80 ms, whereas my program comes in around 150ms. I’m struggling to find where this extra latency is coming from, especially since I have timed my entire loop (using glFinish to make sure rendering is done) and it takes 33 ms to fill the frame buffer and display it. This is expected since the camera is 30 fps and I have to wait on it for a buffer to be filled, plus the time to render is around 16ms.

Still, maybe by the time I receive the frame from V4L2 it is already behind by 2-3 frames? Do you know of any sort of frame buffering that happens at that level?


How is the latency if you capture using GStreamer with v4l2src? If you are using V4L2 to capture in your application then you are skipping the ISP and thus, an equivalent test would be to capture using GStreamer with v4l2src instead of nvarguscamerasrc.

Depending on how is your V4L2 application configured you might have about 2-3 buffers stored at the kernel level (a ring buffer).

Best Regards,

I would like to try using v4l2src, but my understanding is that it does not support the default onboard camera (OV5693) due to pixel format. I will be getting a different camera at some point in the future, but it is RAW12 and I’m unsure if v4l2src will support that either.

One thing I did try was using an opencv VideoCapture object using Gstreamer as the source, then displaying with OpenGL. Once again it seems like there is a buffer of a few frames before it gets rendered and the latency is worse than using gstreamer in terminal. The VideoCapture object does have some configuration options, including setting a number of buffers, but any attempt to modify those options leads to a segmentation fault. This might be due to using gstreamer as the source, but unfortunately I cannot open the device directly with VideoCapture due once again to pixel format.

How can I configure my V4L2 application to avoid having a ring buffer? The latency is there even when I request a single V4L2 buffer.

Hi @dylan,
We only support ring buffer by default. Please contact us to have further cooperation.