daemon: AV1 OBU sequence-header synthesis (forked from marfrit-packages#59) #14

New Issue

2026-05-21T18:11:03Z

claude-noether commented

2026-05-21 18:11:03 +00:00

Summary

Daemon-side AV1 OBU sequence-header synthesis is the missing piece to extend the V4L2 stateless decode path (already operational for H.264 + VP9 via daedalus_v4l2 kmod + this daemon) to AV1.

Context

Forked off from marfrit/marfrit-packages#59, which closed out the firefox-fourier h264/vp9 hwaccel-inert symptom via the libavcodec61-fourier compat-package route. AV1 was explicitly called out as "still in flight" in that issue's close-out comment, blocked on the same daemon needing OBU-level synthesis equivalent to what the DAEMON-PPS H.264 path already does for SPS+PPS NAL units.

What needs to happen (daemon side)

The kernel module ships V4L2 stateless AV1 controls (V4L2_CTRL_TYPE_AV1_FRAME + sequence/tile-group) per the V4L2 stateless AV1 uAPI. The daemon receives REQ_DECODE with the AV1 control structs but no AnnexB-style NAL stream — it must synthesise the OBU sequence header (and any necessary frame-level OBUs) from the bound V4L2 controls before handing the frame to libavcodec's AV1 decoder.

This is the AV1 analogue of the existing H.264 path implemented in daedalus_h264_meta (REQ_DECODE flag DAEDALUS_REQ_FLAG_H264_META, daemon synthesises AnnexB SPS+PPS NAL units from the bound H.264 stateless control structs).

Reference: existing H.264 code path that needs the AV1 sibling

kernel module: device_run() reading bound H.264 controls into struct daedalus_h264_meta shipped over chardev
daemon: SPS+PPS NAL synthesis from those structs before av_send_packet

End-to-end target

When this lands, the existing libva-v4l2-request-fourier + daedalus_v4l2 kmod + libavcodec61-fourier chain extends to AV1 with no further consumer-side changes. Firefox / mpv / ffmpeg AV1 hwaccel flows through /dev/daedalus-v4l2 → daemon → libavcodec 7.1 AV1 decoder → frame back to libva client.

marfrit/marfrit-packages#59 — closed-out parent, h264/vp9 verified, AV1 deferred here
daedalus-v4l2 kernel module already has the V4L2 stateless AV1 control plumbing infrastructure (verify which patch landed it; if not yet, kernel-side AV1 control wiring is a sub-task)
libva-v4l2-request-fourier — AV1 codec dispatch on the libva side; verify it routes via the daedalus path the same way H.264 does

## Summary Daemon-side AV1 OBU sequence-header synthesis is the missing piece to extend the V4L2 stateless decode path (already operational for H.264 + VP9 via `daedalus_v4l2` kmod + this daemon) to AV1. ## Context Forked off from [marfrit/marfrit-packages#59](https://git.reauktion.de/marfrit/marfrit-packages/issues/59), which closed out the firefox-fourier h264/vp9 hwaccel-inert symptom via the `libavcodec61-fourier` compat-package route. AV1 was explicitly called out as "still in flight" in that issue's close-out comment, blocked on the same daemon needing OBU-level synthesis equivalent to what the DAEMON-PPS H.264 path already does for SPS+PPS NAL units. ## What needs to happen (daemon side) The kernel module ships V4L2 stateless AV1 controls (`V4L2_CTRL_TYPE_AV1_FRAME` + sequence/tile-group) per the V4L2 stateless AV1 uAPI. The daemon receives `REQ_DECODE` with the AV1 control structs but no AnnexB-style NAL stream — it must synthesise the OBU sequence header (and any necessary frame-level OBUs) from the bound V4L2 controls before handing the frame to libavcodec's AV1 decoder. This is the AV1 analogue of the existing H.264 path implemented in `daedalus_h264_meta` (REQ_DECODE flag `DAEDALUS_REQ_FLAG_H264_META`, daemon synthesises AnnexB SPS+PPS NAL units from the bound H.264 stateless control structs). Reference: existing H.264 code path that needs the AV1 sibling - kernel module: `device_run()` reading bound H.264 controls into `struct daedalus_h264_meta` shipped over chardev - daemon: SPS+PPS NAL synthesis from those structs before `av_send_packet` ## End-to-end target When this lands, the existing libva-v4l2-request-fourier + `daedalus_v4l2` kmod + `libavcodec61-fourier` chain extends to AV1 with no further consumer-side changes. Firefox / mpv / ffmpeg AV1 hwaccel flows through `/dev/daedalus-v4l2 → daemon → libavcodec 7.1 AV1 decoder → frame back to libva client`. ## Related - marfrit/marfrit-packages#59 — closed-out parent, h264/vp9 verified, AV1 deferred here - daedalus-v4l2 kernel module already has the V4L2 stateless AV1 control plumbing infrastructure (verify which patch landed it; if not yet, kernel-side AV1 control wiring is a sub-task) - libva-v4l2-request-fourier — AV1 codec dispatch on the libva side; verify it routes via the daedalus path the same way H.264 does

claude-noether referenced this issue from marfrit/marfrit-packages

2026-05-21 18:11:22 +00:00

firefox-fourier: v4l2-request hwaccel inert on Pi 5 — no libavcodec with --enable-v4l2-request at the soname Firefox loads #59

marfrit closed this issue

2026-05-21 18:23:30 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: reauktion/daedalus-v4l2#14