At this time, the only browser for Linux that offers hardware-accelerated video decoding is the patched version of Chromium. The code to enable the feature is already in the browser, as I understand, as a remnant of the code to enable the feature in the Linux-based ChromeOS, but Google has it blocked on all non-ChromeOS Linux distros for reasons that don’t seem valid to me. They say it’s unreliable and does not work with all setups (nVidia in particular), which is probably true, but even if the patch is installed, the feature is still disabled by default and hidden behind a “flag” that marks it as an experimental and unsupported feature, so why not just enable it and let the user decide as with other experimental, unsupported features?
The patch to enable hardware-accelerated video decoding (I will call it HAVD for short) was submitted a long time ago, but Google refuses to accept the submission. Still, Chromium is open source, and the patched versions are available in the repos of several distros, and by PPA for Ubuntu and derivatives. I’ve tested it before and found it quite effective, though it did not reduce the CPU use as much as using hardware-accelerated media players like VLC. It seemed kind of like it was half accelerated compared to the full HAVD acceleration found in Windows browsers and dedicated media players on any platform.
Recently, Chromium has switched to the “Mojo” decoder in the code base, presumably because it is better than the old one in some way, but when I tried to use it to stream a 1080p 60 fps video on my slow Swift, it didn’t work as well as it used to. It paused (a single stutter) for a fraction of a second every five seconds or so, while the older Chromium builds I tested a while back (not sure which ones they were) just streamed the video flawlessly with about 40% CPU usage. Dedicated media players like VLC or SMPlayer (which have full hardware video decode acceleration) are able to stream the same video with considerably less CPU usage.
Without hardware decoding acceleration in Chromium, the 60 fps video is rough on the Swift. It can just about handle it if there is nothing else at all running on it, but even something like moving the mouse will cause it to stutter and drop a lot of frames. I get the same result in Waterfox, which of course has no option to use hardware decoding.
Note that HAVD is not the same as the option that browsers typically just call hardware acceleration, which Waterfox and unpatched Chromium do have. That kind of hardware acceleration uses the GPU to draw the onscreen elements, and is used all the time, not just while decoding video streams.
My main concern on the Swift is battery life. One of the main complaints of people who want hardware acceleration in our browsers is just that… but with the iffy hardware acceleration of Chromium, what will the difference be?
I devised a series of tests to get an idea. I would charge the Swift to 100%, then start the video playing (in this case, Big Buck Bunny at 1080p, 24 fps, h.264, looped), and measure the time it takes to get to 90% battery life remaining. In the olden days of laptops, the remaining battery percentage was estimated, but batteries in modern laptops report their rate of charge or discharge and remaining charge to the system, so the OS does not need to estimate.
I tested using unencrypted video from Youtube and Widevine encrypted video from castlabs.com, on Waterfox Classic 2019.10 and Chromium 79 (development version, patched, from the saiarcot895 PPA). I also tested Waterfox in Windows 10 (which has HAVD) and in SMplayer in Linux and Windows, which both have HAVD as well . The video is the same (1080p, 24fps, h.264) in both cases, with the only difference being that one is encrypted (using the same Widevine method as Netflix, Amazon Prime, Hulu, and other content providers) and one is not.
For all tests, Wifi was on, bluetooth off, sound muted, display brightness about 20%, no USB devices plugged in. Tests 1-7 and 11-12 used KDE Neon Linux, kernel 5.0.0-34, with TLP enabled and using default settings. Tests 8-10 used Windows 10 (1809) with default settings, with the power savings/performance slider set to prefer power savings (not all the way to the power savings side, but about a third of the way from there).
Test 1 used encrypted video on Waterfox. It went 30 minutes, 18 seconds.
Test 2 used unencrypted video on Waterfox. It went 34 minutes, 15 seconds.
Test 3 used encrypted video on Chromium, with HAVD disabled. It went 24 min, 12 seconds.
Test 4 used unencrypted video on Chromium, with HAVD enabled. It went 32:30.
Test 5 used encrypted video on Chromium, with HAVD enabled. It went 30 minutes, 8 seconds.
Test 6 used unencrypted video on Chromium, with HAVD disabled. It went 26 minutes, 19 seconds.
Test 7 used SMplayer media player, unencrypted, using the Mplayer backend with HAVD enabled. It went 44 minutes, 9 seconds.
Test 8 used Waterfox 2019.10 on Windows 10, HAVD enabled as by default, unencrypted. It went 41 minutes, 30 seconds.
Test 9 used SMplayer on Windows 10 with HAVD enabled. I was not able to get the streaming from Youtube to work with it (it would silently crash with no error with either the Mplayer or MPV backend, and I didn’t want to spend too much time troubleshooting it for a Windows installation that doesn’t get used for anything other than testing), so I downloaded the file to the local eMMC drive and I ran it from there. That should, if anything, theoretically increase the play time, as the wireless link would not have to be used to transmit the data to the PC. It went 43 minutes, 30 seconds (I didn’t screenshot those, so I may have rounded the times). Yes, surprisingly, Linux beat it by one minute.
Test 10 used Waterfox on Windows 10 playing the encrypted video. HAVD on. It went 30 min 39 sec.
Test 11 used Chromium 78, unpatched, from the Ubuntu repo. HAVD is not available with this build. With the encrypted video, it went 26 minutes, 7 seconds.
Test 12 used Vivaldi 2.9.1705.41, based on Chromium 78. HAVD is not available with this build. With the encrypted video, it went 30 minutes, 57 seconds.
I repeated the unencrypted Waterfox test and got 34 minutes, 15 seconds again. Amazingly consistent! I went back and checked my screenshots to be sure, and it’s correct.
I then tried disabling the seconds on the systray clock and the realtime CPU monitor I have there, seeing perhaps if these were keeping the CPU from entering a deeper power saving state. I’d seen a post that indicated that in GNOME, simply reducing the cursor flash rate can reduce the wakeups per second of the CPU and increase battery run tume. I decided to disable the things that made use of a timer for the updates in the same manner, which immediately brought those two things to mind. On that test, my notes say 34.5 minutes, and the screenshot doesn’t include the seconds, so I have to consider it rounded to the nearest quarter minute.
There are a few things we can take away from this.
First, the methodology seems valid, given how repeatable they were. In two identical tests, I got the same result to the second. A third repetition with a few minor changes came in within about 15 seconds of the first two.
Second, there was no discernible difference between Linux and Windows when running the same test, which I did twice. On SMplayer, which is only able to play the unencrypted video, the run time was about a minute longer in Linux, while the encrypted Waterfox test was 16 seconds better in Windows. Previous video playback tests on Linux and Windows have shown that Windows had a significant advantage in battery run time, so this is quite a nice thing. The Linux kernel, Ubuntu, and KDE devs have made significant effort to improve Linux’s power management, and it shows. While it will still be necessary to play unencrypted videos in dedicated media players in order to do it, it does not appear that there will be any loss in run time while streaming videos on battery power, on my Swift at least.
Third, the HAVD unencrypted video in Chromium on Linux did increase the run time by a significant margin (from 26 to 32 minutes), which was as expected, but what surprises me was that I got the same result with the encrypted video, from 24 minutes to 30 minutes. I’ve read in several places that the Widevine plugin for browsers precludes hardware acceleration and always uses the CPU for decoding, but if that were true, I would not expect to see any improvement with the run time by turning on HAVD.
To be certain, I repeated the encrypted video tests on Chromium with HAVD on and off and found the same large gap.
That led me to think: Perhaps the issue here is that the patching to enable the hardware acceleration somehow harms the unaccelerated mode? That was the reason for test 11, which demonstrated that the unpatched Chromium is just as bad with the run time as the patched one with the HAVD feature disabled. Oddly, Vivaldi, which is based on the same Chromium base version as the unpatched Chromium used for the test, scored significantly better on the same test. I would have expected it to produce the same result, but it didn’t. Something’s different about the Vivaldi version of Chromium, though I have no idea what that may be.
The big performance gap between HAVD-enabled and HAVD-disabled while streaming encrypted videos was not seen in Waterfox, where the times were nearly identical using Waterfox on Linux (which has no HAVD) and on Windows (which has HAVD). That’s what I would have expected… why there was an increase in performance in Chromium when acceleration was enabled on encrypted streams is an open question.
Fourth, Waterfox with hardware decoding acceleration disabled (as that is the only option in Waterfox on Linux) significantly bests the time of Chromium with acceleration disabled on the same platform. Chromium with HAVD enabled ran 10 seconds shorter than Waterfox with encrypted video, and 1 minute, 45 seconds shorter with the unencrypted video. That was not the result I had expected! I’d read about how Chromium had improved so much in its battery run time, but perhaps that only applied to Windows versions (with HAVD fully enabled, unlike even the patched Linux version). Enabling the HAVD feature only allowed Chromium to get into the ballpark of what Waterfox offers in terms of run time.
Fifth, Waterfox with full HAVD on Windows with the unencrypted video got pretty close to the run time of the dedicated media player, at 41 min, 30 seconds and 43 minutes, 30 seconds respectively.
Clearly, as things stand with the configuration I now have on the Swift, Chromium’s HAVD on Linux still leaves much to be desired. It does seem to reduce the CPU utilization, but my system tray widget that shows CPU utilization doesn’t have the same feature for GPU utilization, and clearly that’s going to increase power demands too. The poor state of HAVD in Linux Chromium could change pretty quickly as the Mojo decoder continues development, though there have not yet been any announcements about whether Google or Mozilla have any near-term plans to begin bringing HAVD to Linux, finally. Clearly, it is possible, as SMPlayer and VLC do it brilliantly, equally so in Linux and Windows.
If these results are accurate, it appears that Linux as tested is just as viable for streaming videos on battery power as Windows, on my Swift at least. For unencrypted videos, like those on standard Youtube, it is necessary to use media players like SMPlayer to get the best run-times, but that’s easy to do. I have an addon in Waterfox that launches SMPlayer with the current page’s video with the click of a touchpad, which is pretty painless. I’d rather be able to do it in the browser directly without losing a lot of battery life, and maybe someday that will happen, but for now, this is a pretty good workaround.
With encrypted videos, using dedicated media players is not possible (at least not the ones I have tried), but even then, the run time of Waterfox on Linux was as good as on Windows, so there is no loss in run time on Linux there either.
Since the same encryption schema is used by Netflix and many other similar content providers, this will be the pertinent test configuration to estimate how much streaming is possible before the battery runs out. (It should be noted that pirated, unencrypted video will have the same run-time advantages as the unencrypted streams here. I’m not recommending anyone do that, but it might be something the content creators/copyright holders may want to consider before encumbering their videos with battery-busting encryption. The pirate videos do exist, so the encryption didn’t do what it was meant to do, which was to prevent pirates from getting ahold of it, so why make the experience so much worse for your legit customers than the pirates? Using an encrypting service like Netflix takes nearly a third of the run time away on batteries as compared to the same stream unencrypted. That’s a lot!
I don’t blame Netflix and the like for this… it’s something the creators and copyright holders of the content that insist on this, futile and counterproductive as it may be. It only takes one individual to successfully “crack” the protection, and as soon as he does, that version will be spread far and wide, at the speed of the internet, so the argument that it stops “most” pirates isn’t going to work. It either stops 100% of them or it fails completely… there’s no middle ground.
Dell XPS 13/9310, i5-1135G7/16GB, KDE Neon 6.2
XPG Xenia 15, i7-9750H/32GB & GTX1660ti, Kubuntu 24.04
Acer Swift Go 14, i5-1335U/16GB, Kubuntu 24.04 (and Win 11)
-
This topic was modified 5 years, 4 months ago by
.
-
This topic was modified 5 years, 4 months ago by
