tl;dr:
Hardware-accelerated video decoding and rendering can help make a 10.5-year-old desktop that much more usable, and it can reduce a Sandy Bridge Core i3 laptop's battery drain by up to 110%. Sucks that Linux web browsers can't use this by default.
A little background...
As many others on this board most likely do, I like to push older PC hardware to test its limits; take gear that's regarded as beyond its serviceable lifespan and see how usable it still is in the current day and age.
When it comes to PCs, "old" is a subjective term anyway, as those in an enterprise environment generally consider five years to be the asset depreciation lifespan, which is why there's been a glut of Sandy Bridge-based hardware in the used market while the amount of Ivy Bridge-based stuff is on the rise. On the other hand, average home users -- and by "average" I mean folks who're just as likely to purchase PCs from Costco or Walmart as they would Dell or HP -- have a tendency to keep their rigs from seven to ten years unless reacting to a disaster. So, when I get my mitts on such cast-offs, I'm keen to see what they can still do, and whether or not I can quietly snicker at the previous owner(s) for dumping it when they could have extended their ROI with a Linux distro and a little effort.
My most recent project (read: victim) is a Dell Dimension C521: a "slimline" desktop from Nov. of 2006 sporting an AM2-socketed Athlon 64 X2 4200+, 3 GB of DDR2-533, a 160 GB Samsung HD, and a 256 MB Radeon X1300 GPU. This machine was released from Dell's assembly line right at the trailing edge of the 64 X2s' price-to-performance dominance in the desktop market, as the first Core 2 Duo E6XXX chips had just been introduced in July of that same year.
As for how the C521 performed once I got it in my hands, I was happy to find that -- once I'd loaded Ubuntu Mate 16.04 on it (distro choice based on resale reception rather than personal preference) -- it was still perfectly competent for common day-to-day desktop usage as one would expect, at least after a few tweaks were performed in the web browsing arena (e.g., activating OpenGL compositing in both Firefox and Chrome while leaving desktop compositing off, then reducing the browsers' system load by way of uBlock Origin).
The only thing I wasn't satisfied with was web video performance. As is, the machine could handle 720p60 or 1080p30 YouTube playback well enough, providing one makes use of the h264ify extension and doesn't consider <1% dropped frames a problem. However, the high-res and/or high-fps playback absolutely beat the shit out of the CPU, making multitasking attempts a miserable experience while streaming video was playing.
The X1300 GPU doesn't have any usable H.264 decoding capabilities on Linux, so my luck peaked when I stumbled upon a number of 1 GB Radeon HD 7570 low-profile cards for $5 each at my favorite recycler's shop (residents of the greater-Seattle area, check 'em out if you haven't already). These cards have damn good hardware H.264 decoding for 1080p60 which can be utilized with the VDPAU Mesa driver, and coupling that with MPV, youtube-dl, and both the Disable HTML5 Autoplay and Watch With MPV addons for Firefox, the C521's usability jumped right back up the ladder to a satisfying experience. After squaring all of this away, I decided on turning the C521 into a 1080p Kodi HTPC once I'm done playing with it.
The part where I whimper about things I could do something about if I knew how to code, but don't and am therefore useless:
While running through all of the workarounds needed to use VDPAU for video playback, I found myself getting angry at the fact that hardware-accelerated video decoding couldn't be utilized in either Firefox or Chrome/Chromium on Linux, while it's something people are now taking for granted on Windows. The funny thing is that I remember being able to configure this in Chrome on my main rig within the last year or so, at least while running a GTX 960 GPU with the proprietary Nvidia drivers, but it no longer works. Some digging revealed that the functionality was dropped due to instability reasons and there appear to be no plans to reintroduce it anytime soon.
Now, there is a patched version of Chromium which is supposed to include VAAPI decoding support, but its functionality has been hit-or-miss depending on one's GPU/drivers (appears to favor Intel integrated GPUs), and trying this on the C521 failed when using the included vdpau-va-driver package, so no dice here. To make matters sting that much more, an attempt to build this patched Chromium on an Intel-based laptop from the AUR failed repeatedly, to the point of me giving up on it out of a combination of frustration and laziness.
On the Firefox side of things, hardware decoding has been in the works for more than two years, but progress has been slow to say the least... All things being what they are, the FF team hasn't gotten OpenGL compositing stable enough to have it active by default yet (even though I've never had a problem with it once manually activated), and that's one of the major roadblocks in the way of hardware decoding getting any real attention.
Reading through the FF OpenGL/hwaccel bug dependency tree, I started to understand the complexity of the tasks set before the devs, but it still irked me that the feature request is over two years old and will most likely remain open for two more years before it bears any fruit. Desktop Linux is still too much of a fringe concern for even an open-source based company to devote reasonable resources to this functionality. In my mind, it's another shortcoming of desktop Linux to add to the "people won't try it without XYZ" pile, right alongside sketchy MS Office document compatibility and nary a sideways glance from companies with popular creative software like Adobe. Same old, same old, grouch-grouch-grump-grump-gripe-gripe-belch.
Wherein I console myself by gathering metrics like a good nerd:
At this point, my simmering anger gave way to curiosity. The Dimension C521 is ultimately nothing more than a toy to me, but the laptop I mentioned -- a craptastic, plastic, Gateway-branded Acer with a Core i3-2348M and 4 GB of DDR3 RAM running Manjaro XFCE -- is definitely a tool, and one I use to distract myself with the occasional YouTube video on occasional breaks, at least while it's plugged into wall power. Watching video on this thing has always dropped my battery levels faster than a congressman's approval rating, so I figured I'd see what kind of power savings I'd get by using MPV with VAAPI decoding vs. Firefox playback.
To give myself an apples-to-apples baseline, I used youtube-dl to pull down the 1080p60 version of this video ('cause it's "pretty") using the 299+140 video+audio format codes (same as 1080p60 MP4 playback in the browser), then launched it from a terminal using mpv --vo=opengl --loop-file=4 [filename] for CPU decoding and OpenGL rendering while:
1. running on a fully-charged battery (4000 mA, BTW)
2. disconnected from ethernet and with wifi off
3. the screen at 50% brightness (right at my comfort zone on this laptop), and
4. the video played back in full-screen.
4 loops = 1:01:44 of playback time, and once it was done, my battery was down to 39% capacity. (61% drain after just over an hour of video? Yeesh!) After recharging, I ran the playback test again with the same settings, and the result was an even 60% drain, so I was seeing consistency within an acceptable margin of error.
After another recharge, I launched the video using mpv --vo=vaapi --hwdec=vaapi --loop-file=4 [filename] under the same conditions, and at the end of this run, my battery was only down 27%. A 27% drain?! That's a 55.37% decrease in battery usage over the average of the two CPU/OpenGL runs... Why the hell haven't I been using VAAPI on this laptop all along? Oh, silly, stupid me.
After yet another recharge, I re-ran the VAAPI test, this time increasing the loop count to 8 for a 2:03:28 run. This resulted in a 54% drain, meaning that VAAPI allows me twice as much video playback time while still giving me a 10.74% battery savings over an hour of CPU/OpenGL play. This I like. This I like quite a bit.
Let's get real with these tests, shall we?
The next day, I set out to check Firefox's actual battery drain while on YouTube, so I decided to shoot for full-screen, long-form video playback over wifi. The video I went with was Gamer's Little Playground's Titanfall 2 movie (which is just as "pretty" as the locally-cached test vid), sporting a 2:05:52 runtime. Thanks to the h264ify extension, the 1080p60 playback used the same 299+140 format codes as the previous day's tests, so all would remain apples-to-apples as I went forward. Concerning other variables, the only difference between the previous day's tests is that I dropped the video playback volume down to ~30% so it wouldn't bother me as it ran, and I had the laptop set to warn me when the battery reached 7% remaining, which I considered the test's end point if the video didn't reach its end first.
FF YouTube results: in-browser playback hit the battery's 7% limit in ~1:27:00 (rounded up to the nearest minute because I didn't notice the alert right away). Comparing this against the average of the previous day's 4-loop offline tests, the battery drain with wifi on was 8.31% greater per second of video playback, which didn't surprise me all that much. Time for a recharge and an MPV run.
For the sake of being thorough, I should note that I set up an mpv.conf file with a specific profile to use with the Watch With MPV extension (--profile=WatchWithMpv is the only option needed for the extension's "Additional Player Parameters" setting):
# ~/.config/mpv/mpv.conf
vo=vaapi,opengl
hwdec=vaapi
[WatchWithMpv]
quiet
log-file=~/Donwloads/WatchWithMpv.log
force-window=immediate
geometry=50%:50%
autofit=70%
ytdl
ytdl-format="299+140/298+140/137+140/22/http-1080/http-720/best/18/http-480/worst"You'll notice that there are a few additional format codes here, set to cover a few different bases for both YouTube and DailyMotion. I also have it set to generate a log file every time Watch With MPV is used. With that log, I was able to confirm MPV played the video back using the 299+140 format codes, and used VAAPI as both the decoder and the renderer.
MPV results: The video completed the full 2:05:52 playback with 36% battery remaining (64% drain). Comparing this to the offline MPV runs, the battery drain over wifi was oddly 13.99% greater per second, which I'd most likely chalk up to MPV's more aggressive handling of YouTube's DASH streams and local data caching. However, this playback method provided 110.23% better battery performance over the browser, leaving enough charge for just under an hour of more 1080p60 playback if I wanted to push it to the 7% remaining limit. God, I wish I'd set this up earlier...
So... what if Mozilla DID manage to get hardware decoding working in the browser, eh?
This question didn't pop into my head until I started writing this, and with it came an interesting point: Mozilla's shooting to implement VDPAU/VAAPI decoding all right, but they're also looking to use OpenGL rendering to display the video. Up to this point, I'd been using VAAPI decoding and rendering in my MPV setup, and it looks really damn good with the Core i3 HD3000 graphics' capabilities. OpenGL video rendering looks just as good, but it increases the laptop's CPU load somewhat... Not by an enormous amount, mind you, but enough to warrant one more test.
Time for a quick edit of my mpv.conf file, changing...
vo=vaapi,opengl
hwdec=vaapi...to...
vo=opengl
hwdec=vaapi...effectively moving the opengl fallback video-out setting to the forefront.
Once done, I ran the wifi MPV test one more time, and was pleased to find that the video playback made it through the full 2:05:52 with 31% battery remaining (69% drain). This means that OpenGL rendering adds a scant 7.25% more overhead to my YouTube experience over VAAPI, and it also means that VAAPI/OpenGL playback in Firefox might net a ~95% improved power savings for streaming video if the devs manage to get this shit working. Fingers crossed that some breakthrough will be made sooner than later.
Okay... so you've either managed to read through this whole mess or pretend you did, and now I'd like to know: Have you played around with hardware-accelerated video on your Linux laptop or gotten that patched Chromium to work? If so, what's your experience been like? Good battery savings to report? Video quality okay? Dish! Dish!
