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.