Two frame latency/delay in TX2 V4L stack

[bdehj]

Hi Guys,

We use JetPack3.3 & l4t/l4t-r28.2. We found camera capture timestamp (user space with gettimeofday) is two frame later compared with actual camper capture content. We use an time clock gui showing on tx2 board and use camera to capture this clock.

Seems there are about two frames on tx2. We search relative topic below. Do we need to apply relative patch by hand?
How about the latest JetPack3.x? Did it fixed or improved now?

One frame latency/delay in TX1 V4L stack

We have noticed some problematically large latency in the TX1 V4L stack, and am wondering if you might be able to shed some light on where the issues may be coming from. We are seeing ~66ms of latency in the camera stream, and believe that it is related to something in the TX1 driver stack because we have tested 3 different configurations with the same cameras: MIPI data directly into the TX1 results ~66ms of latency MIPI data into the TX1 via USB (using a MIPI to USB converter) results in ~6…

[ShaneCCC]

Have a try below patch.

(tx2)the camera delay N+2 frame

Hi, Please have a try this patch for modify QUEUED_BUFFERS 2 diff --git a/drivers/media/platform/tegra/camera/vi/channel.c b/drivers/media/platform/tegra/camera/vi/channel.c index 0a07f9d..057678f 100644 --- a/drivers/media/platform/tegra/camera/vi/channel.c +++ b/drivers/media/platform/tegra/camera/vi/channel.c @@ -525,7 +525,7 @@ static void add_buffer_to_ring(struct tegra_channel *chan, static void update_state_to_buffer(struct tegra_channel *chan, int state) { - int save_index = …

[bdehj]

ShaneCCC,

Seems it works. Can you give me more explanation why this patch fix the issue?
Another question is is there any side-effect if we apply this patch?

[ShaneCCC]

The patch fix the QUEUED_BUFFERS define as 2, this define hold QUEUED_BUFFERS -1 buffer to return to userspace.
I can’t make sure if any side-effect current still under review/test for this patch.