picture: no-op codec_set_controls case for VAProfileAV1Profile0 #10
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: marfrit/libva-v4l2-request-fourier#10
Reference in New Issue
Block a user
Delete Branch "noether/picture-av1-noop"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Unblocks AV1 frames reaching the daedalus daemon
Bug
VAProfileAV1Profile0 hit the default branch in
picture.c::codec_set_controls, returningVA_STATUS_ERROR_UNSUPPORTED_PROFILE. vaEndPicture failed with status 12, no OUTPUT buffer ever got queued, daedalus daemon never saw a REQ_DECODE.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". That NOP path was promised but never actually wired in picture.c.
Fix
Add a VAProfileAV1Profile0 case that just
break;s through. For the daedalus_v4l2 daemon path this is exactly the right shape — AV1 frame data is self-describing per OBU stream, so the OUTPUT buffer alone is sufficient for the kernel→daemon forward.Status on higgs
Before:
vaEndPicture-> status 12, no daemon traffic.After: AV1 frames queue to /dev/video2, daemon receives REQ_DECODE codec=2 messages, libdav1d context opens. Decode itself still fails because libdav1d needs an AV1 sequence header OBU which ffmpeg-vaapi sends separately via VAPictureParameterBufferAV1 (not in the slice buffer) — that's a daemon-side OBU synthesiser follow-up, analogous to the H.264 SPS/PPS NAL synth that DAEMON-PPS added in daedalus-v4l2/daemon/src/h264_nal_synth.c. Separate substantial work.
This patch unblocks AV1 reaching the daemon at all.
For RK3588 vpu981
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(...).Generated with Claude Code
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>