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
  • Firefox video decode acceleration… how did I miss this?

    Posted on Ascaris Comment on the AskWoody Lounge

    Home Forums AskWoody support Non-Windows operating systems Linux – all distros Firefox video decode acceleration… how did I miss this?

    • This topic has 1 reply, 1 voice, and was last updated 1 month ago.
    Viewing 1 reply thread
    • Author
      Posts
      • #2297265 Reply
        Ascaris
        AskWoody_MVP

        If you want to skip the intro and get to the meat of it, scroll down until you see the wide gap between paragraphs.

        In Linux, the standard hardware video decoding API for non-nVidia GPUs is VAAPI, or Video Acceleration API. This is the one used by Intel, AMD, and I believe the open-source (but poor quality, thanks to nVidia’s lack of cooperation) Nouveau drivers for nVidia.

        The nVidia proprietary drivers are the odd ones out. They do not support VAAPI, but instead use VDPAU.

        There are VDPAU to VAAPI bridge drivers that allow VAAPI to work with nVidia proprietary drivers, but I do not know how well they work. I’ve seen reports both ways. While I do use the nVidia proprietary drivers on my desktop and my Dell G3 laptop, I never investigated video acceleration with them, as they are both quick enough to render the videos in software without any problems.

        The Swift is the exception. Not only is it the only one whose battery life is a real issue, where the lower CPU usage of the hardware-accelerated decoding substantially improves battery life, but it’s also the only one of my main three PCs that cannot handle decoding a 1080p video at 60 fps in software.

        I use the same video for testing all of the hardware accelerated video decoding stuff on the G3. It’s “Costa Rica in 4k” on Youtube. One of the versions of that video is 1080p60, and it definitely shows if hardware acceleration is working on the Swift.

        Chromium for Linux has long had most of the hardware acceleration code already in place, as I understand, since Linux Chromium is the base of Chrome in Chromebooks, which do have hardware video acceleration. They’ve refused to turn it on, though, citing compatibility issues (generally surrounding nVidia). I don’t know why they insist on hardcoding it to OFF when it is behind a flag anyway, so it won’t affect regular people who don’t deliberately enable it.

        Patches to enable VAAPI in Chromium were created and submitted to Google, but they never accepted them. Chromium is open source, though, so alternative versions with VAAPI enabled were created. In Ubuntu and derivatives, the place to get these builds has been the saiarcot895 PPA. It’s the base Chromium build, not yet Googled, but with the VAAPI patch.

        When I heard about the hardware accelerated version, I installed it from the PPA above (on the Swift). After I enabled the flag, Chromium was able to render the video in 1080p60, nice and smooth. It was, as far as I was concerned, good enough to where it should at least be offered as a possibility behind a flag. If it worked even in a minority of cases as well as it did for me, it would still be worth it as an opt-in.

        Fedora and OpenSUSE both patched the versions of Chromium they offer in their own repos to enable the feature. At least one of them tried to enable it by default, but they had to back off from that as the bugs that Google was worried about surfaced. Best to have it available, but off by default, they concluded.

        In the more recent Chromium builds, though, the hardware acceleration has taken a hit. The smoothness it had before on the Swift is gone, and it freezes for a few hundred ms every couple of seconds, with lots of frames dropped. This coincides with the changeover from their old internal media player to the newer one, called Mojo, if I recall, and it’s not as good on my Swift as the old one was.

        I’ve been hoping that Vivaldi would eventually respond to their users’ requests to implement the patch into their Chromium-based browser, but every time I checked back, no progress had been made on the customer requests.

        The best video hardware decoding on Linux has been from media players like VLC and MPV. They deliver the same super-smooth video as the old Chromium player, but with less CPU usage (which means less heat and more battery life). My solution has been to use Waterfox to choose the video, then use the “open in VLC” extension to open it in the media player. Despite the name, it does not have to be VLC, and I have found I like SMPlayer with MPV as the backend more than VLC.

        Then, today, on the Waterfox Github site, I happened to see a request to bring VAAPI video decoding to Waterfox (current), and I thought…well, that would be something! I knew Mozilla had mentioned that they were working on it, but they’re working on a lot of things. It could be a while, I thought.

        I looked at the request, though, and it said that Firefox 80 for Linux already had VAAPI capability, ready to go, with just a few settings to turn it on!

        The post listed these prefs to enable (off by default):

        media.ffmpeg.dmabuf-textures.enabled
        media.ffmpeg.vaapi.enabled

        And one to toggle off (on by default):

        media.ffvpx.enabled

        Finally, set the following environment variable (for X11):

        MOZ_X11_EGL=1

        Or for Wayland:

        MOZ_ENABLE_WAYLAND=1

        (slightly more detailed instructions available via the link)

        I did these on my Swift, then restarted Firefox, and went to “Costa Rica in 4k” on Youtube and set the video quality to 1080p60.

        The result was unmistakable. It was smooth and beautiful, just the way it should be. I let it finish the whole video looking for choppiness or stuttering, and there was none. It’s as good as the Chromium version used to be visually, and I’ll have to wait and see how it compares on power consumption. I had the video full screen while it was playing, so I could not see my tray icon that shows the CPU usage. That will be one of the next steps, though, for sure!

        I’m surprised that the feature is actually present in not only a release version of a major browser, but in Firefox, and I’m just now learning about it! I’ve been waiting and wishing for this for so long… I don’t like Chromium, so even when it had the better video player internally, it was no substitute for Waterfox.

        Firefox is becoming my main browser again, it looks like. Not just this, but also I am noticing that more and more sites are failing to work properly with Waterfox Classic, and spoofing the useragent does not work as reliably as it did. It’s becoming more normal for it to actually fail on a missing-feature basis rather than by useragent sniffing. The new Reddit is one such site, and so is Youtube if I spoof the useragent to a recent version of Firefox. The Kroger grocery store site does not work reliably with Waterfox Classic either (specifically, the sign-in for ordering groceries online fails most of the time, regardless of whether I have my addons loaded or not, while it works every time in Firefox).

        On top of that, there’s the newfound performance of Firefox, which in my last test actually bested Chromium on SpeeDOMeter 2.0 for the first time just a few weeks ago. Waterfox has always been fast enough given all its other advantages, but with sites failing to work as they are, the speed boost is a push toward Firefox again, particularly on the Swift (a faster browser should mean better battery life, all else being equal). Fortunately, with Aris’ custom userChrome.css modifications, it looks like Firefox should. I just hope they don’t target that as the next important feature to eradicate… there have been so many things I value that have been removed, and that one would be among the worst, on par with losing the Classic addons.

        Group "L" (KDE Neon Linux, User Edition).

        2 users thanked author for this post.
      • #2297780 Reply
        Ascaris
        AskWoody_MVP

        I just did the first power consumption tests playing videos with the new hardware-accelerated decoding in Firefox. I tested it against a dedicated media player (SMPlayer, MPV backend) and against the unaccelerated decoding in Waterfox Classic.

        I did this on the Acer Swift, as it is the laptop I use on battery frequently, so it’s the one where the power consumption matters the most. It’s also the only one of my main PCs that can’t easily decode a 1080p60 video in software, so hardware acceleration is a must.

        The Swift is running Fedora 32, 5.8.9 kernel, Mesa 20.1.7 (modesetting) for video, and the Intel Media Driver 20.1.1 for the VAAPI video hardware acceleration.

        Firefox version is 80.0.1, Waterfox is 2020.08.1, and is SMPlayer 20.4.2, using MPV 0.32.0 as the backend.

        I used Intel’s Powertop utility to measure the power consumption while playing the Costa Rica in 4k video from start to finish (though I did it at 1080p60). The length of the video corresponds with 12 “clicks” of Powertop, each with its own power consumption in joules. I simply added the 12 for each of the three runs.

        First, I played the video on Firefox. It used a total of 2582 J playing the ~5 minute video.

        Next up was SMPlayer. It used noticeably less energy, for a total of 2016 J.

        Finally, I ran Waterfox, the unaccelerated example. There were a lot of stutters and dropped frames, though it was better than expected. The energy consumption surprised me… it was 2531 J, slightly less than the hardware accelerated Firefox (though probably within the margin for error). The power consumption was more front-loaded in this test, with the first of the 12 readings being quite a bit higher than the rest of them, where the hardware-accelerated runs were more even.

        I was surprised that the hardware-accelerated Firefox test did not net any power savings at all, and in fact used more power than the unaccelerated Waterfox. I guess at some level it makes sense, given that a lot fewer frames were being rendered. I am thinking that with a faster PC that was able to render them all, the power consumption may have been higher for the unaccelerated video. I’ll have to repeat the test on the G3 (in order to get the joule readings, it is necessary to be running on the internal battery, so it would not work with the desktop).

        So, when running on battery, I will still watch the various videos in SMPlayer. It’s easy to do, as I have an addon that makes an icon pop up when a video is playing, and if I press that, it launches that video in SMPlayer. I keep Firefox/Waterfox in the click to play mode, so it gives me a chance to press the button for SMPlayer before it starts.

        When running on AC, I might as well watch the videos in Firefox itself. That wasn’t possible before with higher resolution videos, at least not in a really usable form.

        I will certainly keep watching this as Mozilla progresses with their Linux hardware decode acceleration.

        Group "L" (KDE Neon Linux, User Edition).

    Viewing 1 reply thread

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

    Reply To: Firefox video decode acceleration… how did I miss this?

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