h264: rate-limit V4L2 readback EACCES warning to once per process

Hantro+v4l2 on Linux 6.19.x returns EACCES from VIDIOC_G_EXT_CTRLS
on a request_fd in QUEUEING state for compound H.264 controls. Not
actionable from userspace — kernel-side permission check whose
semantics aren't yet investigated. Decode is unaffected (SET-side
write succeeds; we just can't verify via readback from this rig).

Logging the failure once per process instead of per-frame keeps
the diagnostic message visible without flooding stderr.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

src/h264.c

@@ -1019,6 +1019,8 @@ int h264_set_controls(struct request_data *driver_data,
 		rb_controls[1].p_h264_pps = &pps_rb;
 		rb_controls[1].size = sizeof(pps_rb);
 
+		static bool readback_warned = false;
+
 		rb_rc = v4l2_get_controls(driver_data->video_fd,
 					  surface->request_fd,
 					  rb_controls, 2);
@@ -1039,9 +1041,21 @@ int h264_set_controls(struct request_data *driver_data,
 				    !!(pps_rb.flags & V4L2_H264_PPS_FLAG_SCALING_MATRIX_PRESENT),
 				    pps_rb.num_ref_idx_l0_default_active_minus1,
 				    pps_rb.num_ref_idx_l1_default_active_minus1);
-		} else {
+		} else if (!readback_warned) {
-			request_log("V4L2 readback FAILED — controls written "
+			/*
-				    "but readback ioctl errored\n");
+			 * Rate-limit: log once per process. Linux 6.19.x
+			 * hantro+v4l2 returns EACCES when reading compound
+			 * H.264 controls from a request fd that is in
+			 * QUEUEING state. Not actionable from userspace;
+			 * symptomatic of a kernel-side permission check
+			 * not yet investigated. Decode itself is unaffected
+			 * — the SET-side write succeeded; we just can't
+			 * verify it via readback from this rig.
+			 */
+			request_log("V4L2 readback unavailable on this "
+				    "rig (EACCES from VIDIOC_G_EXT_CTRLS on "
+				    "request_fd) — not retrying\n");
+			readback_warned = true;
 		}
 	}