3 ms·
VAAPI support on Wayland is painful. I've built a kiosk system that requires videos playing in Chrome/ium (cannot use Firefox because also need web-bluetooth s
by mmerlin 7y ago
VAAPI support on Wayland is painful.
I've built a kiosk system that requires videos playing in Chrome/ium (cannot use Firefox because also need web-bluetooth support)
Our hardware is Intel NUCs and currently we are rolling these out on Windows OS, but would vastly prefer Linux but hitting so many roadblocks.
Trying to get Intel hardware accelerated GPU video decoding working in Chromium running on Wayland has wasted me days of time with no resolution yet (tried ClearLinux and CentOS 8 and Ubuntu 16).
With Wayland on Intel hardware, only VLC player can make use of VAAPI but Chromium doesn't seem possible, which results in 100% (Celeron) CPU usage trying to view a local video in the browser using video.js player.
I'm going to ditch Wayland (Gnome) and try Xfce on my next attempt.
- ubercow13 7y agoAre you sure you’re using a build of Chromium with VAAPI support patched in? Support for hardware video decoding in Firefox on Linux does not exist at all, and Chromium does not support it either except in a set of patches which are not included upstream.
- mmerlin 7y agoyes I am using chromium-vaapi thanks. [edit] I am about to try Arch Linux (or Manjaro) with Xfce to get Chromium-vaapi working https://wiki.archlinux.org/index.php/Chromium#Hardware_video_acceleration https://wiki.archlinux.org/index.php/Chromium#Hardware_video...
- Whatitat90 7y ago> only VLC player can make use of VAAPI And mpv with "hwdec=vaapi" in ~/.config/mpv/mpv.conf
- aktau 7y agoI used to develop something like this (5-6 years ago). By far the best (most stable and performant) solution was the following: - Linux OS (ease of management, installation, introspectability). - Debian (somewhat stripped down), with custom packages. - Puppet for node management. - runit as a process manager. - Chromium to display videos/presentations. - (Custom) NPAPI based plugin (shim) that would load mplayer-vaapi (nowadays it would be mpv I guess) to display videos. It worked because one could get the X window ID of the <video> element via NPAPI, which was then passed to mplayer so it could initialize/render within the sub-window. One of the main benefits was that this avoided lots of resource leaks. The plugin pre-loaded mplayer processes and would shut them down after the video finished playing. Transitions were near to seamless (though required some HTML hacks to avoid white flashing). On our Sandy Bridge machines (small form factor, fanless), we could display 16 1080p videos side-by-side for days and the machine would stay cool. I was so excited when I demonstrated this. The previous interation of this software used the regular <video> (software) implementation and could barely manage a single video without overheating. Of course, NPAPI was deprecated a long time ago and removed from Chromium more than a year ago I think. The "replacement" (at the time) Pepper API AFAIK didn't allow access to the X window which is needed by mplayer. It was also not compatible between browsers. The plugin I made also worked on Firefox. Nowadays access to the necessary resources is so walled off that you'd really need hardware acceleration to be native to the browser. There'd be hard-to-avoid resource leaks, so I'd schedule browser restarts at night-time. I've been out of the loop for a while so maybe there's better stuff. I remember monitoring the Chromium repository to see if they would implement hardware acceleration. I recall they had a branch where this was "working" on ChromeOS and supposedly you could force-enable this for general Linux. I tried building this once, but my machine at the time could barely handle building it (took many hours). Once the binary was built, it would crash at startup. I decided it was too much effort to replace a solution that was working perfectly.