In our previous post we outlined how Collabora and MediaTek are closing long‑standing gaps in Chromium’s V4L2 support, enabling efficient hardware video decoding and encoding across the Genio and Kompanio SoC families.
That work is the result of a close, ongoing collaboration: MediaTek is sponsoring this effort and actively enabling Collabora to work directly on Chromium for their platforms and customers. This partnership gives us access to the latest hardware and reference platforms, while ensuring the improvements we contribute upstream are aligned with real product requirements.
In this follow‑up, we dive into the details of that joint work: how we tested Chromium on Genio 700 and Genio 720, what workloads we focused on, and what the numbers look like when MediaTek’s hardware codecs are driven by Chromium’s V4L2 paths. We’ll also highlight current limitations and where we, together with MediaTek, are headed next.
All the results below are derived from our 2025 validation work on Chromium 138 with Collabora’s patches running on MediaTek Genio 700 and Genio 720 evaluation boards.
Jump to a section: Platform overview | Test setup | What we tested | Hardware codec verification | Genio 700 results | Genio 720 results | Limitations & next steps | What this means for products | Plans for 2026 | We can help
A joint platform: MediaTek hardware, Collabora enablement
MediaTek’s Genio and Kompanio platforms are shipped in many commercial products today, and most of them can run on upstream kernels with a modern, open graphics stack. By sponsoring this work, MediaTek is enabling Collabora to extend that upstream‑friendly approach into the Chromium ecosystem itself:
- Aligning Chromium’s V4L2 assumptions with MediaTek’s hardware capabilities
- Validating and tuning performance across multiple Linux distributions
- Feeding fixes and improvements back upstream so that future Chromium releases “just work” on Genio and Kompanio
This tight loop—hardware vendor, open source integrator, upstream communities—is what makes it possible to offer both a strong out‑of‑the‑box experience and long‑term maintainability for Chromium-based products.
Test platforms and software stack
Our joint goal with MediaTek was to validate Chromium in configurations that are representative of the systems their partners ship today: upstream-capable kernels, modern graphics stacks, and both Yocto- and Debian-based userspace.
Hardware
- MediaTek Genio 700 EVK
- MediaTek Genio 720 EVK
These evaluation kits, provided as part of the collaboration, serve as our reference platforms for Chromium bring‑up and validation, and mirror what MediaTek’s customers see in their own development environments.
Software environment
For Genio 700 we tested three main combinations:
- Yocto “Scarthgap” + Mali DDK
- Yocto “Scarthgap” + Panfrost (fully open GPU stack)
- Debian 13 + Panfrost
For Genio 720 we focused on:
- Yocto “Scarthgap” + Mali DDK
In all cases we used a Chromium build based on:
- Chromium 138.0.7204.298 with Collabora modifications
- V4L2 stateful and stateless decoding paths enabled
- V4L2 encoding integration
- Platform-specific fixes for MediaTek Genio hardware
Chromium 138 was selected as the version of Chromium because it is receiving Long-Term Support (LTS) updates for 6 months from its release. That enables Collabora development efforts for Chromium to receive security updates. The Collabora Chromium branch will move to the next long-term support candidate (LTC) when available.
To properly characterize CPU utilization we temporarily disabled background services that could skew results (for example, stopping sysrepo-cfg before running sar), and we configured audio routing via PipeWire/WirePlumber (wpctl status / wpctl set-default <id>).
This shared test infrastructure gives MediaTek and their customers a concrete baseline: the same Chromium build, the same test plan, and the same reference performance numbers.
What we tested: from browsing to video conferencing
The test plan was designed together with MediaTek to cover the most common Chromium-based use cases they see in customer projects:
General browsing and downloads
- Basic browsing on high-traffic sites (e.g., Google and the MediaTek website)
- Page load correctness
- Scrolling responsiveness
- Large file downloads (Debian 13 ISO)
- Download success
- Checksum verification (
sha256sum)
Video playback
- YouTube 4K VP9 (
https://www.youtube.com/watch?v=LXb3EKWsInQ)- 4K resolution selection
- Smooth playback
- Fullscreen and picture-in-picture transitions
- Pause/resume and seek behavior
- Ensuring VP9 (
vp09) is used, not AV1 (av01), to exercise hardware decoding
- BBC streaming (
https://www.bbc.com/news)- “Most watched” video playback
- Fullscreen, pause/resume, seek
- Local 4K files
- HEVC 4K@60 (
nasa_2160p_60fps_hevc.mp4) - H.264 4K@60 (“Big Buck Bunny” sunflower clip)
- Kiosk and normal window modes, looping
- HEVC 4K@60 (
WebCodecs
- Decode tests using the W3C WebCodecs demo:
- H.264, H.265, VP8, VP9: validate that content is correct and rendering rate is high (>150 fps for accelerated paths)
- AV1: validate correctness and observe that performance is lower (software decoding only)
- Encode + decode tests:
- H.264/H.265 webcam capture at Full HD
- Hardware vs software preference for encoder and decoder
- Visual smoothness and glass‑to‑glass latency
WebRTC and video conferencing
- WebRTC camera & microphone (Mozilla
gum_test):- Camera preview smoothness
- Microphone capture and playback
- Peer‑to‑peer conferencing (talky.io):
- Bi‑directional video and audio quality
- Screen sharing (tab sharing on the device under test)
- Microsoft Teams in browser:
- Joining meetings from the device under test without login
- Multi‑participant scenarios
- Screen sharing from other devices and receiving on the device under test
These are not synthetic lab‑only workloads: they reflect exactly the kinds of usage patterns MediaTek and Collabora see in embedded Chromium deployments (IVI systems, digital signage, smart home hubs, etc.).
Benchmarks and stress tests
- YouTube 4K VP9 +
sar:- CPU utilization comparison between hardware-accelerated and software decoding
- WebCodecs decode (WebGL renderer):
- FPS and CPU utilization across codecs (H.264, H.265, VP8, VP9, AV1 software)
- WebCodecs encode/decode (single stream):
- H.264/H.265 at 1080p, hardware vs software
- Latency and CPU utilization
- WebCodecs encode/decode (2× encode + 2× decode):
- WebGL Aquarium:
- 5000 fish at fullscreen resolution
- FPS and CPU utilization
Verifying that Chromium is really using the hardware codecs
When enabling V4L2 acceleration, the most important question for MediaTek and their customers is: are we really on the hardware path, or did we silently fall back to software? We use two main mechanisms to confirm this.
Chromium’s Media panel
- Open Chromium Developer Tools (
Ctrl+Shift+I→ More Tools → Web Developer Tools). - Switch to the Media tab (it may be under the » dropdown).
- Select the currently playing media entry.
- Look at the Decoder name (and Encoder name when encoding):
- It should explicitly reference V4L2 when hardware acceleration is in use.
V4L2 logging
For decoding, we run Chromium with verbose logging for V4L2 components:
chromium --enable-logging=stderr --v=0 --vmodule="*v4l2*=2"
This produces traces showing:
- The chosen capture format, e.g.
MM21at 3840×2176 - The number of capture buffers requested vs allocated
- Construction and configuration of the V4L2 image processor backend (conversions from MM21 to NV12 for rendering)
For encoding, we use:
chromium --enable-logging=stderr --v=0 --vmodule="*v4l2_video_encode*"=2
Here we validate that:
- The requested encoder type is hardware
- Input formats are negotiated correctly (e.g., fallback from
PIXEL_FORMAT_I420toPIXEL_FORMAT_NV12via a LibYUV-based image processor) - Input and output buffers are successfully configured and queued
These techniques are now part of the shared debugging toolbox that Collabora uses internally and that MediaTek’s customers can adopt when validating their own devices.
Genio 700: hardware decode and encode across three stacks
On Genio 700, MediaTek’s sponsorship allowed us to validate Chromium across three different graphics and userspace configurations: Scarthgap + Mali DDK, Scarthgap + Panfrost, and Debian 13 + Panfrost. This gives MediaTek and their partners a clear matrix of what works today and where upstream work is still required.
Functional test results
High-level outcomes for everyday workloads:
| General browsing and downloads |
|
| Video decoding (YouTube, BBC, local 4K, WebCodecs decode) |
|
| Video encoding (WebCodecs encode/decode) |
|
| Video conferencing (WebRTC gum test, talky.io, Teams) |
|
From a hardware selection perspective, Collabora believes this provides a clear picture: the MediaTek Genio 700 hardware is capable of efficient hardware decode/encode, and together we are steadily bringing the open graphics and distribution ecosystem up to that bar.
YouTube 4K playback: CPU savings with hardware decode
On Genio 700, playing back 4K VP9 content (YouTube, fullscreen) shows a clear win for hardware decoding:
- Hardware decoding: ~18% CPU
- Software decoding: ~90% CPU
For MediaTek’s customers, this difference directly translates into:
- More thermal and power headroom.
- Smoother UIs during heavy playback.
- The ability to reuse the same SoC for more complex applications without bumping up to a higher tier.
WebCodecs decode: throughput and CPU usage
Representative WebCodecs decode performance on Genio 700:
- H.264 (hardware, Scarthgap + Mali DDK):
- ~309 fps, 33% CPU
- H.264 (software):
- ~270–343 fps, 40–45% CPU
- HEVC (hardware):
- Up to ~1045 fps (Scarthgap + Panfrost), ~40% CPU
- VP8 / VP9:
- Hardware and software both reach high FPS; hardware consistently saves CPU:
- VP9 hardware: up to ~962 fps, ~37% CPU
- VP9 software: ~345–375 fps, ~53–55% CPU
- Hardware and software both reach high FPS; hardware consistently saves CPU:
- AV1:
- Software-only; performance and CPU usage reflect full CPU decode
These numbers are useful for both MediaTek’s internal teams and downstream product developers: they quantify the gain from enabling the hardware codecs correctly in Chromium.
WebCodecs encode/decode and conferencing‑like loads
For single‑stream encode/decode at 1080p:
- H.264 hardware encode + decode (Scarthgap + Mali DDK):
- Glass‑to‑glass latency roughly 100–180 ms
- CPU: ~40%
- H.264 software encode + decode:
- Latency range broader (e.g., 50–300 ms, with longer encode paths)
- CPU: ~60%
For multi‑stream scenarios (2× encode + 2× decode), simulating a multi‑participant video call:
- Hardware en-/decoding (Scarthgap + Mali DDK):
- CPU: ~50%
- Software en-/decoding:
- CPU: ~75–95% across all stacks
These results demonstrate that MediaTek’s hardware video engines, when driven via our joint Chromium work, can comfortably handle video conferencing workloads that would otherwise saturate the CPU.
WebGL performance
The WebGL Aquarium test (5000 fish, fullscreen) on Genio 700 shows:
- Scarthgap + Mali DDK: ~60 FPS, 33% CPU
- Scarthgap + Panfrost: ~45 FPS, 22% CPU
- Debian 13 + Panfrost: ~40–50 FPS, 25% CPU
This reassures MediaTek’s ecosystem that both proprietary and open GPU stacks are viable for Chromium-based 3D content on Genio 700, with Panfrost catching up rapidly.
Genio 720: consolidating hardware acceleration and stability
On Genio 720, MediaTek and Collabora focused on the Scarthgap + Mali DDK configuration and ran the full test suite, including stress workloads. Genio 720 gives us a view of how the next generation of hardware behaves under the same Chromium workloads.
Functional test results
| General browsing and downloads |
|
| Video decoding |
|
| Video encoding (WebCodecs) |
|
| WebRTC camera/microphone |
|
| Video conferencing |
|
These stability issues are being investigated jointly by Collabora and MediaTek, spanning kernel, GPU, and browser layers, to ensure that future platform and software revisions remove these edge‑case regressions.
YouTube 4K playback
On Genio 720, the same YouTube 4K VP9 scenario yields:
- Hardware decoding: ~35% CPU
- Software decoding: ~85% CPU
This locks in the main story for MediaTek’s partners: using the hardware decode path is not an optimization detail; it fundamentally changes the system’s performance envelope.
WebCodecs decode on Genio 720
Representative numbers for WebCodecs decode (Scarthgap + Mali DDK):
- H.264 (hardware): ~433 fps, 34% CPU
- H.264 (software): ~235 fps, 57% CPU
- HEVC (hardware): ~485 fps, 41% CPU
- VP8 (hardware): ~257 fps, 35% CPU
- VP8 (software): ~230 fps, 45% CPU
- VP9 (hardware): ~456 fps, 40% CPU
- VP9 (software): ~257 fps, 50% CPU
- AV1 (software): ~330 fps, 60% CPU
As with Genio 700, these results provide concrete guidance for MediaTek’s product and application teams when choosing codecs and resolutions.
WebCodecs encode/decode and multi‑stream scenarios
For a single encode/decode stream at 1080p:
- H.264 hardware:
- Glass‑to‑glass latency typically 180–210 ms
- CPU: ~29%
- H.264 software:
- Latency often in the 100–300 ms range, with longer tail latencies on encode
- CPU: ~40%
- HEVC hardware:
- Latency 130–205 ms
- CPU: ~34%
For the 2× encode + 2× decode scenario:
- Hardware en-/decoding: ~37% CPU
- Software en-/decoding: ~70% CPU
This confirms that Genio 720’s hardware, combined with our Chromium integration work, can sustain multi‑stream conferencing workloads with plenty of CPU headroom for UI and application logic.
WebGL on Genio 720
At 5000 fish in the WebGL Aquarium:
- Scarthgap + Mali DDK: 60 FPS, ~40% CPU
Again, Chromium’s WebGL support on Genio 720 is more than adequate for the 3D elements found in today’s Chromium-based UIs.
Known limitations and ongoing work
The test campaigns identified a number of areas where Collabora and MediaTek are actively collaborating on further improvements:
- H.264 V4L2 decode on Debian 13 + Panfrost (Genio 700)
- Currently broken in this stack, leading to failures or software fallback.
- We’re aligning V4L2 expectations between Chromium, the driver, and userspace, and feeding fixes upstream.
- NV12 support in Mesa GBM on Genio 700
- The lack of NV12 GBM support blocks hardware encoding on open drivers.
- Once resolved, we expect hardware encode to become available on Panfrost-based stacks too.
- WebRTC hardware encode artifacts on Genio 700
- To avoid visual artifacts in some WebRTC scenarios (e.g., Microsoft Teams), we currently fall back to software encode.
- We’re working on making the hardware path robust enough for these cases as well.
- Stability under high‑stress tab‑sharing scenarios on Genio 720
MediaTek’s sponsorship ensures Collabora can dedicate engineering time not just to quick downstream fixes, but to getting the relevant pieces into mainline kernels, Mesa, and upstream Chromium, so that all their customers—and the wider community—benefit.
What this means for Chromium‑based products on MediaTek SoCs
From a product perspective, the Collabora–MediaTek collaboration on Chromium demonstrates that:
- 4K video playback at reasonable power budgets is practical on Genio 700 and 720 when V4L2 acceleration is in use (e.g., 4K VP9 YouTube playback dropping CPU usage from ~85–90% to ~18–35%).
- WebRTC‑style conferencing workloads can run with ample CPU headroom when hardware encode/decode is used, enabling:
- More participants
- Higher resolutions
- Additional application logic and UI complexity on the same SoC
- Open graphics stacks (Panfrost) are increasingly capable, with hardware decode performing well, and only a handful of format and integration issues between Mesa, GBM, and Chromium remaining. However, the Panfrost stack is not as a performant in WebGL and WebGPU use-cases with heavy scenes (e.g. for gaming type use-cases). The Collabora graphics team, together with Arm and Google, is actively working to close the gap on demanding graphical workloads.
- Vendor and upstream stacks can co‑exist: Yocto‑based reference images and Debian 13 both benefit from the same Chromium improvements, even if some combinations currently require further tuning.
Crucially, because MediaTek is sponsoring this work with the explicit intent of supporting their customers, these improvements are not limited to a single one-time browser build: they are steadily landing upstream and in reference BSPs that downstream device makers can build on.
Plans for 2026
Looking ahead to 2026, this collaboration between MediaTek and Collabora will continue to deepen. Both companies are committed to further investing in Chromium acceleration and integration on Genio SoCs, expanding coverage across more codecs, use cases, and web technologies.
Our joint roadmap includes hardening hardware-accelerated media paths, targeting zero copy whenever possible for even more demanding workloads, improving stability in complex WebRTC scenarios, and aligning closely with upstream Chromium, Mesa, and Linux kernel developments. This ongoing work ensures that Genio-based products can rely on a modern, efficient, and well‑maintained Chromium.
We can help
Bringing a Chromium‑based UI product to market requires careful consideration. If you're planning on building a Chromium-based UI or video application on MediaTek platforms, let’s talk about how we can help you:
- Validate that hardware acceleration is actually in use
- Optimize for 4K+ content rendering
- Move from proprietary stacks to open drivers without losing performance
- Understand potential long‑term maintenance costs
As part of this joint effort with MediaTek, Collabora maintains reference Debian and Yocto system images for MediaTek Genio EVKs that integrate this Chromium work for testing purposes. If you would like to evaluate a Debian or Yocto image on a MediaTek Genio evaluation kit (EVK), or discuss adapting this work to your own board or product, please contact Collabora. We’ll be happy to discuss your use case and share suitable images and guidance.