News, tips, advice, support for Windows, Office, PCs & more. Tech help. No bull. We're community supported by donations from our Plus Members, and proud of it
Home icon Home icon Home icon Email icon RSS icon
  • Comparing video streaming results: Waterfox, Chromium; Windows, Linux

    Posted on Ascaris Comment on the AskWoody Lounge

    Home Forums AskWoody support Questions: Browsers and desktop software Other browsers Comparing video streaming results: Waterfox, Chromium; Windows, Linux

    This topic contains 5 replies, has 3 voices, and was last updated by  Ascaris 1 week, 1 day ago.

    • Author
      Posts
    • #2006783 Reply

      Ascaris
      AskWoody_MVP

      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.

      Group "L" (KDE Neon User Edition 5.17.4).

      • This topic was modified 3 weeks, 6 days ago by  Ascaris.
      • This topic was modified 3 weeks, 6 days ago by  Ascaris.
      1 user thanked author for this post.
    • #2007737 Reply

      OscarCP
      AskWoody Plus

      Ascaris: Thanks for taking the trouble to run all those tests. Considering that the differences in the time it took them to deplete the battery down to 90% charge was  sometimes longer for Waterfox than for Chromium, it looks like those who watch videos during trips in their laptops, for example, might be a little better off  doing it with Waterfox than with Chromium, whether running Windows or Linux. Have you looked at Chrome and Firefox in the same way, or are planning to?

      Windows 7 Professional, SP1, x64 Group B & macOS + Linux (Mint) => Win7 Group W + Mac&Lx

      • This reply was modified 3 weeks, 5 days ago by  OscarCP.
      • #2010131 Reply

        Ascaris
        AskWoody_MVP

        Chrome should be the same as Chromium, as the two are almost the same.  Still, it would be interesting to verify that.

        I have thought of trying Firefox (the current version, whatever it may be at the time… 70, for now).  I would expect it to be very close to Waterfox, but it’s worth a try to see what happens.

        Note that this is only one particular PC, and there might be some variations on other hardware setups. Chromium may be using code that is particularly ill-suited to my Swift’s Pentium N4200 (quad core) SoC, while a higher-end CPU from Intel or an AMD Ryzen may run that same code with relatively less power usage.  It could also be that the results I got will be seen in all the other CPUs too… it would take more testing (of those other systems) to know for sure.

        I was just pretty happy that Linux held its own with Windows.  The last time I tested them both head to head on this same laptop (also using the Big Buck Bunny film, which has sort of become a standard for these kinds of tests, since it’s not copyrighted and is offered in many formats), Windows ran for quite a bit longer vs. Kubuntu (I’m thinking it was 18.04).  If I recall, Windows 10 (not sure what build it was) was at about 6 hours and 45 minutes, while Kubuntu was a bit under 6 hours.  That was the total run time until the battery completely died, which I did not do this time not only because it is hard on the battery, but it is really time consuming, and it would have taken forever to do as many trials as I did.  In those cases, the movie was on the SSD, with either VLC or SMplayer on Linux, and either Windows Media Player or whatever MS had for video players in UWP.  It’s been a while, the details are fuzzy!

         

        Group "L" (KDE Neon User Edition 5.17.4).

        • #2011585 Reply

          Ascaris
          AskWoody_MVP

          I performed the unencrypted test with Firefox 70, with all the same settings as above, and it came on one second shy of 32 minutes even.  Waterfox did a bit over 34 minutes, but I can’t be sure that’s because Waterfox is a bit better, or if it was just a margin-of-error thing.  At the very least, Waterfox can be said to not be any worse than Firefox.

          Group "L" (KDE Neon User Edition 5.17.4).

        • #2015869 Reply

          Ascaris
          AskWoody_MVP

          I tried the unencrypted test with Opera 65.0 in the battery-saving mode.  The run time was 30 minutes, 23 seconds.  That was more than Chromium by a sizable margin, but didn’t quite match the performance of Vivaldi, which lacks a dedicated power-saving mode, and is also based on Chromium.  Firefox and Waterfox bested Opera in the power-saving mode handily.

          Note that this could change with different work loads.  The test the Opera people used to test the battery run-time wasn’t focused on video playback, but on general-purpose web browsing, including scrolling performance.  One of the functions of the low power mode is to reduce the Opera framerate to 30 fps, so it may save some power on scrolling.  The loss of smoothness is definitely noticeable, and I would like to be able to turn off the 30 fps mode and see how much the power savings would be affected, as it’s really very annoying.

          Group "L" (KDE Neon User Edition 5.17.4).

    • #2010139 Reply

      Using FF 70.0.1 with the below hardware, and it seems to huff and puff, and use more memory (and the longer you watch, it seems to use more) than Chrome did. Chrome did, however, tend to be less stable than FF on this system, for some odd reason; had BSOD’s watching streaming video with it a few times. Not so with FF.

      Just some-more grist for the exceedingly fine-grind mill. 🙂

      Win7 Pro SP1 64-bit, Dell Latitude E6330, Intel CORE i5 "Ivy Bridge", Group "Wait for the all-clear", Multiple Air-Gapped backup drives in different locations, "Don't check for updates-Full Manual Mode."
      --
      "...All the people, all the time..." (Peter Ustinov ad-lib from "Logan's Run")

      1 user thanked author for this post.

    Please follow the -Lounge Rules- no personal attacks, no swearing, and politics/religion are relegated to the Rants forum.

    Reply To: Comparing video streaming results: Waterfox, Chromium; Windows, Linux

    You can use BBCodes to format your content.
    Your account can't use Advanced BBCodes, they will be stripped before saving.