2 Commits

Author	SHA1	Message	Date
claude-noether	3ffa9d0d17	iter40: Pi 5 HEVC chapter — backend integration lands, bit-exact pending ... Phase 6 implementation. Backend builds clean on higgs (Debian 13 trixie, aarch64), vainfo lists VAProfileHEVCMain via rpi-hevc-dec, multi-device probe finds /dev/video19 + /dev/media1, CreateContext + S_FMT + REQBUFS + STREAMON all succeed. Phase 7 partial: infrastructure works, 10 frames flow through the pipeline (correct byte counts produced — 13824000 for 1280x720 x 10 NV12 frames). But every DQBUF CAPTURE returns V4L2_BUF_FLAG_ERROR so output content is wrong (libva sha != kdirect sha). The decode itself is failing on the rpi-hevc-dec side despite all ctrl submissions returning success. Code changes: - request.h: video_fd_rpi_hevc_dec / media_fd_rpi_hevc_dec slots + has_hevc_ext_sps_rps_rpi_hevc_dec flag (mirrors iter38 + iter2 pair-of-flags pattern, naturally false on Pi). - request.c: known_decoder_drivers gains rpi-hevc-dec; primary-driver probe gets an else-if branch setting the new fds (Phase 5 F3); request_switch_device_for_profile prefers 'p' for HEVC when rpi-hevc-dec present. - context.c: per-fd want_pixfmt (NC12 on Pi), capture_pixelformat taken from video_format slot (not hardcoded NV12/NV15); synthetic-SPS pre-seed gated off for Pi (Phase 5 F6); destination_sizes uses nv12_col128_uv_plane_offset for NC12 SAND layout (Phase 5 F2); per-driver HEVC_START_CODE (NONE on Pi, ANNEX_B on RK); per-driver context_object->h264_start_code (skip prepend on Pi). - video.c: NV12_COL128 video_format entry (8-bit SAND, single buffer, 2 planes, NV12 drm_format with MOD_NONE so detile branch fires rather than tiled_to_planar). - nv12_col128.c/.h: detile primitive (Y + UV per-plane, kernel hevc_d_video.c bytesperline formula + ffmpeg/Kynesim per-pixel offset). UV plane offset = 128 * ALIGN(h, 8) — within-column (SAND interleaves Y+UV per column, NOT plane-concatenated; earlier wrong formula caught by Phase 7 SEGV). - image.c: #ifdef __arm__ extended to __arm__ || __aarch64__ (Phase 5 F1 — guard was killing detile path on all aarch64 hosts including fresnel iter39 NV15 path, masked because 10-bit never exercised); RequestCreateImage NC12 → NV12 stride override (linear width, not column-stride); copy_surface_to_image NC12 detile branch (gates on fourcc + v4l2_format). - nv15.h: fallback V4L2_PIX_FMT_NV15 define (Debian 13 headers omit it though they have NC12). - nv12_col128.h: fallback V4L2_PIX_FMT_NV12_COL128 + V4L2_PIX_FMT_NV12_10_COL128 (Arch / mainline pre-Pi headers). - tests/test_nv12_col128_detile.c: hand-crafted-bytes unit test; passes (8 cases: Y + UV for 4 widths incl. 1366 misaligned; UV-offset helper). - meson.build / nv12_col128 sources listed. Phase 7 status: not yet bit-exact. Remaining diagnosis: per-frame S_EXT_CTRLS payload diff vs kdirect (kdirect sends 4 ctrls SPS+PPS+decode_params+slice_array; ours sends 5 incl. scaling_matrix; field ordering differs). Likely the slice_array contents need per-driver handling for rpi-hevc-dec's expected layout. Beyond in-session reach. iter38 5/5 baseline on fresnel + ampere should be unaffected (new fd stays -1 on non-Pi hosts; all gates either short-circuit on fd-not-present or no-op). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-05-17 19:17:14 +00:00
claude-noether	662f8874ba	iter39 α-31: H264 Hi10P + HEVC Main10 sub-profile support (10-bit, rkvdec NV15) ... Adds VAProfileH264High10 and VAProfileHEVCMain10 to the libva-v4l2-request backend. RK3399 rkvdec emits decoded frames as V4L2_PIX_FMT_NV15 (4 × 10-bit values packed in 5 bytes per element); VAAPI consumers receive standard VA_FOURCC_P010 via a new userspace unpack in copy_surface_to_image. VP9 Profile 2 explicitly NOT added — RK3399 rkvdec kernel ctrl table caps at V4L2_MPEG_VIDEO_VP9_PROFILE_0 (rkvdec.c::rkvdec_vp9_ctrl_descs). Touchpoints (per Phase 5 sonnet-architect review amendments): - include/drm_fourcc.h: define DRM_FORMAT_NV15 (vendored libdrm lacks it) - src/nv15.{c,h}: NV15 → P010 plane unpack (LSB-first, per Documentation/userspace-api/media/v4l/pixfmt-nv15.rst) - src/video.c: NV15 entry in formats[] (else NULL-deref on video_format_find) - src/codec.c: pixelformat_for_profile cases for Hi10P + Main10 - src/config.c: enumeration, validation, entrypoints, RT_FORMAT_YUV420_10 advertisement for 10-bit profiles - src/context.c: per-profile CAPTURE pix_fmt (NV12/NV15), 10-bit synthetic SPS (bit_depth_luma_minus8=2), video_format invalidation on bit-depth transition (sibling to iter38 device-switch invalidation), is_10bit flag - src/surface.c: RT_FORMAT_YUV420_10 admission, NV15 fourcc on PRIME export - src/image.c: P010 reporting in DeriveImage + QueryImageFormats, P010-aware sizing in CreateImage, NV15 → P010 unpack call in copy_surface_to_image (gated on is_10bit + image.format.fourcc == P010) - src/picture.c: 4 switch blocks route Hi10P/Main10 to existing H264/HEVC per-codec paths - src/request.h: MAX_PROFILES bump 11 → 13, driver_data->is_10bit flag Scope: COPY path (vaGetImage / vaDeriveImage) only. Standard ffmpeg-vaapi hwdownload, mpv vaapi-copy, and any consumer using vaGetImage works end-to-end. PRIME-path consumers that only know NV12/P010 must use the COPY path; PRIME consumers aware of NV15 (panfrost-Mesa et al.) get the correct fourcc on RequestExportSurfaceHandle. PRIME-side P010 emission is follow-up scope (would need DRM_FORMAT_P010 + per-plane unpack into a GPU-accessible buffer). Compile-tested on boltzmann (aarch64 native, gcc 15.2.1, libva 1.23.0, libdrm 2.4.133): clean build, .so produced, 0 new warnings. Phase 0/2 evidence: linux-mmind-v7.0 drivers/media/platform/rockchip/rkvdec. rkvdec_h264_decoded_fmts[] and rkvdec_hevc_decoded_fmts[] both list NV15; ctrl tables cap at HEVC MAIN_10 and H264 HIGH_422_INTRA (Hi10P < cap, not in menu_skip_mask). image_fmt resolution (rkvdec-h264-common.c:196, rkvdec-hevc-common.c:467) dispatches on bit_depth_luma_minus8 only. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>	2026-05-17 09:15:16 +00:00