Using Chromium to play accelerated video freezes/locks up

Technical Support
,
1

I am currently evaluating using a Verdin iMX8M Plus on a Dahlia carrier board and have run into trouble using Chromium to play videos with accelerated video decoding.

I have followed the instructions for how to build the reference multimedia image:

Followed by the instructions for how to add Chromium to the build:

I am installing the image with Toradex Easy Installer

After the OS boots, I then followed this post to enable the correct audio driver:

Then I stop the default app:
systemctl stop wayland-app-launch

And launch Chromium to a demo page to play a video:
chromium --no-sandbox --ozone-platform=wayland --in-process-gpu --kiosk --no-first-run https://www.webmfiles.org/demo-files/

The video plays fine, until you interact with the video player again. After this, the whole Chromium instance appears to lock up. Subsequent launches of Chromium appear to “launch”, but the Chromium window never appears.

Chromium version: 117.0.5938.132
chrome://gpu reports Video Decode: Hardware accelerated

This issue does not occur if you instead run Chromium with the GPU disabled:
chromium --no-sandbox --ozone-platform=wayland --disable-gpu --kiosk --no-first-run https://www.webmfiles.org/demo-files/

tdx-info:

Software summary
------------------------------------------------------------
Bootloader:               U-Boot
Kernel version:           6.6.84-7.3.0-devel #1 SMP PREEMPT Fri May 30 12:17:11 UTC 2025
Kernel command line:      root=PARTUUID=57a4572c-02 ro rootwait console=tty1 console=ttymxc2,115200
Distro name:              NAME="TDX Wayland with XWayland"
Distro version:           VERSION_ID=7.3.0-devel-20250613021642-build.0
Distro variant:           -
Hostname:                 verdin-imx8mp-15696957
------------------------------------------------------------

Hardware info
------------------------------------------------------------
HW model:                 Toradex Verdin iMX8M Plus WB on Dahlia Board
Toradex version:          0058 V1.1B
Serial number:            15696957
Processor arch:           aarch64
------------------------------------------------------------
2

Hi, I’m the Toradex AI Assistant.

I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.

Did you like my answer? :+1: :-1:

Hello! Thank you for sharing a detailed description of your setup and the issue you’re encountering with Chromium video playback on the Verdin iMX8M Plus with the Dahlia carrier board.

Based on your workflow and observations, here are some important points and recommendations:

Chromium GPU Acceleration on Verdin iMX8M Plus

  • Chromium version 117.0.5938.132 is indeed the last version confirmed to work well with GPU acceleration on this platform (reference).
  • Your check of chrome://gpu showing “Video Decode: Hardware accelerated” confirms the GPU part is functioning—at least initially.

Observed Issue

  • Video plays fine until you interact with the player, after which Chromium locks up.
  • After the lock-up, relaunching Chromium doesn’t show its window.

Suggestions and Workarounds

1. Chromium Launch Command Modification

The --in-process-gpu flag can sometimes make video decoding unstable on i.MX8 platforms and is generally not recommended unless specifically required. Try launching Chromium without this flag:

chromium --no-sandbox --ozone-platform=wayland --kiosk --no-first-run https://www.webmfiles.org/demo-files/

Avoiding --in-process-gpu helps Chromium use the GPU process, which tends to be more stable on the Verdin iMX8M Plus (reference).

2. Wayland Compositor and Zombie Chromium Processes

If Chromium locks up, subsequent launches failing to show the window typically means either:

  • The Wayland compositor needs restarting.
  • Stale Chromium processes are left running.

After the lock-up, before launching Chromium again, run:

pkill chromium

Additionally, restarting the Wayland compositor (for example, Weston) might be necessary:

systemctl restart weston

3. Debug Logging

If the modified launch command still leads to issues, gather more details by running:

chromium --no-sandbox --ozone-platform=wayland --enable-logging=stderr --v=1 --kiosk --no-first-run https://www.webmfiles.org/demo-files/

This will help you observe errors or warnings during the lock-up episode (reference).

4. Consider GStreamer for Video Playback

For robust video playback with hardware acceleration, consider using GStreamer directly, as it is well-supported and proven stable on the Verdin iMX8M Plus:

This approach bypasses the web browser for video content and may be a better fit if the application allows it.

5. Known Stability Limitations

The Verdin iMX8M Plus does support GPU acceleration in Chromium, but stability with in-browser video decoding can be affected by:

  • Video player UI interactions,
  • Certain flags (like --in-process-gpu),
  • Compositor stability.

If your use case critically depends on accelerated and robust web-based video playback, monitor upstream Yocto and Chromium developments for future fixes.

To summarize:

  • Try running Chromium without the --in-process-gpu flag.
  • Clear up lingering processes with pkill chromium and restart the compositor if needed.
  • Collect debug logs if issues persist.
  • Consider GStreamer for direct video playback if suitable for your application.

Let me know if the above helps, or if you have further results or logs to share!

Best regards,
Toradex AI Assistant.

Useful references:

3

I got an email about this, I guess because I’m quoted. That sound hack “works” for testing “hello world” type sound stuff, not for production.

Success in the embedded systems world means never use chromium for anything. Redesign the application so you don’t need any part of it. If you are using chromium to connect with the outside world, there is no way to secure your device.

I’m not in my office and I’m not using Toradex for anything anymore. I can tell you Dahlia is the ugly red headed step child chained in the basement. No amount of sudo command line tweaks will change this hard and fast reality.

You have embarked on a trail of tears. I don’t have the dev system running for that client anymore and am not certain I could share what I ultimately had to do to make Dahlia work. Client had to do mods to the board to make sound work. I’m not a hardware geek and that project was years ago. There are hardware flaws in Dahlia, at least when it comes to sound. Grounds that don’t go any where which cause noise on input lines and other problems. I don’t remember them causing crashes, but they reek havoc with sound recording and playback. Just remember the hardware side ranting “all it took was a couple of 2 cent parts that should have been installed during manufacturing.”

You are a looooong way from getting to that point.

Your problem started here.

That doesn’t build for Dahlia. It will air quote run close air quote on Dahlia but not run well.

I am working from years old memory here and don’t have access to the system but . . .

You have to tunnel through the Yocto build scripts finding all verdin references and changing them to the correct value for Dahlia. No, a mass substitution across everything will not work.

There is an initial boot script (don’t remember file name, but this is what chooses the firmware) which has verdin hard coded as a default. Adding insult to injury it doesn’t properly override for Dahlia. You end up with a mish-mash of drivers. Might be two files you have to change . . . memory fuzzy.

You have to change the default to Dahlia AND I think you have to tweak the device/driver list.

I’m not imbibing caffeine right now and I gave up nicotine years ago, but I only found this after something like an 18 hour caffeine and nicotine fueled debug/dev session. You are entering an area where the devices are not the same between Verdin and Dahlia and “compatible” is a horribly hollow feeling.

Once you find the boot script(s) where Verdin is hard coded fixing both that and the device list, then you can move on to finding the hardware reasons the sound doesn’t work reliably.

Even if I wasn’t working from years old memory, I have NDAs in place so probably couldn’t share more. Client paid for a lot of my time and a lot of their hardware people’s time to track all of this down. They own it.