From ee42419479c328b5f6d6da708496a80403c6d960 Mon Sep 17 00:00:00 2001 From: claude-noether Date: Fri, 22 May 2026 20:46:27 +0200 Subject: [PATCH] proto: bump PROTO_MAX_PAYLOAD 64 KiB -> 1 MiB (closes #19) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Real H.264 access units routinely exceed the previous 64 KiB cap on the chardev wire protocol: 720p worst-case I-frame ~200 KiB 1080p worst-case I-frame ~500 KiB libva-v4l2-request-fourier detects the under-sized OUTPUT-MPLANE buffer and tries to grow it via VIDIOC_S_FMT to 147456 B, but daedalus_fill_output_fmt unconditionally pins sizeimage to DAEDALUS_MAX_BITSTREAM (= 65484) regardless of userspace's request. Firefox loses the slice, falls back to libmozavcodec SW for the rest of the session. Bumping the wire-protocol cap to 1 MiB lifts the kernel OUTPUT_MPLANE sizeimage with it (DAEDALUS_MAX_BITSTREAM is derived from the same #define). All allocations (kernel kmalloc / kmemdup, daemon read buffer, vb2 plane backing) are dynamic and sized per-payload at runtime, so the only growth is the daemon's startup read buffer (one ~1 MiB allocation per daemon process) and the V4L2 OUTPUT_MPLANE per-buffer size. KMALLOC_MAX_SIZE on aarch64 SLUB is several MiB; 1 MiB is well within bounds. Other V4L2 stateless decoders (cedrus, rkvdec, hantro) report 1-4 MiB OUTPUT_MPLANE sizeimage — this puts daedalus at the conservative end of normal. ## Compatibility #define-only change; struct layout unchanged. But the effective cap is the smaller of (kernel cap, daemon cap), so: - new daemon + stale kernel: still capped at 64 KiB until the kernel module rebuilds. - new kernel + stale daemon: same. Lock-step install of daedalus-v4l2 + daedalus-v4l2-dkms is therefore required for the fix to take effect; mirrors the PR-#7/#8 cadence. ## NOT changed in this commit - daedalus_fill_output_fmt still hardcodes sizeimage = DAEDALUS_MAX_BITSTREAM regardless of userspace request. Acceptable: vb2 will allocate up to that, and libva's resize- test now sees the kernel report a sizeimage at-least-as-large as what it asked for (147456 < 1048524). A future cleanup could respect userspace's S_FMT.sizeimage clamped to the cap, to save memory on tiny streams. - chardev kmalloc → kvmalloc swap (only matters above KMALLOC_MAX_SIZE, not here). Refs #19. --- include/daedalus_v4l2_proto.h | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/include/daedalus_v4l2_proto.h b/include/daedalus_v4l2_proto.h index 04e2dc2..c437e60 100644 --- a/include/daedalus_v4l2_proto.h +++ b/include/daedalus_v4l2_proto.h @@ -71,7 +71,18 @@ struct daedalus_msg_hdr { __u32 reserved; }; -#define DAEDALUS_PROTO_MAX_PAYLOAD (64u * 1024u) /* 64 KiB */ +/* + * Wire-protocol payload cap. Sized to comfortably hold real-world + * H.264 / VP9 / AV1 access-unit bitstreams: + * - 720p H.264 worst-case I-frame: ~200 KiB + * - 1080p H.264 worst-case I-frame: ~500 KiB + * - 4K H.264 worst-case I-frame: ~2 MiB (would need a bump) + * 1 MiB is the conservative end of what cedrus / rkvdec / hantro + * report as OUTPUT_MPLANE sizeimage. Allocations (chardev kmalloc + * / kmemdup, daemon read buffer, vb2 plane backing) are sized per- + * payload at runtime; this only sets the ceiling. Issue #19. + */ +#define DAEDALUS_PROTO_MAX_PAYLOAD (1024u * 1024u) /* 1 MiB */ /* -- REQ_DECODE / RESP_FRAME payload structures ---------------------- */