marfrit/kernel-agent
1
0
Fork 1
Code Issues 2 Pull Requests Actions Packages Projects Releases Wiki Activity

rkvdec HEVC: uninitialized run.ext_sps_st_rps/lt_rps causes OOPS on RK3588/RK3576 #14

New Issue
Closed
opened 2026-05-16 10:34:31 +00:00 by marfrit · 3 comments
marfrit commented 2026-05-16 10:34:31 +00:00
Owner
Copy Link
Copy Source

Summary

The Casanova/Collabora v7.0 HEVC EXT_SPS_*_RPS series introduces a stack-uninit bug in rkvdec_hevc_run on vdpu381 (RK3588) and vdpu383 (RK3576). On every HEVC decode where the dispatcher enters the assemble path, prepare_hw_st_rps dereferences a non-NULL stack-garbage pointer and faults.

Repro

  • Host: ampere (CoolPi CM5 GenBook, RK3588), linux-fresnel-fourier-style 7.0-rc3 + mmind v7.0 + Casanova HEVC v7.0 patches.
  • Command: LIBVA_DRIVER_NAME=v4l2_request ffmpeg -hwaccel vaapi -i any.hevc.mp4 -frames:v 3 -f rawvideo /tmp/o.nv12
  • dmesg:
[00000000000051a0] pgd=0, p4d=0
Internal error: Oops: 0000000096000004
pc : __pi_memcmp+0x10/0x110
lr : rkvdec_hevc_prepare_hw_st_rps+0x38/0x300 [rockchip_vdec]
x0 : ffff000119202410   x1 : 00000000000051a0   x2 : 0000000000000048
Call trace:
 __pi_memcmp+0x10/0x110
 rkvdec_hevc_assemble_hw_rps+0x1c
 rkvdec_hevc_run+0x12c
 rkvdec_device_run+0x48
 v4l2_m2m_try_run
 v4l2_m2m_request_queue
 media_request_ioctl_queue
  • 0x51a0 is deterministic stack-leftover for the specific calling pattern — not a ctrl pointer.

Root cause

drivers/media/platform/rockchip/rkvdec/rkvdec-vdpu381-hevc.c:591:

struct rkvdec_hevc_run run;          // uninitialized
rkvdec_hevc_run_preamble(ctx, &run);

drivers/media/platform/rockchip/rkvdec/rkvdec-hevc-common.c:498-508:

if (ctx->has_sps_st_rps) {
    ctrl = v4l2_ctrl_find(..., V4L2_CID_STATELESS_HEVC_EXT_SPS_ST_RPS);
    run->ext_sps_st_rps = ctrl ? ctrl->p_cur.p : NULL;
}
if (ctx->has_sps_lt_rps) {
    ctrl = v4l2_ctrl_find(..., V4L2_CID_STATELESS_HEVC_EXT_SPS_LT_RPS);
    run->ext_sps_lt_rps = ctrl ? ctrl->p_cur.p : NULL;
}

When ctx->has_sps_st_rps is false (the common case: userspace doesnt yet submit the new controls), run->ext_sps_st_rps keeps stack-leftover bytes. Downstream:

drivers/media/platform/rockchip/rkvdec/rkvdec-hevc-common.c:380:

if (!run->ext_sps_st_rps)
    return;                  // garbage 0x51a0 is non-NULL
if (!memcmp(cache, run->ext_sps_st_rps, sizeof(...)))
    return;                  // memcmp derefs 0x51a0 -> OOPS

Fix (one line)

Option A (recommended — fix at the producer):

--- a/drivers/media/platform/rockchip/rkvdec/rkvdec-hevc-common.c
+++ b/drivers/media/platform/rockchip/rkvdec/rkvdec-hevc-common.c
@@ -495,6 +495,9 @@ void rkvdec_hevc_run_preamble(struct rkvdec_ctx *ctx,
         ctrl = v4l2_ctrl_find(&ctx->ctrl_hdl,
                               V4L2_CID_STATELESS_HEVC_SCALING_MATRIX);
         run->scaling_matrix = ctrl ? ctrl->p_cur.p : NULL;
+
+        run->ext_sps_st_rps = NULL;
+        run->ext_sps_lt_rps = NULL;
 
         if (ctx->has_sps_st_rps) {

Option B (defensive — zero-init at caller, applies to both vdpu381 + vdpu383):

-        struct rkvdec_hevc_run run;
+        struct rkvdec_hevc_run run = {};

Scope

  • Affects: vdpu381_variant (RK3588) + vdpu383_variant (RK3576) — both call rkvdec_hevc_run.
  • Original RK3399 path (rkvdec-hevc.c::rkvdec_hevc_run) needs the same check — has the same uninit pattern. Worth a sweep.
  • Reproducer is any HEVC stream — bbb_60s_720p.hevc.mp4 hits this 100%.

Campaign cross-ref

Found in ampere-kernel-decoders iter3. Full forensic trace in iter3_close.md. Backend instrumentation that surfaced this: libva-v4l2-request-fourier iter3 diagnostic build (md5 404041ea).

Blocks ampere-kernel-decoders iter4 — once this lands in the ampere kernel, the standard 5-control batch failure (EINVAL) can be debugged separately.

## Summary The Casanova/Collabora v7.0 HEVC EXT_SPS_*_RPS series introduces a stack-uninit bug in `rkvdec_hevc_run` on vdpu381 (RK3588) and vdpu383 (RK3576). On every HEVC decode where the dispatcher enters the assemble path, `prepare_hw_st_rps` dereferences a non-NULL stack-garbage pointer and faults. ## Repro - Host: ampere (CoolPi CM5 GenBook, RK3588), `linux-fresnel-fourier`-style 7.0-rc3 + mmind v7.0 + Casanova HEVC v7.0 patches. - Command: `LIBVA_DRIVER_NAME=v4l2_request ffmpeg -hwaccel vaapi -i any.hevc.mp4 -frames:v 3 -f rawvideo /tmp/o.nv12` - dmesg: ``` [00000000000051a0] pgd=0, p4d=0 Internal error: Oops: 0000000096000004 pc : __pi_memcmp+0x10/0x110 lr : rkvdec_hevc_prepare_hw_st_rps+0x38/0x300 [rockchip_vdec] x0 : ffff000119202410 x1 : 00000000000051a0 x2 : 0000000000000048 Call trace: __pi_memcmp+0x10/0x110 rkvdec_hevc_assemble_hw_rps+0x1c rkvdec_hevc_run+0x12c rkvdec_device_run+0x48 v4l2_m2m_try_run v4l2_m2m_request_queue media_request_ioctl_queue ``` - `0x51a0` is deterministic stack-leftover for the specific calling pattern — not a ctrl pointer. ## Root cause `drivers/media/platform/rockchip/rkvdec/rkvdec-vdpu381-hevc.c:591`: ```c struct rkvdec_hevc_run run; // uninitialized rkvdec_hevc_run_preamble(ctx, &run); ``` `drivers/media/platform/rockchip/rkvdec/rkvdec-hevc-common.c:498-508`: ```c if (ctx->has_sps_st_rps) { ctrl = v4l2_ctrl_find(..., V4L2_CID_STATELESS_HEVC_EXT_SPS_ST_RPS); run->ext_sps_st_rps = ctrl ? ctrl->p_cur.p : NULL; } if (ctx->has_sps_lt_rps) { ctrl = v4l2_ctrl_find(..., V4L2_CID_STATELESS_HEVC_EXT_SPS_LT_RPS); run->ext_sps_lt_rps = ctrl ? ctrl->p_cur.p : NULL; } ``` When `ctx->has_sps_st_rps` is false (the common case: userspace doesnt yet submit the new controls), `run->ext_sps_st_rps` keeps stack-leftover bytes. Downstream: `drivers/media/platform/rockchip/rkvdec/rkvdec-hevc-common.c:380`: ```c if (!run->ext_sps_st_rps) return; // garbage 0x51a0 is non-NULL if (!memcmp(cache, run->ext_sps_st_rps, sizeof(...))) return; // memcmp derefs 0x51a0 -> OOPS ``` ## Fix (one line) Option A (recommended — fix at the producer): ```diff --- a/drivers/media/platform/rockchip/rkvdec/rkvdec-hevc-common.c +++ b/drivers/media/platform/rockchip/rkvdec/rkvdec-hevc-common.c @@ -495,6 +495,9 @@ void rkvdec_hevc_run_preamble(struct rkvdec_ctx *ctx, ctrl = v4l2_ctrl_find(&ctx->ctrl_hdl, V4L2_CID_STATELESS_HEVC_SCALING_MATRIX); run->scaling_matrix = ctrl ? ctrl->p_cur.p : NULL; + + run->ext_sps_st_rps = NULL; + run->ext_sps_lt_rps = NULL; if (ctx->has_sps_st_rps) { ``` Option B (defensive — zero-init at caller, applies to both vdpu381 + vdpu383): ```diff - struct rkvdec_hevc_run run; + struct rkvdec_hevc_run run = {}; ``` ## Scope - Affects: `vdpu381_variant` (RK3588) + `vdpu383_variant` (RK3576) — both call rkvdec_hevc_run. - Original RK3399 path (`rkvdec-hevc.c::rkvdec_hevc_run`) needs the same check — has the same uninit pattern. Worth a sweep. - Reproducer is any HEVC stream — bbb_60s_720p.hevc.mp4 hits this 100%. ## Campaign cross-ref Found in `ampere-kernel-decoders` iter3. Full forensic trace in `iter3_close.md`. Backend instrumentation that surfaced this: `libva-v4l2-request-fourier` iter3 diagnostic build (`md5 404041ea`). Blocks `ampere-kernel-decoders` iter4 — once this lands in the ampere kernel, the standard 5-control batch failure (EINVAL) can be debugged separately.
claude-noether commented 2026-05-16 10:53:42 +00:00
Collaborator
Copy Link
Copy Source

Empirical verification: Option A patch eliminates the OOPS

Applied Option A to ampere's running kernel tree (linux-rk3588-marfrit-equivalent, 7.0.0-rc3-devices+) and re-ran the exact repro.

Patch as applied

--- a/drivers/media/platform/rockchip/rkvdec/rkvdec-hevc-common.c
+++ b/drivers/media/platform/rockchip/rkvdec/rkvdec-hevc-common.c
@@ -496,6 +496,9 @@ void rkvdec_hevc_run_preamble(struct rkvdec_ctx *ctx,
 			      V4L2_CID_STATELESS_HEVC_SCALING_MATRIX);
 	run->scaling_matrix = ctrl ? ctrl->p_cur.p : NULL;
 
+	run->ext_sps_st_rps = NULL;
+	run->ext_sps_lt_rps = NULL;
+
 	if (ctx->has_sps_st_rps) {
 		ctrl = v4l2_ctrl_find(&ctx->ctrl_hdl,
 				      V4L2_CID_STATELESS_HEVC_EXT_SPS_ST_RPS);

Built via make M=drivers/media/platform/rockchip/rkvdec modules, installed to /lib/modules/7.0.0-rc3-devices+/kernel/..., depmod, fresh reboot for a clean slate (prior OOPS had left a v4l2_release thread stuck in D-state holding the module refcount — rmmod was blocked).

Test

LIBVA_DRIVER_NAME=v4l2_request ffmpeg -hwaccel vaapi -hwaccel_output_format vaapi \
  -i ~/measurements/encoded/bbb_60s_720p.hevc.mp4 -vf hwdownload,format=nv12 \
  -frames:v 3 -f rawvideo -pix_fmt nv12 /tmp/o.nv12

Result

  • ffmpeg exit code: 0 (was: SIGSEGV via stuck-in-kernel m2m queue on pre-patch run)
  • dmesg post-test: 0 occurrences of Internal error / Oops / Call trace / pgd= (was: deterministic __pi_memcmp fault at 0x51a0 per iter3_close.md)
  • /tmp/o.nv12: 4147200 bytes (exact match for 3 × 1280 × 720 × 1.5 NV12 frames)
  • backend log shows the predicted fallback path: populate_ext_sps_rps_cache exit: err=-61 cache_valid=0 → Unable to set control(s): Invalid argument per frame, BeginPicture/RenderPicture/EndPicture continues cleanly, no kernel fault

Caveat (out of scope for this issue)

/tmp/o.nv12 is all-zero — the EXT_SPS_*_RPS controls fail userspace-side with EINVAL and ffmpeg-vaapi forwards empty CAPTURE buffers. This is the separate iter4 EINVAL flagged in iter3_close.md ("standard-5-controls EINVAL — likely a slice_params field shape or DECODE_PARAMS flag the iter2 backend isn't setting correctly"), unrelated to this patch. The OOPS that this issue is about is gone.

Verdict

Option A is a clean fix for the OOPS. Ready to land in the Casanova v7.0 series. Also worth applying the same NULL-init (or struct rkvdec_hevc_run run = {} at caller) sweep for the original RK3399 path in rkvdec-hevc.c::rkvdec_hevc_run as noted in the "Scope" section.

Substrate at verification:

  • ampere 7.0.0-rc3-devices+, branch ampere-minimal-devices
  • backend libva-v4l2-request-fourier iter3 diagnostic build (md5 404041ea)
  • patched module: rockchip-vdec.ko 121872 bytes (was 121192 pre-patch)
## Empirical verification: Option A patch eliminates the OOPS Applied Option A to ampere's running kernel tree (`linux-rk3588-marfrit`-equivalent, `7.0.0-rc3-devices+`) and re-ran the exact repro. ### Patch as applied ```diff --- a/drivers/media/platform/rockchip/rkvdec/rkvdec-hevc-common.c +++ b/drivers/media/platform/rockchip/rkvdec/rkvdec-hevc-common.c @@ -496,6 +496,9 @@ void rkvdec_hevc_run_preamble(struct rkvdec_ctx *ctx, V4L2_CID_STATELESS_HEVC_SCALING_MATRIX); run->scaling_matrix = ctrl ? ctrl->p_cur.p : NULL; + run->ext_sps_st_rps = NULL; + run->ext_sps_lt_rps = NULL; + if (ctx->has_sps_st_rps) { ctrl = v4l2_ctrl_find(&ctx->ctrl_hdl, V4L2_CID_STATELESS_HEVC_EXT_SPS_ST_RPS); ``` Built via `make M=drivers/media/platform/rockchip/rkvdec modules`, installed to `/lib/modules/7.0.0-rc3-devices+/kernel/...`, depmod, fresh reboot for a clean slate (prior OOPS had left a `v4l2_release` thread stuck in D-state holding the module refcount — rmmod was blocked). ### Test ``` LIBVA_DRIVER_NAME=v4l2_request ffmpeg -hwaccel vaapi -hwaccel_output_format vaapi \ -i ~/measurements/encoded/bbb_60s_720p.hevc.mp4 -vf hwdownload,format=nv12 \ -frames:v 3 -f rawvideo -pix_fmt nv12 /tmp/o.nv12 ``` ### Result - **ffmpeg exit code: 0** (was: SIGSEGV via stuck-in-kernel m2m queue on pre-patch run) - **dmesg post-test: 0 occurrences** of `Internal error` / `Oops` / `Call trace` / `pgd=` (was: deterministic `__pi_memcmp` fault at `0x51a0` per iter3_close.md) - **/tmp/o.nv12: 4147200 bytes** (exact match for 3 × 1280 × 720 × 1.5 NV12 frames) - backend log shows the predicted fallback path: `populate_ext_sps_rps_cache exit: err=-61 cache_valid=0` → `Unable to set control(s): Invalid argument` per frame, BeginPicture/RenderPicture/EndPicture continues cleanly, no kernel fault ### Caveat (out of scope for this issue) `/tmp/o.nv12` is all-zero — the EXT_SPS_*_RPS controls fail userspace-side with EINVAL and ffmpeg-vaapi forwards empty CAPTURE buffers. This is the *separate* iter4 EINVAL flagged in `iter3_close.md` ("standard-5-controls EINVAL — likely a slice_params field shape or DECODE_PARAMS flag the iter2 backend isn't setting correctly"), unrelated to this patch. The OOPS that this issue is about is gone. ### Verdict Option A is a clean fix for the OOPS. Ready to land in the Casanova v7.0 series. Also worth applying the same NULL-init (or `struct rkvdec_hevc_run run = {}` at caller) sweep for the original RK3399 path in `rkvdec-hevc.c::rkvdec_hevc_run` as noted in the "Scope" section. Substrate at verification: - ampere `7.0.0-rc3-devices+`, branch `ampere-minimal-devices` - backend `libva-v4l2-request-fourier` iter3 diagnostic build (`md5 404041ea`) - patched module: `rockchip-vdec.ko` 121872 bytes (was 121192 pre-patch)
claude-noether commented 2026-05-18 09:40:17 +00:00
Collaborator
Copy Link
Copy Source

Triage refresh 2026-05-18. No empirical re-test needed — the bug is closed-form (stack-uninitialized field, deterministic fault, kernel-side). Confirming the issue is still open / unfixed:

  • fleet/ampere.yaml in kernel-agent does NOT include this fix among ampere's 6 board-DTS patches.
  • linux-ampere-fourier 7.0rc3.kafr1-1 baseline policy is "clean mainline + board-DTS only; fixes belong in experiment branch / target, not baseline" (per ampere.yaml preamble + the ampere-fourier campaign convention).

Closing sibling #11 as duplicate (symptom report; this issue carries the root cause + one-line fix).

Indirect mitigation path may exist via userspace work

There's a non-fix that could make the bug NOT FIRE under fleet conditions, without patching the kernel:

  1. kernel-agent#15 — register V4L2_CID_STATELESS_HEVC_EXT_SPS_ST_RPS / _LT_RPS in vdpu38x_hevc_ctrl_descs[]. This makes ctx->has_sps_st_rps = true in the kernel.
  2. libva-v4l2-request-fourier#3 — userspace backend populates V4L2_CID_STATELESS_HEVC_EXT_SPS_ST_RPS. iter2 commits 393d02f + f0ef69d in the libva repo look like this work has landed.

If both conditions hold (kernel has_sps_st_rps=true AND userspace submits the control), the if (ctx->has_sps_st_rps) branch in rkvdec_hevc_run_preamble initializes run->ext_sps_st_rps properly, the stack-garbage path is never reached, and the memcmp(0x51a0, ...) fault doesn't fire. The underlying bug is still there (any other userspace that doesn't submit EXT_SPS_*_RPS would still oops), but the fleet's libva backend would no longer trip it.

Decision points (operator)

a) Direct fix path: apply Option B (struct rkvdec_hevc_run run = {};, one-liner in rkvdec-vdpu381-hevc.c:591 + rkvdec-vdpu383-hevc.c) as a kernel-agent experiment branch / scope-tagged patch under patches/driver/media/ and ship via a non-baseline linux-ampere-fourier-rkvdec-hevc-fix variant. Bulletproof — doesn't depend on userspace cooperation.

b) Indirect path: rely on the userspace coverage from libva iter2 + kernel-agent#15 landing. Cheaper if those are happening anyway, but the bug remains a footgun for any other v4l2-request consumer (e.g. ffmpeg -hwaccel v4l2request direct without libva).

c) Upstream-first: send Option A to linux-media (Casanova/Collabora HEVC v7.0 series authors). Right long-term home; doesn't block local progress because (a) is still available as a stop-gap.

Recommend (c) as the right ultimate fix + (b) as the no-action interim, because the libva iter2 work appears to already be done. Reproducer-on-ampere would confirm — but reproducing requires installing a libva backend with iter2 on ampere, which the current sandbox policy gates.

**Triage refresh 2026-05-18.** No empirical re-test needed — the bug is closed-form (stack-uninitialized field, deterministic fault, kernel-side). Confirming the issue is still open / unfixed: - `fleet/ampere.yaml` in kernel-agent does NOT include this fix among ampere's 6 board-DTS patches. - `linux-ampere-fourier 7.0rc3.kafr1-1` baseline policy is "clean mainline + board-DTS only; fixes belong in experiment branch / target, not baseline" (per `ampere.yaml` preamble + the ampere-fourier campaign convention). Closing sibling [#11](https://git.reauktion.de/marfrit/kernel-agent/issues/11) as duplicate (symptom report; this issue carries the root cause + one-line fix). ## Indirect mitigation path may exist via userspace work There's a non-fix that could make the bug NOT FIRE under fleet conditions, without patching the kernel: 1. **[kernel-agent#15](https://git.reauktion.de/marfrit/kernel-agent/issues/15)** — register `V4L2_CID_STATELESS_HEVC_EXT_SPS_ST_RPS` / `_LT_RPS` in `vdpu38x_hevc_ctrl_descs[]`. This makes `ctx->has_sps_st_rps = true` in the kernel. 2. **[libva-v4l2-request-fourier#3](https://git.reauktion.de/marfrit/libva-v4l2-request-fourier/issues/3)** — userspace backend populates `V4L2_CID_STATELESS_HEVC_EXT_SPS_ST_RPS`. iter2 commits `393d02f` + `f0ef69d` in the libva repo look like this work has landed. If both conditions hold (kernel has_sps_st_rps=true AND userspace submits the control), the `if (ctx->has_sps_st_rps)` branch in `rkvdec_hevc_run_preamble` initializes `run->ext_sps_st_rps` properly, the stack-garbage path is never reached, and the `memcmp(0x51a0, ...)` fault doesn't fire. The underlying bug is still there (any other userspace that doesn't submit EXT_SPS_*_RPS would still oops), but the fleet's libva backend would no longer trip it. ## Decision points (operator) a) **Direct fix path**: apply Option B (`struct rkvdec_hevc_run run = {};`, one-liner in `rkvdec-vdpu381-hevc.c:591` + `rkvdec-vdpu383-hevc.c`) as a kernel-agent experiment branch / scope-tagged patch under `patches/driver/media/` and ship via a non-baseline `linux-ampere-fourier-rkvdec-hevc-fix` variant. Bulletproof — doesn't depend on userspace cooperation. b) **Indirect path**: rely on the userspace coverage from libva iter2 + kernel-agent#15 landing. Cheaper if those are happening anyway, but the bug remains a footgun for any other v4l2-request consumer (e.g. `ffmpeg -hwaccel v4l2request` direct without libva). c) **Upstream-first**: send Option A to linux-media (Casanova/Collabora HEVC v7.0 series authors). Right long-term home; doesn't block local progress because (a) is still available as a stop-gap. Recommend (c) as the right ultimate fix + (b) as the no-action interim, because the libva iter2 work appears to already be done. Reproducer-on-ampere would confirm — but reproducing requires installing a libva backend with iter2 on ampere, which the current sandbox policy gates.
marfrit added the EWONTFIX label 2026-05-18 09:44:37 +00:00
claude-noether commented 2026-05-18 09:44:38 +00:00
Collaborator
Copy Link
Copy Source

EWONTFIX 2026-05-18.

HEVC on ampere (RK3588) is scoped out indefinitely. Joint decision covering this issue plus kernel-agent#14 (kernel stack-uninit OOPS), kernel-agent#15 (HEVC_SLICE_PARAMS registration), and libva-v4l2-request-fourier#3 (libva backend EXT_SPS_*_RPS submission).

Rationale

  • Fleet HEVC consumption is near-zero for the workloads that matter: YouTube serves VP9 / AV1 / H.264 (never HEVC); mediathek.ard.de is H.264-dominant; DRM-gated 4K streams (Netflix/Apple TV+/Disney+) are blocked by Widevine L1 in the fleet's browsers anyway.
  • HEVC where it IS needed (local files, archive content) is already covered by fresnel (RK3399), which decodes HEVC + Main10 bit-exact HW==SW via libva-v4l2-request-fourier iter38/iter39 (verified during marfrit-packages#21 fix earlier today).
  • Ampere's value to the fleet is bigger silicon for YouTube AV1 (per daedalus-fourier README's "YouTube ∩ Pi5-HW = ∅" framing) — HEVC on ampere doesn't move that needle.

Reopen criteria

Reopen any of the three if a concrete HEVC workflow emerges on ampere (4K local file collection, HEVC-encoded archive that doesn't fit on fresnel, specific app that requires HEVC and runs only on ampere). The kernel side fix in #14 + #15 is closed-form (one-liner each); the libva side in #3 is straightforward bitstream-translation work. None of the analysis is lost; it's all archived in the closed issues' bodies + comments.

Closing.

**EWONTFIX 2026-05-18.** HEVC on ampere (RK3588) is scoped out indefinitely. Joint decision covering this issue plus [kernel-agent#14](https://git.reauktion.de/marfrit/kernel-agent/issues/14) (kernel stack-uninit OOPS), [kernel-agent#15](https://git.reauktion.de/marfrit/kernel-agent/issues/15) (HEVC_SLICE_PARAMS registration), and [libva-v4l2-request-fourier#3](https://git.reauktion.de/marfrit/libva-v4l2-request-fourier/issues/3) (libva backend EXT_SPS_*_RPS submission). ## Rationale - Fleet HEVC consumption is near-zero for the workloads that matter: YouTube serves VP9 / AV1 / H.264 (never HEVC); mediathek.ard.de is H.264-dominant; DRM-gated 4K streams (Netflix/Apple TV+/Disney+) are blocked by Widevine L1 in the fleet's browsers anyway. - HEVC where it IS needed (local files, archive content) is already covered by **fresnel** (RK3399), which decodes HEVC + Main10 bit-exact HW==SW via libva-v4l2-request-fourier iter38/iter39 (verified during marfrit-packages#21 fix earlier today). - Ampere's value to the fleet is bigger silicon for YouTube AV1 (per `daedalus-fourier` README's "YouTube ∩ Pi5-HW = ∅" framing) — HEVC on ampere doesn't move that needle. ## Reopen criteria Reopen any of the three if a concrete HEVC workflow emerges on ampere (4K local file collection, HEVC-encoded archive that doesn't fit on fresnel, specific app that requires HEVC and runs only on ampere). The kernel side fix in #14 + #15 is closed-form (one-liner each); the libva side in #3 is straightforward bitstream-translation work. None of the analysis is lost; it's all archived in the closed issues' bodies + comments. 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.)
 area:boltzmann
Touches boltzmann host
 area:fresnel
Touches fresnel host
 area:patch-tree
Touches the scope-tagged patches/ tree
 decision
Pending decision required (no clear default)
 migration
Bootstrap-time migration from existing trees into kernel-agent layout
No Label EWONTFIX
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claude-ampere (Claude (ampere)) claude-boltzmann (Claude (boltzmann)) claude-noether (Claude (noether)) marfrit (Markus Fritsche)
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: marfrit/kernel-agent#14
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?