Chromium hardware video acceleration on MediaTek Genio

A browser is the quickest UI stack an embedded product can adopt: your HMI is a web app, your kiosk is a URL, and your frontend team already knows the tools. On MediaTek Genio that browser is Chromium, MediaTek ships an image that includes it, and the difference between a smooth product and a hot, throttling one usually comes down to one question: is video actually decoding in hardware? Here is how the pieces fit on Genio and how to verify each one.

Key Insights

• Chromium ships in MediaTek’s rity-browser-image, the top of the RITY image hierarchy, with proprietary codec support included.
• Genio’s hardware decoders (H.264/H.265) are exposed through V4L2 by the mtk-vcodec drivers; Chromium reaches them through its V4L2 video decode path on Wayland/Ozone.
• Never assume acceleration: chrome://gpu and chrome://media-internals tell you what your specific build is doing, and CPU load while playing video is the honest cross-check.
• Treat browser WebRTC encode as software: for camera-out streaming, a native GStreamer pipeline with the hardware encoder is the dependable path.

Which image gives you Chromium, and what does it cost?

MediaTek’s IoT Yocto (RITY) images stack in a strict hierarchy, and Chromium arrives at the top:

Image	Approx. size	What it adds
rity-bringup-image	~150 MB	Core tools, SSH, debug
rity-bsp-image	~500 MB	Weston, GStreamer, camera, audio
rity-demo-image	~1 GB	AI/ML stack (TFLite, ONNX, NeuroPilot)
rity-browser-image	~2 GB	Chromium with proprietary codecs

That 2 GB figure is the honest price of a browser UI, and it buys you a Chromium that MediaTek has already integrated against the platform’s Wayland compositor and codec stack, so you are not patching a browser yourself. For products, you have two sane starting points: ship the browser image and strip what you do not need, or derive from rity-bsp-image and pull the Chromium recipe in, owning the integration choices explicitly. Prototype on the first; decide deliberately before the second.

Chromium runs on Weston through the Wayland Ozone backend on these images. If you are composing your own launch command, --ozone-platform=wayland is the flag that puts Chromium on the compositor properly instead of through legacy paths.

How does hardware video decode work under Chromium here?

Two layers have to cooperate. The kernel side is solid ground: Genio SoCs expose their hardware H.264 and H.265 decoders as V4L2 devices through the mtk-vcodec drivers, the same decoders our GStreamer pipelines use in Genio video work. The browser side is Chromium’s V4L2 video decode support, which turns a <video> element’s stream into work for those devices instead of for libavcodec on the CPU.

The reason to verify rather than trust: whether a given Chromium build uses V4L2 decode, and for which codecs, is a build-time and version-dependent decision. Browser upgrades, codec type (H.264 vs VP9 vs AV1, where the web increasingly serves the latter two), and DRM-protected content can each silently change the path. The platform decoder covers H.264/H.265; a site that serves VP9 or AV1 lands on software decode no matter how well the V4L2 path works.

How do you prove decode is actually in hardware?

Three checks, in order of authority:

1. chrome://media-internals while your real content plays. Find the player entry and read the decoder it instantiated. A V4L2-backed hardware decoder is named as such; FFmpegVideoDecoder or VpxVideoDecoder means software. This is per-stream truth, and it catches the codec-mismatch case immediately.
2. chrome://gpu, the capability view: the Video Acceleration section lists which codecs and resolutions the build believes it can accelerate. If decode capability is absent here, no flag juggling on your content will conjure it.
3. top during playback, the unfakeable check. Hardware-decoded 1080p sits at low single-digit browser CPU for the decode itself; software decode of the same stream is unmissable across the cores. On a fanless enclosure, thermals make this check for you, unkindly, a few minutes later.

When these disagree with your expectations, work down the stack: does the content codec match what the platform accelerates, does chrome://gpu show the capability, and do the V4L2 decoder devices exist and probe cleanly in dmesg? That ordering turns “video is janky” into a specific layer with a specific owner.

What does a production kiosk setup look like?

The launch pattern that behaves:

chromium --ozone-platform=wayland --kiosk --noerrdialogs \
         --disable-session-crashed-bubble http://localhost/app

Run it as a systemd service tied to the Weston session, with Restart=always so a renderer crash is a blip instead of a service call. Two disciplines pay for themselves: keep the flag list minimal and version-controlled (kiosk images grow cargo-cult flags at every debugging session, and each one is an unaudited behavior change), and size RAM for the browser you actually run, since a modern web app in Chromium is comfortably a multi-hundred-megabyte tenant on top of the 2 GB image.

Where does the browser stop being the right tool?

Outbound video. Chromium’s WebRTC encode on embedded Linux is, in practice, a software path, so every outgoing stream is a standing CPU tax, exactly the resource your UI and application need. Genio has a hardware encoder sitting right there; the browser just is not the reliable way to reach it. For camera-to-network products we put capture and encode in a native GStreamer pipeline using the hardware codec and keep the browser for what it is great at: rendering the UI. If a video call inside the browser is a hard requirement, benchmark a real sustained call on your image early, with thermals, not a ten-second demo.

Where to start

Flash rity-browser-image, put your actual content in front of it, and run the three verification checks before any optimization work. You will know within an hour whether your product’s video path is hardware-clean, codec-mismatched, or build-limited, and each of those has a different, specific fix.

Building a kiosk or HMI product on Genio and want the video path verified end to end, with the browser integration done right? Get MediaTek Genio engineering support.

Sources: MediaTek IoT Yocto documentation, Chromium Ozone/Wayland documentation, and the Linux V4L2 codec interface documentation.