Issue with Corrupted Frames and Frame Discarding in GStreamer 1.16 on Xavier NX (L4T 35.5.0, Kernel 5.10)

Dear GStreamer,

I’m encountering an issue related to handling corrupted video frames after porting my code from a 4.9 kernel to a 5.10 kernel on a Xavier NX platform (L4T 35.5.0).

In the older kernel (4.9) using the videobuf2 framework, I believe there was a “requeue” option that allowed for the re-submission of buffers. However, this feature seems to be removed in kernel 5.4 and later, as I understand it.

Currently, with the 5.10 kernel, when a frame received from the kernel is in an error state (specifically, the VB2_BUF_STATE_ERROR flag is set in the kernel space), GStreamer 1.16 still passes this frame to the userspace pipeline. This results in errors and the corrupted frame being potentially displayed, which is undesirable.

My goal is to discard these corrupted frames within the GStreamer pipeline before they reach the display.

My questions are:

  1. Is there a recommended approach in GStreamer 1.16 to detect and discard frames that have been flagged with VB2_BUF_STATE_ERROR by the kernel?
  2. Are there specific GStreamer elements or properties that can be used to achieve this frame discarding based on metadata or buffer flags?
  3. Could the removal of the “requeue” option in newer kernels be directly contributing to this behavior in GStreamer?
  4. Are there any known issues or best practices related to handling VB2_BUF_STATE_ERROR flags within GStreamer on the Xavier NX platform with L4T 35.5.0 and a 5.10 kernel?
  5. Looking ahead, do future versions of GStreamer offer more explicit support for discarding frames reported as erroneous from kernel space? If so, could you provide some details or point me towards relevant documentation?

Any insights, suggestions, or pointers on how to effectively discard these corrupted frames within my GStreamer 1.16 pipeline on the Xavier NX would be greatly appreciated.

Thank you for your time and assistance.

Sincerely,
Hari

GStreamer 1.16 is too old. I guess better to upgrade gstreamer first.

Hi Joe,

I compared the gstreamer-plugins-good/sys/v4l2/gstv4l2bufferpool.c source code between GStreamer versions 1.16 and 1.25 and found no implementation for discarding frames when the VB2_BUF_STATE_ERROR flag is set.

However, in version 1.26, I found a patch (patch link) that was pushed 5 days ago. This patch attempts to identify frames with the VB2_BUF_STATE_ERROR and discard them on the decoding side.

Since our primary goal is to discard these frames within v4l2src itself, we’ve updated the code as shown below. For now, it successfully discards the error frames. However, I’m unsure if there are any hidden bugs, so I request you to review my code changes.

Note that the patch below is for GStreamer-plugins-good version 1.16:

From bc49b9df049a80d6eaac15de1cab63dc48df2273 Mon Sep 17 00:00:00 2001
From: cibi-p <brohari740@gmail.com>
Date: Thu, 24 Apr 2025 12:53:27 +0530
Subject: [PATCH] patch for discarding the corrupted frame in the v4l2src

Signed-off-by: cibi-p <brohari740@gmail.com>
---
 sys/v4l2/gstv4l2bufferpool.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/sys/v4l2/gstv4l2bufferpool.c b/sys/v4l2/gstv4l2bufferpool.c
index 49f222b..fa8800e 100644
--- a/sys/v4l2/gstv4l2bufferpool.c
+++ b/sys/v4l2/gstv4l2bufferpool.c
@@ -1227,6 +1227,16 @@ gst_v4l2_buffer_pool_dqbuf (GstV4l2BufferPool * pool, GstBuffer ** buffer,
   GST_LOG_OBJECT (pool, "dequeueing a buffer");

   res = gst_v4l2_allocator_dqbuf (pool->vallocator, &group);
+
+  while (group->buffer.flags & V4L2_BUF_FLAG_ERROR) {
+    GST_ERROR_OBJECT (pool, "correpted frame found - frame Num: %d. Dequeueing again!",
+      group->buffer.index);
+    res = gst_v4l2_allocator_dqbuf (pool->vallocator, &group);
+
+    if (res != GST_FLOW_OK)
+      break;
+  }
+
   if (res == GST_FLOW_EOS)
     goto eos;
   if (res != GST_FLOW_OK)
-- 
2.25.1

Let gstreamer guys help you check this out. They are experts. Note that this version of gstreamer may have more memory leaks.