# Phase 0 — substrate lock for iter14

**Goal:** Brave actually engages VAAPI hardware video decode via libva-v4l2-request-fourier on PineTab2 / Mali-G52 r1 MC1 / RK3566, building on iter13's ANGLE-Vulkan unlock.

Closed **2026-05-20** after iter13 close. Brave currently plays bbb_1080p30_h264.mp4 in pure software:
- Renderer pegs a core at 106% CPU
- `lsof /dev/video1` is empty (hantro-vpu V4L2 decoder idle)
- chrome://gpu reports "Video Decode: Hardware accelerated" but this is misleading (a chromium-wide chrome://gpu lie pattern, see iter11 evidence)

## Confirmed working in isolation

The libva backend itself is healthy:

```
$ pacman -Q libva libva-v4l2-request-fourier
libva 2.23.0-1
libva-v4l2-request-fourier 1:1.0.0.r380.9898331-1

$ LIBVA_DRIVER_NAME=v4l2_request vainfo
v4l2-request: auto-selected codec device: /dev/video1 + /dev/media0
Trying display: wayland
vainfo: VA-API version: 1.23 (libva 2.22.0)
vainfo: Driver version: v4l2-request
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            :	VAEntrypointVLD
      VAProfileMPEG2Main              :	VAEntrypointVLD
      VAProfileH264Main               :	VAEntrypointVLD            ← bbb
      VAProfileH264High               :	VAEntrypointVLD
      VAProfileH264ConstrainedBaseline:	VAEntrypointVLD            ← bbb
      VAProfileH264MultiviewHigh      :	VAEntrypointVLD
      VAProfileH264StereoHigh         :	VAEntrypointVLD
      VAProfileVP8Version0_3          :	VAEntrypointVLD
```

VAProfileH264ConstrainedBaseline matches bbb_1080p30_h264.mp4's profile. Decoder hardware path is RK3566 → `hantro-vpu` (V4L2 stateless H.264 frontend) → `/dev/video1`.

## What's missing from Brave's current invocation

The packaged `brave-vulkan` launcher uses iter9's combo:
```
brave --use-gl=disabled --enable-features=Vulkan --use-vulkan=native \
      --ozone-platform=x11 --no-sandbox --disable-gpu-sandbox --ignore-gpu-blocklist
```

Three reasons this can't engage VAAPI:

1. **No `LIBVA_DRIVER_NAME` set.** libva defaults to vendor-string-based driver autodetection, which on Mali-G52 / Mesa returns nothing useful — libva-v4l2-request-fourier is **not** auto-selected. Brave's `vaapi_wrapper.cc:1658` then logs "vaInitialize failed: unknown libva error" (we saw this in iter11).
2. **`--use-gl=disabled`.** Brave's VAAPI delivery path uploads decoded frames into GL textures for compositing. With no GL backend, there's no destination for decoded surfaces → the wrapper bails before opening `/dev/video1`. iter13 unlocked the real GL backend (ANGLE on Vulkan); we need to use it here.
3. **No `AcceleratedVideoDecodeLinuxGL` feature flag.** Brave 148 has a Linux-specific Finch gate that disables VAAPI by default on non-Nvidia GPUs unless this feature is explicitly enabled.

## Brave 148 VAAPI feature inventory

`strings /opt/brave-bin/brave | grep VaapiOnEnableVideo` produces:
- `AcceleratedVideoDecodeLinuxGL` — primary Linux gate
- `AcceleratedVideoDecodeLinuxZeroCopyGL` — zero-copy GPU→GL path
- `VaapiVideoDecoder` — generic switch (likely needed too)
- `VaapiIgnoreDriverChecks` — disables the driver-vendor allowlist (libva-v4l2-request-fourier reports "v4l2-request" as vendor, not on chromium's known-good list)
- `VaapiOnNvidiaGPUs` — irrelevant here
- Metrics: `Media.HasAcceleratedVideoDecode.H264`, `Media.VaapiVideoDecoder.DecodeError`, `Media.VaapiVideoDecoder.VAAPIError`

## iter14 plan

Phase-bridge: iter11 was "VAAPI engagement on Brave" but stalled because:
- ANGLE-Vulkan didn't work (no VK_EXT_transform_feedback) → iter12 forced `--use-gl=disabled` → no GL backend → no VAAPI delivery path

iter13 fixed the underlying ANGLE-Vulkan gap. iter14 now wires:
- env: `LIBVA_DRIVER_NAME=v4l2_request`
- flags: `--use-gl=angle --use-angle=vulkan` + `--enable-features=Vulkan,AcceleratedVideoDecodeLinuxGL,AcceleratedVideoDecodeLinuxZeroCopyGL,VaapiVideoDecoder,VaapiIgnoreDriverChecks`
- keep: `--ozone-platform=x11 --no-sandbox --disable-gpu-sandbox --ignore-gpu-blocklist`

Regression probe (Phase 3): play bbb_1080p30_h264.mp4 in Brave with this combo and verify empirically:
1. `lsof /dev/video1` shows Brave holding it
2. Renderer CPU drops well below 100% (HW decode = ~5-15% renderer CPU, software = 100-130% on this hardware)
3. chrome://media-internals shows the decoder is "VaapiVideoDecoder" not "FFmpegVideoDecoder"

## Out of scope for iter14

- Hardware **encode** (chrome://gpu reports "Video Encode: Software only"; libva-v4l2-request-fourier is decode-only).
- VP9 / AV1 / HEVC. Even though some profiles are reported by vainfo, RK3566 lacks the hardware for these in this configuration.
- Decoder buffer descriptor format mismatches (NV12 vs NV15/NV20). Will surface in Phase 4 if it does; defer until then.

— claude-noether, 2026-05-20