marfrit/libva-v4l2-request-fourier
1
0
Fork 1
Code Issues 2 Pull Requests Actions Packages Projects Releases Wiki Activity

config: include video_fd_daedalus in profile enumeration probe #7

Merged
marfrit merged 1 commits from claude-noether/libva-v4l2-request-fourier:noether/libva-2-config-profile-enum-daedalus into master 2026-05-20 14:52:11 +00:00
Conversation 0 Commits 1 Files Changed 1
+7 -2
claude-noether commented 2026-05-20 14:46:05 +00:00
Collaborator
Copy Link
Copy Source

LIBVA-2 follow-up: H.264/VP9/AV1 profiles missing on Pi 5 mixed deploy

Bug

LIBVA-1 (PR #6, c332d34) added the per-codec dispatch in request_switch_device_for_profile so VP9/AV1/H.264 route to daedalus_v4l2 while HEVC stays on rpi-hevc-dec. But the dispatch never gets to fire because RequestQueryConfigProfiles walks any_fd_supports_output_format over a hardcoded fds[5] array that does NOT include video_fd_daedalus.

Result on higgs (Pi CM5, rpi-hevc-dec + daedalus_v4l2 both loaded):

$ LIBVA_DRIVER_NAME=v4l2_request vainfo
v4l2-request: phase 8.10: opened daedalus_v4l2 at video_fd=7 media_fd=8
  ...
vainfo: Supported profile and entrypoints
      VAProfileHEVCMain               : VAEntrypointVLD

Only HEVC enumerated. ffmpeg vaapi -i h264_test.mp4 then reports 'No support for codec h264 profile 578' and bails during hwaccel init, before the LIBVA-1 dispatch can run.

Fix

Extend any_fd_supports_output_format fds[] from 5 to 6, with the sixth being video_fd_daedalus when HAVE_DAEDALUS_V4L2 is on (-1 otherwise so it is skipped by the existing 'if fds[i] < 0 continue' guard).

daedalus_v4l2 advertises VP9F + AV1F + S264 on OUTPUT (verified on higgs via v4l2-ctl -d /dev/video2 --list-formats-out). After the fix, RequestQueryConfigProfiles returns the H264* + VP9Profile0 + AV1Profile0 profiles, all routing through the LIBVA-1 'd' kind in request_switch_device_for_profile.

Backward-compatible on RK3399/3588 — the new slot is gated by HAVE_DAEDALUS_V4L2 AND video_fd_daedalus >= 0; both false in those deployments. Existing 5-fd probe order unchanged.

Build clean on boltzmann (only config.c.o + request.c.o recompile).

Test plan (LIBVA-2 close)

Once merged + libva package rebuilt + installed on higgs:

  • vainfo should list VAProfileH264* + VP9Profile0 + AV1Profile0 + HEVCMain
  • ffmpeg -hwaccel vaapi -i h264_test.mp4 -f null - should land frames in the daedalus daemon journal
  • ffmpeg -hwaccel vaapi -i hevc_test.mp4 -f null - should NOT touch the daedalus daemon (HEVC routes to rpi-hevc-dec)

Generated with Claude Code

## LIBVA-2 follow-up: H.264/VP9/AV1 profiles missing on Pi 5 mixed deploy ### Bug LIBVA-1 (PR #6, c332d34) added the per-codec dispatch in request_switch_device_for_profile so VP9/AV1/H.264 route to daedalus_v4l2 while HEVC stays on rpi-hevc-dec. But the dispatch never gets to fire because RequestQueryConfigProfiles walks any_fd_supports_output_format over a hardcoded fds[5] array that does NOT include video_fd_daedalus. Result on higgs (Pi CM5, rpi-hevc-dec + daedalus_v4l2 both loaded): ``` $ LIBVA_DRIVER_NAME=v4l2_request vainfo v4l2-request: phase 8.10: opened daedalus_v4l2 at video_fd=7 media_fd=8 ... vainfo: Supported profile and entrypoints VAProfileHEVCMain : VAEntrypointVLD ``` Only HEVC enumerated. ffmpeg vaapi -i h264_test.mp4 then reports 'No support for codec h264 profile 578' and bails during hwaccel init, before the LIBVA-1 dispatch can run. ### Fix Extend any_fd_supports_output_format fds[] from 5 to 6, with the sixth being video_fd_daedalus when HAVE_DAEDALUS_V4L2 is on (-1 otherwise so it is skipped by the existing 'if fds[i] < 0 continue' guard). daedalus_v4l2 advertises VP9F + AV1F + S264 on OUTPUT (verified on higgs via v4l2-ctl -d /dev/video2 --list-formats-out). After the fix, RequestQueryConfigProfiles returns the H264* + VP9Profile0 + AV1Profile0 profiles, all routing through the LIBVA-1 'd' kind in request_switch_device_for_profile. Backward-compatible on RK3399/3588 — the new slot is gated by HAVE_DAEDALUS_V4L2 AND video_fd_daedalus >= 0; both false in those deployments. Existing 5-fd probe order unchanged. Build clean on boltzmann (only config.c.o + request.c.o recompile). ### Test plan (LIBVA-2 close) Once merged + libva package rebuilt + installed on higgs: - vainfo should list VAProfileH264* + VP9Profile0 + AV1Profile0 + HEVCMain - ffmpeg -hwaccel vaapi -i h264_test.mp4 -f null - should land frames in the daedalus daemon journal - ffmpeg -hwaccel vaapi -i hevc_test.mp4 -f null - should NOT touch the daedalus daemon (HEVC routes to rpi-hevc-dec) Generated with Claude Code
claude-noether added 1 commit 2026-05-20 14:46:05 +00:00
config: include video_fd_daedalus in profile enumeration probe d1ba4625d2 
LIBVA-2 follow-up.  RequestQueryConfigProfiles walks each known
decoder fd via any_fd_supports_output_format() and adds a VAProfile*
for each codec OUTPUT format the V4L2 device advertises.  The fd
list missed video_fd_daedalus — so on a Pi 5 with rpi-hevc-dec
primary + daedalus_v4l2 alt, only S265 (HEVC) was probed and the
H.264 / VP9 / AV1 profiles never got enumerated.

Effect on higgs: ffmpeg -hwaccel vaapi -i h264_test.mp4 reported
"No support for codec h264 profile 578" before the per-codec
dispatch in request_switch_device_for_profile could fire — the
profile-578 (H264 Constrained Baseline) check happened during
hwaccel init, found nothing in the libva profile list, and bailed
without ever calling into the daedalus path.

Fix: extend the fds[] array in any_fd_supports_output_format from
5 to 6 entries, with the sixth being video_fd_daedalus when
HAVE_DAEDALUS_V4L2 is on (and -1 otherwise so it's skipped by the
`if (fds[i] < 0) continue;` guard).  After the fix, daedalus_v4l2's
OUTPUT format menu (VP9F + AV1F + S264) gets seen, and Request-
QueryConfigProfiles returns VP9Profile0 + AV1Profile0 + the H264*
profiles, all of which then route through the LIBVA-1 'd' kind
override in request_switch_device_for_profile.

Verified on higgs:

  Before:
    vainfo: Supported profile and entrypoints
          VAProfileHEVCMain               : VAEntrypointVLD
    (only HEVC; H264/VP9/AV1 not enumerated)

  ffmpeg vaapi -i h264 → "No support for codec h264 profile 578"

Build clean on boltzmann (only config.c.o + request.c.o recompile).

Backward-compatible on RK3399/3588 — the new slot is gated by
HAVE_DAEDALUS_V4L2 *and* video_fd_daedalus >= 0; both stay false in
those deployments.  Existing 5-fd probe order unchanged.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
marfrit merged commit 989833114a into master 2026-05-20 14:52:11 +00:00
marfrit deleted branch noether/libva-2-config-profile-enum-daedalus 2026-05-20 14:52:11 +00:00
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
Clear labels
EWONTFIX
Triaged 2026-05-18: scoped out indefinitely; reopen-able if real need emerges. (HEVC-on-ampere first batch.)
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claude-noether (Claude (noether)) marfrit (Markus Fritsche)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: marfrit/libva-v4l2-request-fourier#7
Delete Branch "claude-noether/libva-v4l2-request-fourier:noether/libva-2-config-profile-enum-daedalus"

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?