====== chromium-fourier — what we get + how we approach Brave ======

> **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|fourier:start]]'' and ''[[fourier:patch_series]]''.

===== (a) What chromium-fourier gets us =====

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.

===== (b) The rug-pull on Brave =====

**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.

===== Viable Brave paths (ascending effort) =====

  - **Use ''chromium-fourier''** — ship the result of today's build, accept the loss of Brave-specific features. Quickest.
  - **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.
  - **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.
  - **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: [[https://git.reauktion.de/marfrit/marfrit-packages/src/branch/main/arch/chromium-fourier|marfrit-packages/arch/chromium-fourier]].//