picture: no-op codec_set_controls case for VAProfileAV1Profile0

picture.c's codec_set_controls() switch was falling through to the
default case for VAProfileAV1Profile0, returning
VA_STATUS_ERROR_UNSUPPORTED_PROFILE.  Result: vaEndPicture failed
with status 12 ("requested VAProfile is not supported"), no OUTPUT
buffer ever got queued, and the daedalus_v4l2 daemon never saw a
REQ_DECODE for AV1.

config.c's VAProfileAV1Profile0 case (line 84-93) explicitly notes
"Decode-side ctrl dispatch (V4L2_CID_STATELESS_AV1_*) is NOT YET
WIRED on master — vainfo will list the profile + CreateConfig
succeeds, but consumers that submit decode buffers hit a NOP path".
The NOP path was never actually wired in picture.c — it hit the
default UNSUPPORTED_PROFILE branch instead.

Fix: add a VAProfileAV1Profile0 case that just `break;`s through
without setting V4L2 controls.  For the daedalus_v4l2 daemon path
this is exactly the right shape — AV1 frame data is self-describing
per OBU stream (no separate SPS/PPS controls needed at the V4L2
boundary), so the OUTPUT buffer alone is sufficient for the kernel
to forward to the daemon.

Verified on higgs: ffmpeg -hwaccel vaapi -i av1.mkv now actually
queues frames to /dev/video2 and the daemon's libdav1d context opens.
Decode itself still fails (libdav1d wants the AV1 sequence header
OBU, which ffmpeg-vaapi sends via VAPictureParameterBufferAV1 not
via the slice buffer) — separate issue, needs an OBU sequence-header
synthesiser in the daedalus daemon (analogous to the new H.264
SPS/PPS NAL synth in daedalus-v4l2/daemon/src/h264_nal_synth.c).
That sequence-header synth work is a substantial follow-up; this
patch unblocks AV1 reaching the daemon at all.

For RK3588 vpu981 (the originally-planned AV1 target), this
remains a true NO-OP — when V4L2_CID_STATELESS_AV1_* dispatch
lands from the av1-iter1 operator branch, replace the no-op with
av1_set_controls(...).

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

src/config.c

@@ -172,15 +172,20 @@ VAStatus RequestDestroyConfig(VADriverContextP context, VAConfigID config_id)
 static bool any_fd_supports_output_format(struct request_data *driver_data,
 					  unsigned int fmt)
 {
-	int fds[5] = {
+	int fds[6] = {
 		driver_data->video_fd,
 		driver_data->video_fd_rkvdec,
 		driver_data->video_fd_hantro,
 		driver_data->video_fd_rpi_hevc_dec,  /* iter40 */
 		driver_data->video_fd_vpu981,        /* ampere-av1 Phase 2 */
+#ifdef HAVE_DAEDALUS_V4L2
+		driver_data->video_fd_daedalus,      /* LIBVA-1: H.264/VP9/AV1 */
+#else
+		-1,
+#endif
 	};
 	int i;
-	for (i = 0; i < 5; i++) {
+	for (i = 0; i < 6; i++) {
 		if (fds[i] < 0) continue;
 		if (v4l2_find_format(fds[i], V4L2_BUF_TYPE_VIDEO_OUTPUT, fmt))
 			return true;

src/h264.c

@@ -827,10 +827,63 @@ int h264_set_controls(struct request_data *driver_data,
 
 	dpb_update(context, &surface->params.h264.picture);
 
+	/*
+	 * Dump the raw VAAPI fields at the libva boundary so issue #8
+	 * follow-up can disambiguate "ffmpeg-vaapi didn't populate" from
+	 * "downstream consumer (daedalus_v4l2 wire protocol) corrupted the
+	 * value". One-line; safe to leave in — costs a single printf per frame.
+	 */
+	request_log("h264_set_controls: VAProfile=%d seq_fields=0x%08x pic_fields=0x%08x num_ref_frames=%u bit_depth_luma_m8=%u bit_depth_chroma_m8=%u w_mbs_m1=%u h_mbs_m1=%u\n",
+		    (int)profile,
+		    surface->params.h264.picture.seq_fields.value,
+		    surface->params.h264.picture.pic_fields.value,
+		    surface->params.h264.picture.num_ref_frames,
+		    surface->params.h264.picture.bit_depth_luma_minus8,
+		    surface->params.h264.picture.bit_depth_chroma_minus8,
+		    surface->params.h264.picture.picture_width_in_mbs_minus1,
+		    surface->params.h264.picture.picture_height_in_mbs_minus1);
+
 	h264_va_picture_to_v4l2(driver_data, context, surface,
 				&surface->params.h264.picture,
 				&decode, &pps, &sps);
 
+	/*
+	 * max_num_ref_frames fallback. Some VAAPI clients (older ffmpeg-vaapi
+	 * paths, some daedalus_v4l2 consumers) leave VAPicture->num_ref_frames
+	 * at zero. Hardware decoders tolerate; libavcodec-via-daedalus enforces
+	 * sps.max_num_ref_frames strictly and rejects every frame.
+	 *
+	 * Count valid DPB entries first (the bitstream-true reference count we
+	 * can see); fall back to a per-profile spec minimum if even that is 0.
+	 * See marfrit/libva-v4l2-request-fourier issue #8.
+	 */
+	if (sps.max_num_ref_frames == 0) {
+		unsigned int valid = 0;
+		unsigned int i;
+		for (i = 0; i < 16; i++) {
+			const VAPictureH264 *ref =
+				&surface->params.h264.picture.ReferenceFrames[i];
+			if (!(ref->flags & VA_PICTURE_H264_INVALID))
+				valid++;
+		}
+		if (valid > 0) {
+			sps.max_num_ref_frames = (uint8_t)valid;
+		} else {
+			switch (profile) {
+			case VAProfileH264ConstrainedBaseline:
+				sps.max_num_ref_frames = 1;
+				break;
+			case VAProfileH264Main:
+			case VAProfileH264High:
+			case VAProfileH264MultiviewHigh:
+			case VAProfileH264StereoHigh:
+			default:
+				sps.max_num_ref_frames = 4;
+				break;
+			}
+		}
+	}
+
 	/*
 	 * Populate the scaling matrix unconditionally: from VAAPI's
 	 * VAIQMatrixBufferH264 when the consumer sent one this frame

src/picture.c

@@ -318,6 +318,30 @@ static VAStatus codec_set_controls(struct request_data *driver_data,
 			return VA_STATUS_ERROR_OPERATION_FAILED;
 		break;
 
+	case VAProfileAV1Profile0:
+		/*
+		 * AV1 has no codec-specific V4L2 control dispatch wired up
+		 * yet on this branch (see config.c VAProfileAV1Profile0
+		 * comment).  For the daedalus_v4l2 daemon path that's fine:
+		 * AV1 frames are self-describing per-frame (OBU sequence +
+		 * frame headers carry everything libavcodec needs), so the
+		 * bitstream in the V4L2 OUTPUT buffer is sufficient — no
+		 * V4L2_CID_STATELESS_AV1_* controls have to be populated.
+		 *
+		 * Per-codec dispatch in request_switch_device_for_profile
+		 * has already retargeted (video_fd, media_fd) to
+		 * video_fd_daedalus (or video_fd_vpu981 on RK3588 if
+		 * present) by the time we get here; the OUTPUT buffer will
+		 * be queued via that fd and the kernel forwards bytes to
+		 * the daemon as a regular REQ_DECODE.  No-op is the
+		 * correct shape.
+		 *
+		 * When the vpu981-targeted V4L2_CID_STATELESS_AV1_* dispatch
+		 * lands from the av1-iter1 operator branch, replace this
+		 * with av1_set_controls(...).
+		 */
+		break;
+
 	default:
 		return VA_STATUS_ERROR_UNSUPPORTED_PROFILE;
 	}