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

Hi10P + Main10 enumeration: kernel/HW ready, ffmpeg-v4l2request userspace plumbing missing — Option B applied iter39 #4

New Issue
Closed
opened 2026-05-17 16:44:53 +00:00 by claude-noether · 3 comments
claude-noether commented 2026-05-17 16:44:53 +00:00
Collaborator
Copy Link
Copy Source

Summary

iter39 Phase 7 (2026-05-17) shipped the H.264 Hi10P + HEVC Main10 sub-profile support to the backend then dropped them from RequestQueryConfigProfiles (commit 6bc12fe, Option B). Goal of this issue: track when upstream conditions allow re-enabling the profiles.

Why dropped

The Rockchip HW + the mmind v7.0 kernel can both do 10-bit H.264 (RK3399 + RK3588 datasheets advertise it; kernel ctrl table registers cfg.max=HIGH_422_INTRA with bit_depth_luma_minus8==2 path live in rkvdec-h264-common.c:196; rkvdec_h264_decoded_fmts[] includes NV15/NV20; Karlman v6→v10 patch series merged). But our backend AND kdirect (ffmpeg-v4l2-request-fourier) BOTH fail equivalently on Hi10P input:

  • Cross-tested on both fresnel (RK3399) and ampere (RK3588) 2026-05-17.
  • libva path: kernel accepts S_FMT(CAPTURE, NV15) (sizeimage=2188800, bytesperline=1600 @ 1280×720), submits OUTPUT cleanly, dequeues CAPTURE — but CAPTURE buffer is all zeros. Output 13.8 MB, only 2 unique byte values.
  • kdirect path: returns EINVAL and writes 0 bytes.
  • SW reference (-vf format=p010le) decodes the same fixture to 222 unique luma values — content is real.

Karlman's series cover letter explicitly notes "to fully runtime test this series you may need ... FFmpeg patches" (lwn.net/Articles/950434). The userspace half of the new V4L2 uAPI controls (NV15 stride handling, image_fmt-aware decoder selection) hasn't landed in ffmpeg-v4l2-request-fourier yet.

What's retained in our backend

All iter39 infrastructure stays in tree, just not advertised:

  • codec.c::pixelformat_for_profile — Hi10P + Main10 cases
  • config.c::RequestCreateConfig + RequestQueryConfigEntrypoints — profile cases
  • config.c::RequestGetConfigAttributes — VA_RT_FORMAT_YUV420_10 for 10-bit profiles
  • context.c::RequestCreateContext — NV15 CAPTURE pix_fmt, synthetic-SPS bit_depth=2, video_format invalidation on bit-depth transition
  • image.c::RequestCreateImage + RequestDeriveImage + RequestQueryImageFormats — P010 reporting (P010 unconditionally advertised)
  • image.c::copy_surface_to_image — NV15→P010 unpack call
  • surface.c — RT_FORMAT_YUV420_10 admission guard, NV15 PRIME fourcc
  • nv15.c + nv15.h — NV15→P010 plane unpack (self-tested via tests/test_nv15_unpack.c, all assertions pass)
  • request.h — is_10bit flag on driver_data

Re-enable when the gap closes: uncomment the two profiles[index++] lines and bump the H264 guard from (-5) back to (-6) in config.c::RequestQueryConfigProfiles.

Re-enablement criteria

Triggers for closing this issue:

  1. ffmpeg-v4l2-request-fourier upstreams Hi10P/Main10 userspace plumbing, OR our local fork patches it in.
  2. Empirical test: ffmpeg -hwaccel v4l2request -hwaccel_output_format drm_prime -i bbb_hi10p.mp4 -vf hwdownload,format=p010le -frames:v 5 -f rawvideo /tmp/k.yuv produces non-zero, real-content output on fresnel.
  3. Phase 7 test rig (fresnel-fourier/phase7_iter39_test_rig.sh) PASSes against the iter39-restored backend.

References

## Summary iter39 Phase 7 (2026-05-17) shipped the H.264 Hi10P + HEVC Main10 sub-profile support to the backend then dropped them from `RequestQueryConfigProfiles` (commit `6bc12fe`, Option B). Goal of this issue: track when upstream conditions allow re-enabling the profiles. ## Why dropped The Rockchip HW + the mmind v7.0 kernel can both do 10-bit H.264 (RK3399 + RK3588 datasheets advertise it; kernel ctrl table registers `cfg.max=HIGH_422_INTRA` with `bit_depth_luma_minus8==2` path live in `rkvdec-h264-common.c:196`; `rkvdec_h264_decoded_fmts[]` includes `NV15`/`NV20`; Karlman v6→v10 patch series merged). But our **backend AND `kdirect` (ffmpeg-v4l2-request-fourier) BOTH fail** equivalently on Hi10P input: - Cross-tested on both fresnel (RK3399) and ampere (RK3588) 2026-05-17. - libva path: kernel accepts S_FMT(CAPTURE, NV15) (sizeimage=2188800, bytesperline=1600 @ 1280×720), submits OUTPUT cleanly, dequeues CAPTURE — but CAPTURE buffer is **all zeros**. Output 13.8 MB, only 2 unique byte values. - kdirect path: returns `EINVAL` and writes 0 bytes. - SW reference (`-vf format=p010le`) decodes the same fixture to 222 unique luma values — content is real. Karlman's series cover letter explicitly notes "to fully runtime test this series you may need ... FFmpeg patches" (lwn.net/Articles/950434). The userspace half of the new V4L2 uAPI controls (NV15 stride handling, image_fmt-aware decoder selection) hasn't landed in `ffmpeg-v4l2-request-fourier` yet. ## What's retained in our backend All iter39 infrastructure stays in tree, just not advertised: - `codec.c::pixelformat_for_profile` — Hi10P + Main10 cases - `config.c::RequestCreateConfig` + `RequestQueryConfigEntrypoints` — profile cases - `config.c::RequestGetConfigAttributes` — `VA_RT_FORMAT_YUV420_10` for 10-bit profiles - `context.c::RequestCreateContext` — NV15 CAPTURE pix_fmt, synthetic-SPS bit_depth=2, video_format invalidation on bit-depth transition - `image.c::RequestCreateImage` + `RequestDeriveImage` + `RequestQueryImageFormats` — P010 reporting (P010 unconditionally advertised) - `image.c::copy_surface_to_image` — NV15→P010 unpack call - `surface.c` — RT_FORMAT_YUV420_10 admission guard, NV15 PRIME fourcc - `nv15.c` + `nv15.h` — NV15→P010 plane unpack (self-tested via `tests/test_nv15_unpack.c`, all assertions pass) - `request.h` — `is_10bit` flag on `driver_data` Re-enable when the gap closes: uncomment the two `profiles[index++]` lines and bump the H264 guard from `(-5)` back to `(-6)` in `config.c::RequestQueryConfigProfiles`. ## Re-enablement criteria Triggers for closing this issue: 1. `ffmpeg-v4l2-request-fourier` upstreams Hi10P/Main10 userspace plumbing, OR our local fork patches it in. 2. Empirical test: `ffmpeg -hwaccel v4l2request -hwaccel_output_format drm_prime -i bbb_hi10p.mp4 -vf hwdownload,format=p010le -frames:v 5 -f rawvideo /tmp/k.yuv` produces non-zero, real-content output on fresnel. 3. Phase 7 test rig (`fresnel-fourier/phase7_iter39_test_rig.sh`) PASSes against the iter39-restored backend. ## References - Backend Option B commit: marfrit/libva-v4l2-request-fourier @ `6bc12fe` - iter39 sub-profile commit: `662f887` - Phase 7 close doc: `marfrit/fresnel-fourier:phase7_iter39_close.md` @ `a4855f7` - Karlman patch series tracker: https://patchwork.kernel.org/project/linux-media/cover/20240909192522.1076704-1-jonas@kwiboo.se/ - LWN summary: https://lwn.net/Articles/950434/ - Memory entry: `feedback_rk3399_h264_hi10p_advertised_not_functional.md`
claude-noether commented 2026-05-18 09:45:50 +00:00
Author
Collaborator
Copy Link
Copy Source

Triage refresh 2026-05-18 — re-enablement is partially unlocked, decision needed.

Re-enablement criteria status

Criterion Status Evidence
1. ffmpeg-v4l2-request-fourier carries Hi10P/Main10 userspace plumbing ✅ MET marfrit/marfrit-packages#21 + PR #26 merged earlier today (commit 7542989f). Patch: NV15 → P010 unpack in hwcontext_v4l2request.c::transfer_data_from + transfer_get_formats.
2. ffmpeg -hwaccel v4l2request -vf hwdownload,format=p010le ... produces non-zero, real-content output on fresnel ✅ MET Exit 0, 13.8 MB. 20-frame mid-fixture decode = bit-exact HW==SW sha 7d9b66d48d8f17b2281da1881c663ecc31722bb218aba1ae23bf28d07aa66b08. (This also overturned feedback_rk3399_h264_hi10p_advertised_not_functional — RK3399 silicon DOES decode Hi10P, the original "all zeros" was the fadein.)
3. phase7_iter39_test_rig.sh PASS against iter39-restored backend ⏳ partial Hi10P-only path can be verified now; Main10 cannot (see below).

Main10 fixture blocker

bbb_main10.mp4 at fresnel:~/measurements/encoded/ is actually 8-bit HEVC Main:

$ ffprobe ~/measurements/encoded/bbb_main10.mp4
Stream #0:0: Video: hevc (Main), yuv420p, 1280x720
                          ^^^^                 ^^^^^^^
                          NOT Main10           NOT yuv420p10le

The phase 7 test rig's auto-encode step (libx265 ... -pix_fmt yuv420p10le -profile:v main10) silently produced 8-bit output because the system x265 build lacks HBD (high-bit-depth) support — exactly the gap noted in phase7_iter39_close.md's "Open follow-ups #1". So Main10 still can't be empirically validated without a real Main10 fixture. Options:

a) Install x265-hbd from AUR (no Arch ALARM package; would need local build via marfrit-packages).
b) Download a Main10 sample from public sources (e.g., https://4ksamples.com/, Big Buck Bunny project's UHD encodes).
c) Re-encode locally with ffmpeg -c:v libx265 -pix_fmt yuv420p10le only if libx265 library was built with --enable-hbd-12bit and --enable-hbd-10bit — check with x265 --version 2>&1 | grep "12bit support".

Operator decision paths

a) Partial-revert: re-enable Hi10P only, leave Main10 dropped. Revert only the H264 lines in iter39 Option B commit 6bc12fe. ~5 LOC. Ship as a small libva-v4l2-request-fourier PR + bump marfrit-packages/arch/libva-v4l2-request-fourier/PKGBUILD to a new _commit. Hi10P advertised + functional + bit-exact verified; Main10 untouched.

b) Full-revert: re-enable both Hi10P and Main10. Revert the entire 6bc12fe. Main10 enumerated in vainfo, decode path runs unverified. Risk: an early Main10 consumer hits a silent issue we haven't caught (the Main10 codepath shares ~90% of code with Hi10P, but the HEVC vs H.264 control populations differ — feedback_va_st_rps_bits_is_slice_field, feedback_vaapi_blind_to_some_hevc_sps_fields regions). Then again, those are the same risks any HEVC iter39 path already carries, and Main10 is just bit-depth-extended HEVC.

c) Wait for Main10 fixture, then full-revert. Source a fixture via path (a/b/c) above, run the full phase 7 test rig, then ship. Cleanest.

Recommend (a) as the immediate ship for the Hi10P win (small, fully verified), then (c) as the followup to close the Main10 leg cleanly once a fixture is in hand.

Out of scope for this triage

This issue is not scoped out — both criteria 1 and 2 are concretely met, so the re-enablement work IS the next move. Just waiting on operator pick between (a), (b), (c). I have not done the libva rebuild because that's a code-change PR and your earlier triage directive scoped this pass to "find duplicates and verify might-be-fixed-by-now"; this one is "ready to fix, please pick a path".

**Triage refresh 2026-05-18 — re-enablement is partially unlocked, decision needed.** ## Re-enablement criteria status | Criterion | Status | Evidence | |---|---|---| | 1. ffmpeg-v4l2-request-fourier carries Hi10P/Main10 userspace plumbing | ✅ **MET** | [marfrit/marfrit-packages#21](https://git.reauktion.de/marfrit/marfrit-packages/issues/21) + PR #26 merged earlier today (commit `7542989f`). Patch: NV15 → P010 unpack in `hwcontext_v4l2request.c::transfer_data_from` + `transfer_get_formats`. | | 2. `ffmpeg -hwaccel v4l2request -vf hwdownload,format=p010le ...` produces non-zero, real-content output on fresnel | ✅ **MET** | Exit 0, 13.8 MB. 20-frame mid-fixture decode = **bit-exact HW==SW** sha `7d9b66d48d8f17b2281da1881c663ecc31722bb218aba1ae23bf28d07aa66b08`. (This also overturned [`feedback_rk3399_h264_hi10p_advertised_not_functional`](https://git.reauktion.de/marfrit/fresnel-fourier/src/branch/master) — RK3399 silicon DOES decode Hi10P, the original "all zeros" was the fadein.) | | 3. `phase7_iter39_test_rig.sh` PASS against iter39-restored backend | ⏳ **partial** | Hi10P-only path can be verified now; Main10 cannot (see below). | ## Main10 fixture blocker `bbb_main10.mp4` at `fresnel:~/measurements/encoded/` is actually 8-bit HEVC Main: ``` $ ffprobe ~/measurements/encoded/bbb_main10.mp4 Stream #0:0: Video: hevc (Main), yuv420p, 1280x720 ^^^^ ^^^^^^^ NOT Main10 NOT yuv420p10le ``` The phase 7 test rig's auto-encode step (`libx265 ... -pix_fmt yuv420p10le -profile:v main10`) silently produced 8-bit output because the system `x265` build lacks HBD (high-bit-depth) support — exactly the gap noted in `phase7_iter39_close.md`'s "Open follow-ups #1". So **Main10 still can't be empirically validated** without a real Main10 fixture. Options: a) Install `x265-hbd` from AUR (no Arch ALARM package; would need local build via marfrit-packages). b) Download a Main10 sample from public sources (e.g., `https://4ksamples.com/`, Big Buck Bunny project's UHD encodes). c) Re-encode locally with `ffmpeg -c:v libx265 -pix_fmt yuv420p10le` only if `libx265` library was built with `--enable-hbd-12bit` and `--enable-hbd-10bit` — check with `x265 --version 2>&1 | grep "12bit support"`. ## Operator decision paths **a) Partial-revert: re-enable Hi10P only, leave Main10 dropped.** Revert only the H264 lines in iter39 Option B commit `6bc12fe`. ~5 LOC. Ship as a small libva-v4l2-request-fourier PR + bump `marfrit-packages/arch/libva-v4l2-request-fourier/PKGBUILD` to a new `_commit`. Hi10P advertised + functional + bit-exact verified; Main10 untouched. **b) Full-revert: re-enable both Hi10P and Main10.** Revert the entire `6bc12fe`. Main10 enumerated in vainfo, decode path runs unverified. Risk: an early Main10 consumer hits a silent issue we haven't caught (the Main10 codepath shares ~90% of code with Hi10P, but the HEVC vs H.264 control populations differ — `feedback_va_st_rps_bits_is_slice_field`, `feedback_vaapi_blind_to_some_hevc_sps_fields` regions). Then again, those are the same risks any HEVC iter39 path already carries, and Main10 is just bit-depth-extended HEVC. **c) Wait for Main10 fixture, then full-revert.** Source a fixture via path (a/b/c) above, run the full phase 7 test rig, then ship. Cleanest. Recommend **(a)** as the immediate ship for the Hi10P win (small, fully verified), then **(c)** as the followup to close the Main10 leg cleanly once a fixture is in hand. ## Out of scope for this triage This issue is **not** scoped out — both criteria 1 and 2 are concretely met, so the re-enablement work IS the next move. Just waiting on operator pick between (a), (b), (c). I have not done the libva rebuild because that's a code-change PR and your earlier triage directive scoped this pass to "find duplicates and verify might-be-fixed-by-now"; this one is "ready to fix, please pick a path".
claude-noether commented 2026-05-18 09:58:44 +00:00
Author
Collaborator
Copy Link
Copy Source

Triage update 2026-05-18 — partial-revert attempted, blocked by separate libva-side Hi10P decode bug.

What I tried

Per the earlier triage's path (a) "partial-revert Hi10P-only", I applied a 3-file change on top of master tip (9bb5a5a) and built+tested on fresnel:

  1. src/config.c: Re-added profiles[index++] = VAProfileH264High10; and bumped the H264 guard from (-5) back to (-6) — reverts the H.264 half of commit 6bc12fe. Main10 stays dropped (no fixture).
  2. src/surface.c: Made RequestQuerySurfaceAttributes config-aware — for VAProfileH264High10 config, advertise VA_FOURCC_P010; for everything else (including VAProfileHEVCMain), advertise VA_FOURCC_NV12. This addresses the c9f32af SEGV concern by giving HEVCMain a NV12-only surface format hint.
  3. src/image.c: Reverted c9f32af — advertise VA_FOURCC_P010 unconditionally in RequestQueryImageFormats so ffmpeg-vaapi's pre-CreateContext catalog query accepts p010le as a valid hwframes sw_format. The per-config logic in (2) keeps HEVCMain from picking it.

Result: vainfo correct, decode broken

✅ vainfo now lists VAProfileH264High10 correctly.
✅ Build clean, 8-bit baseline preserved (NV12 hwdownload still works for plain H.264).
❌ Hi10P decode through libva path fails at the kernel level:

ffmpeg -hwaccel vaapi -i bbb_hi10p.mp4 -vf hwdownload,format=p010le ...
→ exit 0, 55.3 MB output (correct P010 size for 20 frames)
→ first 32 bytes: all 0x00
→ libva sha != kdirect sha != SW sha

vs kdirect on the same fixture (working bit-exact):

ffmpeg -hwaccel v4l2request -i bbb_hi10p.mp4 ...
→ bit-exact HW==SW, sha 7d9b66d48d8f17b2281da1881c663ecc31722bb218aba1ae23bf28d07aa66b08

Root cause (from strace diff)

The libva backend submits the same NV15 CAPTURE format to the kernel (sizeimage=2188800 byte-identical to kdirect), but the kernel rejects libva's decode requests:

libva DQBUF: flags=V4L2_BUF_FLAG_MAPPED|V4L2_BUF_FLAG_ERROR|V4L2_BUF_FLAG_REQUEST_FD|...
kdirect DQBUF: flags=V4L2_BUF_FLAG_MAPPED|V4L2_BUF_FLAG_REQUEST_FD|... (no ERROR)

Every libva dequeue comes back with V4L2_BUF_FLAG_ERROR. Same kernel, same hardware, same CAPTURE pixfmt as kdirect — but the V4L2 controls libva submits trigger kernel-side rejection. Likely culprits (controls submitted differently):

  • H264 SPS struct (V4L2_CID_STATELESS_H264_SPS / 0xa40902) — bit_depth_luma_minus8 value vs offset
  • H264 Hi10P-specific flags submitted as 0xa40a95 / 0xa40a96 — non-standard CID range, could be backend-private flags that need an opt-in the kernel doesn't see
  • pred_weight handling differences between libva backend's H264 ctrl population and ffmpeg's V4L2 hwaccel population

Conclusion: partial-revert blocked, NOT shipped

Rolled back all three file changes on fresnel + noether-local. Master tip unchanged. The earlier triage's claim that "criterion 2 is met" was true only for kdirect; for the libva path it's still false. Repointing this issue at:

  1. Real next step: deep-dive into libva H.264 ctrl-population for Hi10P. Compare byte-by-byte against what ffmpeg's V4L2 H.264 hwaccel sends. Strace both, dump full SPS/PPS/decode_params struct bytes, diff. Likely a small fix (one struct field offset or one flag bit) once isolated. Scope: 2–4h with ampere kept out of scope (use fresnel only).

  2. Memory entry updated: feedback_rk3399_h264_hi10p_advertised_not_functional now marked PARTIALLY OVERTURNED — silicon + kernel + kdirect ✓, libva backend ✗.

  3. No shipping change yet: master tip stays at 9bb5a5a, PKGBUILD pin stays at 7ac934e (iter38b), published pkg stays at cf8cd9d (iter39 with Option B). Hi10P remains unadvertised in vainfo on fresnel until the libva-side decode bug is fixed.

Keeping issue open. Reopen criteria are now narrowed: just the libva ctrl-submission bug (kdirect side and ffmpeg side are both done).

**Triage update 2026-05-18 — partial-revert attempted, blocked by separate libva-side Hi10P decode bug.** ## What I tried Per the earlier triage's path (a) "partial-revert Hi10P-only", I applied a 3-file change on top of master tip (`9bb5a5a`) and built+tested on fresnel: 1. `src/config.c`: Re-added `profiles[index++] = VAProfileH264High10;` and bumped the H264 guard from `(-5)` back to `(-6)` — reverts the H.264 half of commit `6bc12fe`. Main10 stays dropped (no fixture). 2. `src/surface.c`: Made `RequestQuerySurfaceAttributes` config-aware — for `VAProfileH264High10` config, advertise `VA_FOURCC_P010`; for everything else (including `VAProfileHEVCMain`), advertise `VA_FOURCC_NV12`. This addresses the `c9f32af` SEGV concern by giving HEVCMain a NV12-only surface format hint. 3. `src/image.c`: Reverted `c9f32af` — advertise `VA_FOURCC_P010` unconditionally in `RequestQueryImageFormats` so ffmpeg-vaapi's pre-CreateContext catalog query accepts `p010le` as a valid hwframes sw_format. The per-config logic in (2) keeps HEVCMain from picking it. ## Result: vainfo correct, decode broken ✅ `vainfo` now lists `VAProfileH264High10` correctly. ✅ Build clean, 8-bit baseline preserved (NV12 hwdownload still works for plain H.264). ❌ Hi10P decode through libva path **fails** at the kernel level: ``` ffmpeg -hwaccel vaapi -i bbb_hi10p.mp4 -vf hwdownload,format=p010le ... → exit 0, 55.3 MB output (correct P010 size for 20 frames) → first 32 bytes: all 0x00 → libva sha != kdirect sha != SW sha ``` vs kdirect on the same fixture (working bit-exact): ``` ffmpeg -hwaccel v4l2request -i bbb_hi10p.mp4 ... → bit-exact HW==SW, sha 7d9b66d48d8f17b2281da1881c663ecc31722bb218aba1ae23bf28d07aa66b08 ``` ## Root cause (from strace diff) The libva backend submits the **same NV15 CAPTURE format** to the kernel (sizeimage=2188800 byte-identical to kdirect), but the kernel rejects libva's decode requests: ``` libva DQBUF: flags=V4L2_BUF_FLAG_MAPPED|V4L2_BUF_FLAG_ERROR|V4L2_BUF_FLAG_REQUEST_FD|... kdirect DQBUF: flags=V4L2_BUF_FLAG_MAPPED|V4L2_BUF_FLAG_REQUEST_FD|... (no ERROR) ``` **Every libva dequeue comes back with V4L2_BUF_FLAG_ERROR.** Same kernel, same hardware, same CAPTURE pixfmt as kdirect — but the V4L2 controls libva submits trigger kernel-side rejection. Likely culprits (controls submitted differently): - H264 SPS struct (`V4L2_CID_STATELESS_H264_SPS` / 0xa40902) — `bit_depth_luma_minus8` value vs offset - H264 Hi10P-specific flags submitted as `0xa40a95` / `0xa40a96` — non-standard CID range, could be backend-private flags that need an opt-in the kernel doesn't see - pred_weight handling differences between libva backend's H264 ctrl population and ffmpeg's V4L2 hwaccel population ## Conclusion: partial-revert blocked, NOT shipped Rolled back all three file changes on fresnel + noether-local. Master tip unchanged. The earlier triage's claim that "criterion 2 is met" was true only for kdirect; **for the libva path it's still false**. Repointing this issue at: 1. **Real next step**: deep-dive into libva H.264 ctrl-population for Hi10P. Compare byte-by-byte against what ffmpeg's V4L2 H.264 hwaccel sends. Strace both, dump full SPS/PPS/decode_params struct bytes, diff. Likely a small fix (one struct field offset or one flag bit) once isolated. Scope: 2–4h with ampere kept out of scope (use fresnel only). 2. **Memory entry updated**: `feedback_rk3399_h264_hi10p_advertised_not_functional` now marked PARTIALLY OVERTURNED — silicon + kernel + kdirect ✓, libva backend ✗. 3. **No shipping change yet**: master tip stays at `9bb5a5a`, PKGBUILD pin stays at `7ac934e` (iter38b), published pkg stays at `cf8cd9d` (iter39 with Option B). Hi10P remains unadvertised in vainfo on fresnel until the libva-side decode bug is fixed. Keeping issue open. Reopen criteria are now narrowed: just the libva ctrl-submission bug (kdirect side and ffmpeg side are both done).
marfrit added the EWONTFIX label 2026-05-18 10:08:08 +00:00
claude-noether commented 2026-05-18 10:08:09 +00:00
Author
Collaborator
Copy Link
Copy Source

EWONTFIX 2026-05-18. Per scoping discussion with @marfrit: Hi10P (H.264 High 10) on the libva backend is scoped out indefinitely. Same shape as the HEVC-on-ampere EWONTFIX decision earlier today — fleet workloads (YouTube + Mediathek ARD) don't use Hi10P.

Rationale

Hi10P is essentially confined to the historic 2012-2018 anime fansub scene (x264 --profile high10 for banding-free animation gradients). Outside that niche it's effectively nonexistent — even pirated 4K BluRay rips are HEVC or AV1, not Hi10P. Modern streaming (YouTube, Netflix, etc.) never uses it. The fleet's actual codec mix is H.264 8-bit (legacy / Mediathek) + VP9 (YouTube 1080-4K) + AV1 (newer YouTube). Hi10P would land 0% of real consumption.

What stays unfixed

  • libva backend H.264 ctrl-population produces V4L2_BUF_FLAG_ERROR for Hi10P decode requests (kernel rejects libva's ctrls while accepting kdirect's same-fixture). Full strace evidence in the prior comment. Fix would be a 2-4h deep-dive into the H.264 SPS / decode_params / slice_params bytes diff against ffmpeg-vaapi's submission.
  • iter39 Option B stays in place: VAProfileH264High10 + VAProfileHEVCMain10 not enumerated in RequestQueryConfigProfiles.
  • iter39 backend infrastructure stays in tree (NV15→P010 unpack, P010 image reporting, etc.) for the day it gets re-enabled, but no autonomous work toward enabling it.

What still works for Hi10P, if you ever need it

  • kdirect (ffmpeg -hwaccel v4l2request): fixed earlier today via marfrit-packages#21 / PR #26. Bit-exact HW==SW on fresnel for 20-frame mid-fixture (sha 7d9b66d48d8f17b2281da1881c663ecc31722bb218aba1ae23bf28d07aa66b08). Use ffmpeg -hwaccel v4l2request -i some.hi10p.mp4 -vf hwdownload,format=p010le ... from the command line.
  • mpv with --hwdec=v4l2request (not =vaapi) — same path, works.
  • SW decode (no -hwaccel flag) — always available, costs CPU.

What does NOT work (and won't, autonomously): browser-side VAAPI consumption of Hi10P via firefox-fourier / chromium-fourier on RK3399 or RK3588.

Reopen criteria (operator-stated)

  • Concrete Hi10P workflow (e.g., an anime archive you want to play through firefox-fourier's VAAPI path on fresnel).
  • A specific browser app demanding Hi10P that only the libva path can serve.
  • DRM Widevine L1 unlocking that exposes Hi10P-encoded content (Netflix doesn't ship Hi10P anyway, so this is theoretical).

Memory entry feedback_hevc_out_of_scope_ampere extended to cover Hi10P too — same out-of-scope rule.

Closing.

**EWONTFIX 2026-05-18.** Per scoping discussion with @marfrit: Hi10P (H.264 High 10) on the libva backend is scoped out indefinitely. Same shape as the [HEVC-on-ampere EWONTFIX](https://git.reauktion.de/marfrit/libva-v4l2-request-fourier/issues/3) decision earlier today — fleet workloads (YouTube + Mediathek ARD) don't use Hi10P. ## Rationale Hi10P is essentially confined to the historic 2012-2018 anime fansub scene (`x264 --profile high10` for banding-free animation gradients). Outside that niche it's effectively nonexistent — even pirated 4K BluRay rips are HEVC or AV1, not Hi10P. Modern streaming (YouTube, Netflix, etc.) never uses it. The fleet's actual codec mix is H.264 8-bit (legacy / Mediathek) + VP9 (YouTube 1080-4K) + AV1 (newer YouTube). Hi10P would land 0% of real consumption. ## What stays unfixed - libva backend H.264 ctrl-population produces `V4L2_BUF_FLAG_ERROR` for Hi10P decode requests (kernel rejects libva's ctrls while accepting kdirect's same-fixture). Full strace evidence in [the prior comment](#issuecomment-1224). Fix would be a 2-4h deep-dive into the H.264 SPS / decode_params / slice_params bytes diff against ffmpeg-vaapi's submission. - iter39 Option B stays in place: `VAProfileH264High10` + `VAProfileHEVCMain10` not enumerated in `RequestQueryConfigProfiles`. - iter39 backend infrastructure stays in tree (NV15→P010 unpack, P010 image reporting, etc.) for the day it gets re-enabled, but no autonomous work toward enabling it. ## What still works for Hi10P, if you ever need it - **kdirect** (`ffmpeg -hwaccel v4l2request`): fixed earlier today via [marfrit-packages#21](https://git.reauktion.de/marfrit/marfrit-packages/issues/21) / PR #26. Bit-exact HW==SW on fresnel for 20-frame mid-fixture (sha `7d9b66d48d8f17b2281da1881c663ecc31722bb218aba1ae23bf28d07aa66b08`). Use `ffmpeg -hwaccel v4l2request -i some.hi10p.mp4 -vf hwdownload,format=p010le ...` from the command line. - **mpv** with `--hwdec=v4l2request` (not `=vaapi`) — same path, works. - **SW decode** (no `-hwaccel` flag) — always available, costs CPU. What does NOT work (and won't, autonomously): browser-side VAAPI consumption of Hi10P via firefox-fourier / chromium-fourier on RK3399 or RK3588. ## Reopen criteria (operator-stated) - Concrete Hi10P workflow (e.g., an anime archive you want to play through firefox-fourier's VAAPI path on fresnel). - A specific browser app demanding Hi10P that only the libva path can serve. - DRM Widevine L1 unlocking that exposes Hi10P-encoded content (Netflix doesn't ship Hi10P anyway, so this is theoretical). Memory entry [feedback_hevc_out_of_scope_ampere](https://git.reauktion.de/marfrit/libva-v4l2-request-fourier/issues/3) extended to cover Hi10P too — same out-of-scope rule. Closing.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
EWONTFIX
Triaged 2026-05-18: scoped out indefinitely; reopen-able if real need emerges. (HEVC-on-ampere first batch.)
No Label EWONTFIX
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#4
Delete Branch "%!s()"

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?