Replies: 3 comments
-
I generally do not partake in discussions, since I mostly comment on GitHub via ForkHub (a discontinued GitHub client for Android) which does not support discussions, and as such, when an issue is converted to a discussion, it just shows me that it was locked up to collaborators, with no way to interact with it any longer, so any replies from me may be delayed. |
Beta Was this translation helpful? Give feedback.
-
Google isn't such much against Linux, it's just not worth it for them to invest that much time and effort into getting it working as there are so many possible configurations and even the drivers have problems (NVIDIA's VA-API implementation is so problematic that Chromium has VA-API support explicitly blocklisted when using NVIDIA drivers, INTEL-MESA recently had issues that caused many apps to crash on launch, not just Chromium ones), so VA-API support in Chromium is very much community maintained and supported, which is why it is still very much work-in-progress. FreeTube automatically enables VA-API support on Linux, but as your setup is rather exotic, you will likely have to experiment with various flags until you find something that works, if you find something that works. Also the reason you found no way to run FreeTube headless is because that doesn't exist and implementing something like that would require a major rewrite of the app (turning it from a purely client side app with Electron integrations into a client-server app, with certain functionality disabled outside of Electron due to the lack of Electron integration), with significantly increased maintenance and support burden, so it will likely never happen. It is easier just to self-host an Invidious or Piped instance if you want something like that. |
Beta Was this translation helpful? Give feedback.
-
Sorry about that, this was my opinion after seeing Google's actions against multiple different features when it came to Chromium, whether they came from Microsoft (system resource utilization efficiency), the community (GPU offload improvements), or even joint efforts that bizarrely Goggle is part of (JXL), not to mention their manifest v3 shenanigans. Regarding the rest, you are quite correct, which is why I hope that Crocus will help in that regard (though on AMD hardware, I am not seeing any improvement with amdgpu). While personally I do not see anything exotic about my setup (Solus generally tries to stick to upstream defaults, unless they are broken), I can certainly understand why it could be. In regards to the headless option, that is quite understandable. Interestingly, I had just checked with Vivaldi, where GPU offload is also supposed to work (and is verified as such in vivaldi://gpu), however even there GPU offload isn't working. I guess I'll check with others about this, and once GPU offload works in Vivaldi, I'll check again on FreeTube. By the way, since people had complained about YouTube serving them the wrong codec on FreeTube, I checked, and the same started to happen to me, sometimes AVC, sometimes VP9 and sometimes AV1 (on the website, only AV1 is being served, unless I use h264ify to block AV1 and VP9), even with the legacy codec option set, though with that I only get 320p in any case. |
Beta Was this translation helpful? Give feedback.
-
Currently there are many devices (mostly old, but also some ultra budget) devices with CPUs that are too weak to render even 720p30 videos via software (such as pretty much every laptop and tablet that originally came with only 2GB of RAM, although there are also some that came with more (but soldered)), but whose GPUs are able to render even 1080p30 (some also 1080p60 or even 1440p), like our old deChromeified Chromebook (Acer CB3-131, currently with MrChromebox's UEFI firmware, running Solus Budgie, I may switch it over to Budgie XFCE in the future).
Unfortunately, due to Google's vehemency against desktop Linux that is not under their control (so ChromeOS and Android are excluded), GPU offload (a.k.a. hardware acceleration) is particularly hard to get working under Linux (not this is an easy task, on any OS on Chromium, and by extension, Electron, but alternative solutions have it mostly figured out in a manner that allows clients, such as other apps, to support GPU offload via the existing libraries (Mozilla did this, after backlash from the community due to them breaking GPU offload support when switching from Cairo to Skia, by relying upon FFMPEG, relatively quickly, with other desktop apps supporting this very quickly by relying upon different libraries that can interact with protocols such as VA-API, including, but not limited to, FFMPEG), which is why Electron's GPU offload support under Linux regularly keeps on breaking, with the flags changing more often than they should, despite also relying upon FFMPEG (the breakage originates from the Chromium/Electron side, not the FFMPEG side).
This understandably affects FreeTube, which relies upon Electron, and as such even on 720p30 with AVC (the Celeron N2840's Intel HD Graphics Gen7 (not to be confused with 7th Gen Intel Core, this is the GPU generation, not the CPU generation) does not support VP9, but does support both H.264/AVC and VP8, though that is irrelevant to software rendering) around half of the frames are dropped.
Since I was using the portable version of FreeTube (this is for testing, until FreeTube gets accepted for packaging for Solus), after reading the issues here, I decided to try the PWA version of the Android Cordova fork (since I did not yet find a way of running upstream FreeTube headless, with the UI in Firefox) on Firefox, except that the LocalAPI functionality is missing from the latest versions there (it is on the 0.20.x versions, however that is too old to work), and so is currently not viable either.
Beta Was this translation helpful? Give feedback.
All reactions