ffmpeg-v4l2-request-fourier: patch NV15 to P010 unpack for Hi10P / Main10 #26

Merged
marfrit merged 1 commits from claude-noether/marfrit-packages:noether/ffmpeg-v4l2-request-fourier-nv15-p010 into main 2026-05-18 08:52:50 +00:00
Contributor

Fixes marfrit/marfrit-packages#21.

Root cause

The issue's premise (rebase onto Kwiboo's v4l2request-2024-v2-rkvdec for Hi10P/Main10 userspace plumbing) turned out to be inverted. The n8.1 pin (b57fbbe50c) is the newer Karlman rewrite and already carries all the bit-depth-aware plumbing the gist used to ship separately. The actual gap was in v4l2request_transfer_get_formats (hwcontext_v4l2request.c:1076), which deliberately blanks the format list for AV_PIX_FMT_YUV420P10 sw_format. Consequence: kernel-side decode succeeds (Using CAPTURE buffer format NV15, "2 frames decoded; 0 decode errors") but hwdownload rejects the surface at filter-init with -22 EINVAL because no transfer format is exposed.

Fix

0002-nv15-to-p010-unpack.patch against v4l2-request-n8.1:

  1. Inline NV15→P010 unpack in v4l2request_transfer_data_from (5 bytes per 4 samples LE → high-10-of-16 P010 layout, both luma and chroma planes).
  2. Exposes AV_PIX_FMT_P010 in transfer_get_formats when sw_format is YUV420P10.
  3. Explicit ENOSYS for non-P010 destinations instead of silently corrupting output via av_frame_copy on NV15-packed bytes (Phase 5 review hardening).

Other "needs custom unpack" sw_formats (YUV420P / Allwinner NV12_32L32 tiled, YUV422P10 / rkvdec NV20) keep the original ENOSYS path — separate follow-up.

Verification (fresnel, RK3399, linux-fresnel-fourier 7.0-14)

Test Result
Issue #21 smoke test (5 frames) exit 0, 13.8 MB written (correct P010 size)
20-frame mid-fixture Hi10P, HW vs SW reference bit-exact match, sha 7d9b66d48d8f17b2281da1881c663ecc31722bb218aba1ae23bf28d07aa66b08
8-bit H.264 baseline (NV12 path) still bit-exact HW==SW, no regression
pre-patch reproducer on ampere (RK3588, pkgrel=4) confirmed identical -22 EINVAL, cross-device

The bit-exact 20-frame result also overturns the existing feedback_rk3399_h264_hi10p_advertised_not_functional memory entry (the original "all-zero" was actually the 5-frame fadein title card). RK3399 rkvdec Hi10P is functional, contrary to the prior phase 7 close.

Upstream

This patch is a clean candidate for sending to Kwiboo's v4l2-request-n8.1 branch.

🤖 Generated with Claude Code

Fixes marfrit/marfrit-packages#21. ## Root cause The issue's premise (rebase onto Kwiboo's `v4l2request-2024-v2-rkvdec` for Hi10P/Main10 userspace plumbing) turned out to be inverted. The n8.1 pin (`b57fbbe50c`) is the **newer** Karlman rewrite and already carries all the bit-depth-aware plumbing the gist used to ship separately. The actual gap was in `v4l2request_transfer_get_formats` (`hwcontext_v4l2request.c:1076`), which deliberately blanks the format list for `AV_PIX_FMT_YUV420P10` sw_format. Consequence: kernel-side decode succeeds (`Using CAPTURE buffer format NV15`, "2 frames decoded; 0 decode errors") but `hwdownload` rejects the surface at filter-init with -22 EINVAL because no transfer format is exposed. ## Fix `0002-nv15-to-p010-unpack.patch` against `v4l2-request-n8.1`: 1. Inline NV15→P010 unpack in `v4l2request_transfer_data_from` (5 bytes per 4 samples LE → high-10-of-16 P010 layout, both luma and chroma planes). 2. Exposes `AV_PIX_FMT_P010` in `transfer_get_formats` when sw_format is `YUV420P10`. 3. Explicit `ENOSYS` for non-P010 destinations instead of silently corrupting output via `av_frame_copy` on NV15-packed bytes (Phase 5 review hardening). Other "needs custom unpack" sw_formats (`YUV420P` / Allwinner `NV12_32L32` tiled, `YUV422P10` / rkvdec `NV20`) keep the original ENOSYS path — separate follow-up. ## Verification (fresnel, RK3399, `linux-fresnel-fourier 7.0-14`) | Test | Result | |---|---| | Issue #21 smoke test (5 frames) | exit 0, 13.8 MB written (correct P010 size) | | 20-frame mid-fixture Hi10P, HW vs SW reference | **bit-exact match**, sha `7d9b66d48d8f17b2281da1881c663ecc31722bb218aba1ae23bf28d07aa66b08` | | 8-bit H.264 baseline (NV12 path) | still bit-exact HW==SW, no regression | | pre-patch reproducer on ampere (RK3588, pkgrel=4) | confirmed identical -22 EINVAL, cross-device | The bit-exact 20-frame result also overturns the existing `feedback_rk3399_h264_hi10p_advertised_not_functional` memory entry (the original "all-zero" was actually the 5-frame fadein title card). RK3399 rkvdec Hi10P **is** functional, contrary to the prior phase 7 close. ## Upstream This patch is a clean candidate for sending to Kwiboo's `v4l2-request-n8.1` branch. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
claude-noether added 1 commit 2026-05-18 08:36:56 +00:00
The n8.1 pin's hwcontext_v4l2request.c deliberately blanks the
transfer-formats list for AV_PIX_FMT_YUV420P10 sw_format (the mapping
target for V4L2_PIX_FMT_NV15), so `ffmpeg -hwaccel v4l2request
-vf hwdownload,format=p010le` on a Hi10P / Main10 input failed at
filter-init with -22 EINVAL — even though kernel-side decode succeeded.

0002-nv15-to-p010-unpack.patch adds an inline NV15→P010 unpack
(5 bytes per 4 samples, little-endian → high-10-of-16) inside
v4l2request_transfer_data_from, exposes AV_PIX_FMT_P010 in
transfer_get_formats for that sw_format, and rejects non-P010
destinations explicitly with ENOSYS instead of silently corrupting
output via av_frame_copy on NV15-packed bytes.

Verified on fresnel (RK3399, linux-fresnel-fourier 7.0-14):
- 5-frame smoke test from issue #21 → exit 0, 13.8MB output
- 20-frame mid-fixture decode → bit-exact HW==SW
  sha256 7d9b66d48d8f17b2281da1881c663ecc31722bb218aba1ae23bf28d07aa66b08
- 8-bit baseline (bbb_60s_720p.h264.mp4) still bit-exact HW==SW (no
  regression in the existing NV12 path)
- Cross-device repro of original EINVAL on unpatched ampere (RK3588)
  pkgrel=4, confirming the bug is upstream-FFmpeg-side, not RK3399-specific

Patch is upstream-able to Kwiboo's v4l2-request-n8.1 branch.

Closes #21.
marfrit merged commit 7542989f2b into main 2026-05-18 08:52:50 +00:00
marfrit deleted branch noether/ffmpeg-v4l2-request-fourier-nv15-p010 2026-05-18 08:52:51 +00:00
Sign in to join this conversation.
No Reviewers
No Label
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: marfrit/marfrit-packages#26