Hardware acceleration

[cihlarma]

I don't know what media player back-end FreeTube uses so I don't know what it would take to implement this, but I would like to see hardware-accelerated video playback added. This is especially desirable on portable devices like the PinePhone or even simply laptops, which cannot afford to have their CPU's highly taxed for extended periods of time due to thermals and battery usage.

[PrestonN]

Unfortunately, I cannot do this.

FreeTube is built using Electron, which is a Chromium base for creating desktop applications. Video acceleration is not supported for Electron, which means that I cannot support it for FreeTube.

The best work around that I've seen would be allowing FreeTube to redirect a video over to a player such as VLC or MPV so that we can take advantage of their hardware acceleration features, which is something that I'm hoping to do at some point.

For now, the best luck I've had with watching videos on the Pinephone has been switching to the legacy formats and setting your default quality to 360p. Videos play pretty well with those settings, though obviously it isn't the highest quality.

Apologies for the inconvenience.

[cihlarma]

I just realized, what about VAAPI? Is support for that mainlined into Electron or does it have to be patched in? Or how about having mpv as backend for the media player as an option?

As for using legacy format, that seems to work better than DASH: the PinePhone can smoothly play 720p videos on legacy whereas 720p on DASH stutters.

[PrestonN]

I can look into it, however implementing that library would be a huge undertaking to do. I also do not plan on focusing on Pinephone optimizations right now so this isn't a priority.

I will say that if it allows proper video acceleration within Electron, then I would definitely like to consider including it at some point.

[fabianski7]

From what I found, it is possible to build the electron using the flag use_vaapi = true to enable hardware acceleration support, and then run it with --enable-accelerated-video. have you tried this @PrestonN?

https://github.com/electron/electron/issues/18942 https://github.com/electron/electron/pull/19736 https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=electron-ozone https://github.com/electron/electron/issues/6864

No one can blame freetube for not having this, because chromium and firefox do not have support enabled by default, but at least it is possible to activate them manually and it helps a lot when it is necessary to load a video that requires more of the hardware, such as a 1080p60

[PrestonN]

Going through your linked issues as well as some other links mentioned in those threads, it seems that Chrome (and by extension Chromium) has enabled the use_vaapi = true in v88. The latest Electron release (v11 at this time) is still using Chromium v87. Electron v12 is looking like it'll be shipping with at least v89 so once that comes out we may be able to look into supporting this without any special builds of Electron. I'll keep an eye on it when the new release is ready.

[fabianski7]

Electron v12 is looking like it'll be shipping with at least v89

it is finally available 🥳 https://github.com/electron/electron/releases/tag/v12.0.0

[PrestonN]

I've updated to Electron 12 and enabled enable-accelerated-video along with the ignore-gpu-blacklist flags into the nightly builds. Let me know if this works. I tested a little bit on a RPi4 and wasn't able to notice any improvements. It's possible that I didn't set the flags properly so I'm open to suggestions.

[fabianski7]

I tested a little bit on a RPi4 and wasn't able to notice any improvements

did you check if the gpu was actually being used to decode the video? Perhaps gputop is useful.

in case your hardware is not compatible with VP8/VP9, then this may have to be resolved before https://github.com/FreeTubeApp/FreeTube/issues/504

https://wiki.archlinux.org/index.php/Hardware_video_acceleration#Verification https://wiki.archlinux.org/index.php/Chromium#Hardware_video_acceleration

[cihlarma]

I'm not even sure RPi 4 supports VAAPI at all. From what I could gather, it uses something called MMAL and while you can enable HW accel on Chromium, I'm thinking maybe Raspbian has Chromium compiled with downstream patches to add support for this, much like their builds of ffmpeg and VLC do.

EDIT: I also tried testing it on the PinePhone and my PC and saw no difference. I suspect the PinePhone doesn't have hardware acceleration working yet, and after a closer look and some tests, it looks like my NVidia Maxwell GPU can't do VAAPI either...

EDIT2: You know what, I take that back: 0.12.0 on the PinePhone (Manjaro unstable branch) plays 720p, both DASH and legacy, beautifully. 1080p still stutters like 720p used to, maybe a little less, but that's fine since the PP screen is only 720px vertically. Big thumbs up @PrestonN!

[Zebrazilla]

Just stopping by to say that nightly with hardware accel fixed all issues I was having with micro stutters, videos are now completely smooth at proper framerate as far as I can tell. This is on Windows 11, a Surface Go 3, 4 GB RAM.

[Massimo-B]

As of today, is VAAPI supported by Freetube or are there plans to support it?

[Revival8697]

As of today, is VAAPI supported by Freetube or are there plans to support it?

Hey, I just checked and hardware acceleration is working. This is implemented by Electron, mentioned in https://github.com/lbryio/lbry-desktop/issues/7573. You can make it permanent, taken from Manjaro guide: cp /usr/share/applications/freetube.desktop ~/.local/share/applications/freetube.desktop Then you can edit the file (I use micro as my editor of choice) with micro ~/.local/share/applications/freetube.desktop, the line Exec=freetube %U to Exec=freetube %U --ignore-gpu-blocklist --enable-zero-copy --enable-features=VaapiVideoDecoder --disable-features=UseChromeOSDirectVideoDecoder --use-gl=egl --ozone-platform-hint=x11. I haven't figure out how to make it run on native Wayland on my PC yet. Instructions may vary on different distros.

[Massimo-B]

Thanks, while that sounds promising it doesn't work here. I checked via pgrep -alf freetube |grep Vaap and the option is really set. But nothing to see about Video acceleration in intel_gpu_top, only Render/3D. In STDOUT I noticed:

$ xdg-open /home/mb/.local/share/applications/freetube.desktop
xdg-settings: default-url-scheme-handler not implemented for xfce
[28496:0901/140041.031338:ERROR:object_proxy.cc(623)] Failed to call method: org.freedesktop.DBus.Properties.Get: object_path= /org/freedesktop/portal/desktop: org.freedesktop.DBus.Error.InvalidArgs: No such interface “org.freedesktop.portal.FileChooser”
[28496:0901/140041.031374:ERROR:select_file_dialog_linux_portal.cc(242)] Failed to read portal version property
[28539:0901/140041.118279:ERROR:gpu_init.cc(521)] Passthrough is not supported, GL is desktop, ANGLE is 
TypeError: Cannot destructure property 'value' of 'object null' as it is null.
    at /opt/FreeTube/resources/app.asar/dist/main.js:2:240841
    at async _ (/opt/FreeTube/resources/app.asar/dist/main.js:2:240797)
    at async App.<anonymous> (/opt/FreeTube/resources/app.asar/dist/main.js:2:247098)
(node:28496) UnhandledPromiseRejectionWarning: Error: Cannot create a secure cookie from an insecure URL
(Use `freetube --trace-warnings ...` to show where the warning was created)
(node:28496) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:28496) UnhandledPromiseRejectionWarning: Error: Cannot create a secure cookie from an insecure URL
(node:28496) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 2)
[28496:0901/140042.247197:ERROR:nss_util.cc(349)] After loading Root Certs, loaded==false: NSS error code: -8018
[28539:0901/140116.271509:ERROR:vaapi_wrapper.cc(2690)] vaPutSurface failed, VA error: invalid parameter
[28539:0901/140116.271639:ERROR:vaapi_video_decode_accelerator.cc(286)] Failed putting surface into pixmap

$ grep Vaap /home/mb/.local/share/applications/freetube.desktop
Exec=/opt/FreeTube/freetube %U to Exec=freetube %U --ignore-gpu-blocklist --enable-gpu-rasterization --enable-zero-copy --enable-features=VaapiVideoDecoder --disable-features=UseChromeOSDirectVideoDecoder --use-gl=desktop

[Revival8697]

Thanks, while that sounds promising it doesn't work here. I checked via pgrep -alf freetube |grep Vaap and the option is really set. But nothing to see about Video acceleration in intel_gpu_top, only Render/3D. In STDOUT I noticed:

$ xdg-open /home/mb/.local/share/applications/freetube.desktop
xdg-settings: default-url-scheme-handler not implemented for xfce
[28496:0901/140041.031338:ERROR:object_proxy.cc(623)] Failed to call method: org.freedesktop.DBus.Properties.Get: object_path= /org/freedesktop/portal/desktop: org.freedesktop.DBus.Error.InvalidArgs: No such interface “org.freedesktop.portal.FileChooser”
[28496:0901/140041.031374:ERROR:select_file_dialog_linux_portal.cc(242)] Failed to read portal version property
[28539:0901/140041.118279:ERROR:gpu_init.cc(521)] Passthrough is not supported, GL is desktop, ANGLE is 
TypeError: Cannot destructure property 'value' of 'object null' as it is null.
    at /opt/FreeTube/resources/app.asar/dist/main.js:2:240841
    at async _ (/opt/FreeTube/resources/app.asar/dist/main.js:2:240797)
    at async App.<anonymous> (/opt/FreeTube/resources/app.asar/dist/main.js:2:247098)
(node:28496) UnhandledPromiseRejectionWarning: Error: Cannot create a secure cookie from an insecure URL
(Use `freetube --trace-warnings ...` to show where the warning was created)
(node:28496) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:28496) UnhandledPromiseRejectionWarning: Error: Cannot create a secure cookie from an insecure URL
(node:28496) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 2)
[28496:0901/140042.247197:ERROR:nss_util.cc(349)] After loading Root Certs, loaded==false: NSS error code: -8018
[28539:0901/140116.271509:ERROR:vaapi_wrapper.cc(2690)] vaPutSurface failed, VA error: invalid parameter
[28539:0901/140116.271639:ERROR:vaapi_video_decode_accelerator.cc(286)] Failed putting surface into pixmap

$ grep Vaap /home/mb/.local/share/applications/freetube.desktop
Exec=/opt/FreeTube/freetube %U to Exec=freetube %U --ignore-gpu-blocklist --enable-gpu-rasterization --enable-zero-copy --enable-features=VaapiVideoDecoder --disable-features=UseChromeOSDirectVideoDecoder --use-gl=desktop

Sorry, the last flag is --use-gl=egl. Can you try again?

[read-0nly]

Just posting so that the next person googling can hopefully find this easier - Hardware acceleration, in particular @sp1cyf0x's parameter set, resolved black flickering issues for me in all but picture-in-picture if i stopped moving the mouse (seems to be the same issue mentioned by https://github.com/FreeTubeApp/FreeTube/issues/2012, i'm also windows 10).

[absidue]

@read-0nly Those flags are for linux, on Windows FreeTube already uses hardware acceleration (Linux is weird and has a million different setups, which is why different flags are needed for different people with their different setups).

On Windows graphical issues are usually caused by NVIDIA driver settings getting applied globally instead of to individual apps, see https://github.com/FreeTubeApp/FreeTube/issues/4184#issuecomment-1769299483 for more details.

[read-0nly]

@absidue then I have even less clue why it works lol, but it fixes the issue - i used the wrong shortcut that didn't have these flags this morning by accident and the flickering was back, closed and opened with those parameters, issue fixed

My issue is also not screen tearing, it's flickering to black

[absidue]

@read-0nly Did you check your NVIDIA settings as I suggested or does your computer not have an NVIDIA graphics card?

[read-0nly]

@absidue FXAA was in fact turned on, turning it off I get a single flicker to black on video play and then the video isn't flickering. That said, the flags do mysteriously also fix the issue without requiring changing settings

[Revival8697]

Hey, I just checked and hardware acceleration is working. This is implemented by Electron, mentioned in lbryio/lbry-desktop#7573. You can make it permanent, taken from Manjaro guide: cp /usr/share/applications/freetube.desktop ~/.local/share/applications/freetube.desktop Then you can edit the file (I use micro as my editor of choice) with micro ~/.local/share/applications/freetube.desktop, the line Exec=freetube %U to Exec=freetube %U --ignore-gpu-blocklist --enable-zero-copy --enable-features=VaapiVideoDecoder --disable-features=UseChromeOSDirectVideoDecoder --use-gl=egl --ozone-platform-hint=x11. I haven't figure out how to make it run on native Wayland on my PC yet. Instructions may vary on different distros.

Just updated this. Removed --enable-gpu-rasterization because it isn't needed on my system. Added --ozone-platform-hint=x11 because hardware video acceleration only work on X11/XWayland.

[Nb-tst]

Just to report that hw acceleration is working with these flags on a gen 9 intel iGpu, FreeTube 19.1 flatpak. Tested with intel_gpu_top.

flatpak run io.freetubeapp.FreeTube --enable-features=VaapiVideoDecoder --disable-features=UseChromeOSDirectVideoDecoder

This cpu/iGpu gen in unable to hw decode Av1 formats, so you have to disable the option in player settings.

[linlinxza]

Just to report that hw acceleration is working with these flags on a gen 9 intel iGpu, FreeTube 19.1 flatpak. Tested with intel_gpu_top.

flatpak run io.freetubeapp.FreeTube --enable-features=VaapiVideoDecoder --disable-features=UseChromeOSDirectVideoDecoder

This cpu/iGpu gen in unable to hw decode Av1 formats, so you have to disable the option in player settings.

I can confirm this also works with AMD GPUs too (my RX 580). Thanks for this. I really didn't think I could use this app because it was taxing the CPU more. And I can't get an external player (like a Flatpak of MPV) to work. But with the modified command, I can use this without the extra taxing of the CPU.

I know I have a Ryzen 5 CPU, but I really just don't want to hear the CPU fan spin up much at all because of the CPU being taxed in the slightest. Now FreeTube only uses about 2% CPU utilization while playing 1080 video.

The author of this app should have this in the instructions. Or an option in the settings to enable this.

[absidue]

The author of this app should have this in the instructions. Or an option in the settings to enable this.

@linlinxza

The problem is that as is typical with Linux, the many different setup require different flags, just take a look at this thread alone. If you can come up with a set of flags that work across all Linux machines, we can add them to FreeTube, otherwise it's better to leave it up to the user to figure out what combination of flags work for their specific Linux setup.

[linlinxza]

The author of this app should have this in the instructions. Or an option in the settings to enable this.

@linlinxza

The problem is that as is typical with Linux, the many different setup require different flags, just take a look at this thread alone. If you can come up with a set of flags that work across all Linux machines, we can add them to FreeTube, otherwise it's better to leave it up to the user to figure out what combination of flags work for their specific Linux setup.

Well, Flatpak is universal on any Linux distro. This command flatpak run io.freetubeapp.FreeTube --enable-features=VaapiVideoDecoder --disable-features=UseChromeOSDirectVideoDecoder could be at least added at least to the instructions if one wants to enable hardware acceleration.

Enabling just the Vaapi decoder fixes the hardware acceleration issue across the board on Linux in general. And Flatpak is more widely used as well. So, I think we have the flags we need.

[absidue]

@linlinxza Those aren't flatpak flags, flatpak passes those through to FreeTube where it gets picked up by Chromium. I'm pretty sure that flatpak makes no difference, because every thing else on the machine is different, so flatpak or not you will still have to use different flags on different machines.

[linlinxza]

@linlinxza Those aren't flatpak flags, flatpak passes those through to FreeTube where it gets picked up by Chromium. I'm pretty sure that flatpak makes no difference, because every thing else on the machine is different, so flatpak or not you will still have to use different flags on different machines.

Then if it makes no difference, then there is no problem. Again, enabling just the Vaapi decoder fixes the hardware acceleration issue across the board on Linux in general. And Chromium derivatives are also quite universal.

And these are used on Chromium in general actually (not Flatpak exclusive as you said):

--enable-features=VaapiVideoDecoder --disable-features=UseChromeOSDirectVideoDecoder

That's all we need enabled (also disabled) by default. Again, it's universal on Linux with anything Chromium based. Has nothing to do with the distro, nor the hardware. Yes, Nvidia also has Vaapi. And it's been proven that AMD and Intel are capable of doing the same.

So, given this, it shouldn't be all that hard to add in the instructions at least.

[Revival8697]

Then if it makes no difference, then there is no problem. Again, enabling just the Vaapi decoder fixes the hardware acceleration issue across the board on Linux in general. And Chromium derivatives are also quite universal.

And these are used on Chromium in general actually (not Flatpak exclusive as you said):

--enable-features=VaapiVideoDecoder --disable-features=UseChromeOSDirectVideoDecoder

That's all we need enabled (also disabled) by default. Again, it's universal on Linux with anything Chromium based. Has nothing to do with the distro, nor the hardware. Yes, Nvidia also has Vaapi. And it's been proven that AMD and Intel are capable of doing the same.

So, given this, it shouldn't be all that hard to add in the instructions at least.

These flags do not work for me so it is NOT "universal".

Though I do agree there should be some kind of instructions on the wiki instead of an Github issue like this.

I also wonder if Freetube can be made compatible with Wayland. Helpful resource: https://aur.archlinux.org/packages/chromium-wayland-vaapi.

[linlinxza]

Then if it makes no difference, then there is no problem. Again, enabling just the Vaapi decoder fixes the hardware acceleration issue across the board on Linux in general. And Chromium derivatives are also quite universal. And these are used on Chromium in general actually (not Flatpak exclusive as you said): --enable-features=VaapiVideoDecoder --disable-features=UseChromeOSDirectVideoDecoder That's all we need enabled (also disabled) by default. Again, it's universal on Linux with anything Chromium based. Has nothing to do with the distro, nor the hardware. Yes, Nvidia also has Vaapi. And it's been proven that AMD and Intel are capable of doing the same. So, given this, it shouldn't be all that hard to add in the instructions at least.

These flags do not work for me so it is NOT "universal".

Though I do agree there should be some kind of instructions on the wiki instead of an Github issue like this.

I also wonder if Freetube can be made compatible with Wayland. Helpful resource: https://aur.archlinux.org/packages/chromium-wayland-vaapi.

I am using Wayland right now; and it works with hardware acceleration. Still don't think it's universal? Why isn't universal? If you are running AMD or Intel graphics, it shouldn't be a frigging issue. But Nvidia users essentially still don't have next to any hope; especially on Wayland. Thank Nvidia for that. It's why I ditched them for AMD after all. lol

[Revival8697]

I am using Wayland right now; and it works with hardware acceleration. Still don't think it's universal? Why isn't universal? If you are running AMD or Intel graphics, it shouldn't be a frigging issue. But Nvidia users essentially still don't have and hope; especially on Wayland. lol

I'm running Intel, Wayland. FreeTube must run on XWayland for Hardware accerlation to work.

Also please don't double quote like this.

[linlinxza]

I'm running Intel, Wayland. FreeTube must run on XWayland for Hardware accerlation to work.

No shit. It uses XWayland on my system too. It works. With hardware acceleration. And I have it working on Intel systems too just fine with hardware acceleration.

[Revival8697]

No shit. It uses XWayland on my system too. It works. With hardware acceleration. And I have it working on Intel systems too just fine with hardware acceleration.

Yes. What I wondering if the same patches to Chromium can be added to FreeTube for native Wayland hardware acceleration to work.

[linlinxza]

Yes. What I wondering if the same patches to Chromium can be added to FreeTube for native Wayland hardware acceleration to work.

Here's an idea. instead of wondering, why not just try it when this app natively supports Wayland?

[Revival8697]

Here's an idea. instead of wondering, why not just try it when this app natively supports Wayland?

It doesn't work. I tried. I was wondering with the patches because I don't feel like compiling FreeTube at the momment.

[linlinxza]

It doesn't work. I tried. I was wondering with the patches because I don't feel like compiling FreeTube at the momment.

Then I don't know. I'm no dev. I just know how to use the command line. And with XWayland, those command line arguments do work. Because I don't see the CPU going crazy.

[Revival8697]

Then I don't know. I'm no dev. I just know how to use the command line. And with XWayland, those command line arguments do work. Because I don't see the CPU going crazy.

It is pretty interesting that you don't need --use-gl=egl, which is needed for Chromium below v112 (FreeTube currently use v108, a security risk BTW) though it it stated that the behavior might be different on AMD GPU.

Resources: https://wiki.archlinux.org/title/Chromium#Hardware_video_acceleration https://github.com/GoogleChrome/chrome-launcher/blob/e1d8d5b6d2a14b1a9e95713c6980076d454aa621/docs/chrome-flags-for-tools.md#rendering--gpu https://github.com/FreeTubeApp/FreeTube/releases/tag/v0.19.1-beta https://github.com/electron/electron/releases/tag/v22.0.0 https://www.electronjs.org/docs/latest/tutorial/electron-timelines

[linlinxza]

It is pretty interesting that you don't need --use-gl=egl, which is needed for Chromium below v112 (FreeTube currently use v108, a security risk BTW) though it it stated that the behavior might be different on AMD GPU.

Interestingly enough, adding --use-gl=egl causes the CPU to jump up to about 6% CPU with 1080p60 video. But without it, the max it uses is about 2%. Just tested it.

Anyway, I have a RX 580 paired with a Ryzen 5 5600G. And your hardware? Intel what?

[absidue]

(FreeTube currently use v108, a security risk BTW)

The latest stable release yes, but the nightlies use the up-to-date versions of Electron. Doing constant FreeTube releases, purely for the sake of upgrading Electron, would be annoying to users (remember that FreeTube doesn't have an automatic updater) and would use up valuable time that can be used to fix bugs and add new features (keep in mind that everyone that works on FreeTube is a volunteer and works on FreeTube in their spare time).

I'm not saying it's not a security risk, just that it's much smaller, because you are only accessing a limited list of domains and API endpoints and that if you are still really concerned, you can use the nightly builds.

[Revival8697]

Interestingly enough, adding --use-gl=egl causes the CPU to jump up to about 6% CPU with 1080p60 video. But without it, the max it uses is about 2%. Just tested it.

Anyway, I have a RX 580 paired with a Ryzen 5 5600G. And your hardware? Intel what?

Intel® UHD Graphics for 10th Gen Intel® Processors (Yes, I won't tell you which one, their feature set are the same anyway).

[linlinxza]

Intel® UHD Graphics for 10th Gen Intel® Processors (Yes, I won't tell you which one, their feature set are the same anyway).

Why? Stop being paranoid. lol

[Revival8697]

The latest stable release yes, but the nightlies use the up-to-date versions of Electron. Doing constant FreeTube releases, purely for the sake of upgrading Electron, would be annoying to users (remember that FreeTube doesn't have an automatic updater) and would use up valuable time that can be used to fix bugs and add new features (keep in mind that everyone that works on FreeTube is a volunteer and works on FreeTube in their spare time).

I'm not saying it's not a security risk, just that it's much smaller, because you are only accessing a limited list of domains and API endpoints and that if you are still really concerned, you can use the nightly builds.

Thanks for reminding me that nightly builds exist.

I just tested the latest nightly build and --enable-features=VaapiVideoDecodeLinuxGL just work. Wow, is that 1 universal flag I'm seeing? (Or will be, when this bug is fixed for AMD users, a patch exists.)

I do understand that keeping Electron up to date is not a priority. But when it is updated, this issue will be fully solved. I'm rooting for it!

[Revival8697]

Why? Stop being paranoid. lol

There is no harm in telling you. But there is no reason to tell you either.

[linlinxza]

There is no harm in telling you. But there is no reason to tell you either.

Right. Paranoid.

[Nb-tst]

Chromium is fixing vaapi for wayland. https://chromium-review.googlesource.com/c/chromium/src/+/3646633

Maybe a thread could be opened in discussion section to report and keep up to date flags to be used in order to enable HW acc. There won't be a universal fix, nonetheless with the flatpak version OS/Mesa combinations will be greatly reduced, and fixes should remain the same for a decent amount of time, until a new version of Electron is used by FreeTube.

[absidue]

Important to point out that even upstream considers Linux + VA-API unsupported.

Insofar as Linux + VA-API is not a supported platform (IOW it's a best effort) and this will allow developers and users to try and make it work on their machines.

[absidue]

Maybe a thread could be opened in discussion section to report and keep up to date flags to be used in order to enable HW acc. There won't be a universal fix, nonetheless with the flatpak version OS/Mesa combinations will be greatly reduced, and fixes should remain the same for a decent amount of time, until a new version of Electron is used by FreeTube.

Feel free to open a discussion for that, probably best if it's community maintained anyway, because the flag combinations seem to be different for different machines and setups.

[Revival8697]

Important to point out that even upstream considers Linux + VA-API unsupported.

Insofar as Linux + VA-API is not a supported platform (IOW it's a best effort) and this will allow developers and users to try and make it work on their machines.

But it works, and good enough for most users.

Upstream doesn't support it, but distros do, Chromium is compiled with VA-API support:

Arch Linux: https://wiki.archlinux.org/title/Chromium#Hardware_video_acceleration Fedora: https://fedoramagazine.org/chromium-on-fedora-finally-gets-vaapi-support Ubuntu (Ew snap): https://www.omgubuntu.co.uk/2023/05/chromium-snap-hardware-acceleration-beta

Also consider that upstream is a browser, while FreeTube is a YouTube client.

[Revival8697]

Feel free to open a discussion for that, probably best if it's community maintained anyway, because the flag combinations seem to be different for different machines and setups.

I made one: https://github.com/FreeTubeApp/FreeTube/discussions/4526. Feel free to contribute for other distros.

[absidue]

Upstream doesn't support it, but distros do, Chromium is compiled with VA-API support

The official FreeTube releases use the official Electron builds, so it doesn't really matter what different distros do. Maybe some of the unofficial release channels use custom builds of Electron, but if you want special stuff to happen there, then you need to reach out to the maintainers of those custom builds and those custom FreeTube releases.

Also consider that upstream is a browser, while FreeTube is a YouTube client.

Upstream is literally developed by the company that runs YouTube, which probably has a significantly larger percentage of developers that use Linux.

[Revival8697]

The official FreeTube releases use the official Electron builds, so it doesn't really matter what different distros do. Maybe some of the unofficial release channels use custom builds of Electron, but if you want special stuff to happen there, then you need to reach out to the maintainers of those custom builds and those custom FreeTube releases.

Official Chromium and Electron is compiled with VA-API support since https://github.com/FreeTubeApp/FreeTube/issues/961#issuecomment-789779236... That is how we can make hardware acceleration work with the correct flags.

Upstream is literally developed by the company that runs YouTube, which probably has a significantly larger percentage of developers that use Linux.

What I meant is that a browser doesn't have to have hardware acceleration to work.

No distro enable Chromium hardware acceleration OOTB either.

But FreeTube is a video player, hardware acceleration should be enabled OOTB, you don't have to consider upstream opinion here.

Anyway, just to clarify, FreeTube has already enabled hardware acceleration by default. But the flags are wrong/outdated.

I'm trying to fix the flags...

Yeah, I'm just gonna figure the flags out and make a pull request.

[absidue]

Please only add those flags on Linux (wrap it in an if), because everything works just fine with the existing flags on Windows and macOS, it's only Linux that is weird and requires constant special treatment.