Update 2026-04-28: This page captures the state on 2026-04-26. The
campaign has since grown into 4 sibling patch series + 1 kernel RFC;
the current 4-patch chromium-fourier shape and the end-to-end ohm
validation (~3.8× CPU reduction on bbb_1080p30_h264.mp4) are tracked
in fourier:start and patch_series.

When the cross-compile build on CT220 (chromium-builder-x86 on data) finishes, we get a stock Chromium 147 aarch64 binary at out/Default/chrome plus support files (*.pak, locales/, icudtl.dat, v8_context_snapshot.bin, chromedriver, chrome_sandbox). Packaged as chromium-fourier-147.0.7727.116-1-aarch64.pkg.tar.zst via the marfrit PKGBUILD — total install ~250-400 MB.

Built with use_v4l2_codec=true, use_v4lplugin=true, use_linux_v4l2_only=true baked in at compile time. That's the part brave-bin does not have. Whether those flags actually flip the right factory for our hantro stateless decoder is the test we run post-install on ohm; if not, the next iteration adds a small source patch to the factory check (original chromium-fourier NEXT.md plan B — much smaller scope than full libva-multiplanar).

What we lose vs brave-bin: Brave Shields (ad-block), Brave Wallet, Brave-specific sync, Brave Search integration, Talk, Rewards. UX downgrade for power users; for “video plays, browser browses” it is a wash.

Rug-pull does not reach the code that needs to change.

brave-bin links some things as shared libraries — those CAN be swapped:

• libva — already done with LIBVA_DRIVER_NAME=v4l2_request pointing at our libva-v4l2-request-fourier
• /opt/brave-bin/lib/libffmpeg.so — our ffmpeg-v4l2-request-git libavcodec could be dropped in there

But the decoder factory gating is statically baked into the brave binary as compile-time BUILDFLAG(IS_CHROMEOS) guards, not a runtime function call. There is no symbol to LD_PRELOAD over. The V4L2VideoDecoder class exists in brave-bin (verified via strings), but the factory that decides “should I instantiate it?” is hard-coded IS_CHROMEOS-only at compile time. A library swap cannot undo a #ifdef.

Library swap also does not help with the chromeos pipeline ImageProcessor failure that we hit on stock brave-bin — that is also static.

1. Use chromium-fourier — ship the result of today's build, accept the loss of Brave-specific features. Quickest.
2. Rebuild Brave from source with the same use_v4l2_codec gn args we use for chromium-fourier. Brave's source = chromium + a brave-core overlay; same gn build, same cross-compile environment on CT220, same chromium-fourier patches on top of brave-core's tree. Another 6-10 h build. Ships a brave-fourier next to chromium-fourier. Real Brave with V4L2 unlocked.
3. Binary-patch brave-bin to flip the IS_CHROMEOS check at the call sites. Find the conditional jump in the V4L2VideoDecoder factory, NOP-out the chromeos gate. Fragile, has to be redone every Brave version, and the chromium guards are usually inlined past easy patching.
4. Wait for upstream Brave/Chromium to enable V4L2 on Linux non-ChromeOS. Vaporware horizon.

Recommended: (1) for ohm right now, (2) as the proper followup once chromium-fourier proves the V4L2 unlock actually engages decode. The real validation is “does it decode?” — once confirmed on chromium-fourier, the same patches are guaranteed to work on Brave's tree because Brave is chromium + UI/feature additions; the decoder code is unchanged.

Captured from a Fourier session on 2026-04-26. Live PKGBUILD source: marfrit-packages/arch/chromium-fourier.