This is what was actually broken — and it's much smaller than the STUDY
guessed.
The library is in fact multiplanar-aware throughout the v4l2.c helpers
(v4l2_setup_format, v4l2_get_format, v4l2_query_buffer, v4l2_queue_buffer,
v4l2_dequeue_buffer all branch on v4l2_type_is_mplane). The whole
"context.c / picture.c are single-plane" hypothesis from STUDY.md was wrong —
they derive output_type and capture_type from
video_format->v4l2_mplane and pass them through.
The bug is upstream of all that: driver_data->video_format is set in
RequestCreateSurfaces only, and the probe there only tries
V4L2_BUF_TYPE_VIDEO_CAPTURE (single-plane). On hantro the single-plane
ENUM_FMT returns nothing, video_format stays NULL, and every subsequent
operation hits the `if (video_format == NULL) return OPERATION_FAILED`
guard at the top of context.c / buffer.c / image.c. That's exactly what
Brave's vaCreateContext failure was — not a downstream multiplanar fault,
just the format-detection short-circuit firing.
Three small changes:
- src/video.c: add an NV12 multi-plane entry next to the existing
single-plane NV12 / Sunxi entries. Same pixelformat fourcc (S264 vs NV12
has nothing to do with mplane), distinguished by the v4l2_mplane bit.
- src/video.h + src/video.c: video_format_find() takes a `bool mplane`
parameter and matches both fields. Without this the single-plane and
multi-plane NV12 entries collide on pixelformat.
- src/surface.c: the probe block now tries V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE
as a fallback after the single-plane probes return nothing. On a
single-plane decoder the mplane probe is a no-op; on hantro it picks
the new mplane NV12 entry, video_format gets set, and the rest of the
library — already mplane-aware — does the right thing for OUTPUT
S_FMT, REQBUFS, EXPBUF, QBUF, DQBUF.
Also: src/context.c: the H264 case still referenced V4L2_PIX_FMT_H264_SLICE_RAW
that we renamed in commit c1f5108. Caught now.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
test0r
53999cd154