search

FreeTubeApp / FreeTube

An Open Source YouTube app for privacy
https://freetubeapp.io/
GNU Affero General Public License v3.0
13.06k stars 807 forks source link

[Bug]: Massive leap in CPU usage between 19.2 and 20.0, and another jump to 21.1 (on linux, not a hw accel or GPU issue). #5397

Open libv opened 1 month ago

libv commented 1 month ago

Guidelines

Describe the bug

This is a playback issue, there seems to be no difference between local API and invidious. Perhaps something is wrong with hw accel?

I have compared the same video, selected from history, same window size, same resolution, same playback speed, with back to back installs from the listed versions, sometimes restarting to make sure channel info and such is cached.

19.1: struggles to start a stream these days. real 3m51.779s user 1m27.945s sys 0m9.666s

19.2: real 3m41.153s user 1m33.223s --> comparison basis sys 0m10.070s

20.0: real 3m43.764s user 3m28.316s --> 2.2x more than 19.2 sys 0m11.600s

21.1: fails to play back with both local and invidious.

21.1beta: real 3m39.247s user 4m14.308s --> 2.7x more than 19.2 sys 0m9.562s

Expected Behavior

Broadly similar CPU usage.

Issue Labels

usability issue

FreeTube Version

v0.20.0

Operating System Version

Debian 11.6.0 (oldstable), amd64, 5.10-28 kernel. Intel 5th gen. i915.ko, xf86-video-modesetting, xfce.

Installation Method

.deb

Primary API used

Invidious API

Last Known Working FreeTube Version (If Any)

v19.2

Additional Information

No response

Nightly Build

mafclean commented 1 month ago

Describe the bug

Version 21.1 is taking "double" the resources while playing video. My normal CPU usage idle is between 6% and 8%. While FreeTube is playing in the foreground CPU usage went from constant 16% (v19.2) to constant 32% (v21.1). While FreeTube is playing in the background CPU usage went from constant 8% (v19.2) to constant 32% (v21.1) (peaking 40+%).

COMPARISON:

19.2 (a) (playing in foreground) 19 2 (1-frontground)

19.2 (b) (playing in background) 19 2 (2-background)

21.1 (a) (playing in foreground) 21 1 (1-frontground)

21.1 (b) (playing in background) 21 1 (2-background)

21.1 (c) (terminated) 21 1 (3-closed)

FreeTube Version

0.21.1-win-x64-portable

Operating System Version

Windows 10 version 1607 LTSB (OS Build 14393.2665), Intel Core i7 3517U / Intel HD Graphics 4000.

Installation Method

Portable

Primary API used:

Local API

Video Settings:

1080p @ 50 frames; full window inside the application (not fullscreen). Link of the video: https://www.youtube.com/watch?v=GKOFN9tf3nI

Additional Information:

I also noticed that on version 21.1 the window occlusion tracking (is this the correct name to call it?) was changed back to what it was as in older versions; that is: now video rendering do not stop while FreeTube is playing the video in the background (while window is minimized or not).

PS: I am not a developer and this is my first time posting on github. Forgive me for any mistakes and for being a newbie. If additional information is required, I will research more so to help.

absidue commented 1 month ago

Thank you both for you detailed analysis. I've created a test build based on 0.21.1 with the addition of the enable-accelerated-video-decode flag, if you have time could you please test it, to see if that improves the situation?

https://github.com/absidue/FreeTube/actions/runs/9927581696

libv commented 1 month ago

21.1beta: real 2m59.990s user 3m20.145s sys 0m7.815s

19.2 again: real 3m34.146s user 1m31.759s sys 0m9.871s

mafclean commented 1 month ago

Thank you both for you detailed analysis. I've created a test build based on 0.21.1 with the addition of the enable-accelerated-video-decode flag, if you have time could you please test it, to see if that improves the situation?

https://github.com/absidue/FreeTube/actions/runs/9927581696

And thank you, absidue, and all the FreeTube contributors for your hard work!

I tested this new version under the same circumstances as before, but now with three different and separated videos. The results were:

SCREENSHOTS

VIDEO A A-1) 1080p@24fps playing in the foreground: A-1) 1080p@24fps front

A-2) 1080p@24fps playing in the background: A-2) 1080p@24fps back

A-3) 1080p@24fps terminated: A-3) 1080p@24fps terminated

VIDEO B B-1) 1080p@50fps playing in the foreground: B-1) 1080p@50fps front

B-2) 1080p@50fps playing in the background: B-2) 1080p@50fps back

B-3) 1080p@50fps terminated: B-3) 1080p@50fps terminated

VIDEO C C-1) 1080p@60fps playing in the foreground: C-1) 1080p@60fps front

C-2) 1080p@60fps playing in the background: C-2) 1080p@60fps back

C-3) 1080p@60fps terminated: C-3) 1080p@60fps terminated

At your disposal.

libv commented 1 month ago

I tried a bisect between 0.19.x and 0.20.0 for several hours, and got nowhere, as suddenly all videos were being played with limited CPU usage. Since then i have noticed that in some instances, even with newer versions, there is limited CPU usage. So the culprit is likely hw accel, but it depends on the position of the planets whether VAAPI is used or not.

Is there a way for me to control this application properly and to get verbose output in some sense or form so i can try to see what it does or does not do in any shape?

At least with chromium you can go to chrome://gpu and get some info, with Freetube, nothing.

There seems to be no point in me bisecting again until i have some visibility.

libv commented 1 month ago

intel-gpu-top claims that there is no decoding acceleration being used at all, neither at 0.19.2 nor 0.21.2. And yet the difference in cpu usage is massive.

absidue commented 1 month ago

@libv You can view the chrome://gpu page in FreeTube like this:

  1. Open the dev tools with CTRL+SHIFT+I
  2. Paste this snippet into the console tab and hit enter: require('electron').ipcRenderer.send('create-new-window', { windowStartupUrl: 'chrome://gpu' })
  3. A new window will open with the chrome://gpu page.
libv commented 1 month ago

I have spent quite some time formatting the v0.19.2 output to something resembling the later ones, so a diff can be produced.

Files: freetube-v0.19.2.about-gpu.txt freetube-v0.20.0.about-gpu.txt freetube-v0.21.2.about-gpu.txt

Diffs: freetube-v0.19.2_vs_v0.20.0.about-gpu.diff.txt freetube-v0.19.2_vs_v0.21.2.about-gpu.diff.txt

xsmile commented 4 weeks ago

@libv Acceleration is disabled on both 0.20.0 and 0.21.2 in your case:

 Video Acceleration Information
 ==============================
 Decoding: 
-Decode h264 baseline: 16x16 to 4096x4096 pixels
-Decode h264 main    : 16x16 to 4096x4096 pixels
-Decode h264 high    : 16x16 to 4096x4096 pixels
-Decode vp8          : 16x16 to 4096x4096 pixels

You can verify it for the currently active video with the following steps:

Does it work with Chromium? You will need to manually enable VA-API using command line parameters. If not, then there is probably not much freetube can do about it.

ngocphamm commented 4 weeks ago

@absidue What would be the proper value for macOS if it is to use hardware acleration?

I have 1 Mac Intel and 1 Mac Silicon.

libv commented 4 weeks ago

@xsmile Smashing. Finally a solid handhold.

xsmile commented 4 weeks ago

@ngocphamm According to the technical specs Apple M1-M3 chips support hardware acceleration for the H264 and HEVC formats. Video Toolbox is the framework used in this case. Checking the Hardware decoder value should be enough, as the decoder names can differ.

I don't know much about video acceleration on macOS and I recommend you to verify if it works correctly on Chromium first, which is the basis for Electron and ultimately FreeTube.

libv commented 4 weeks ago

Hah!

0.19.2:

0.2x.x:

So this exposes three different issues: 1) VAAPI is not working in my instance (perhaps missing gpu firmware, who knows) 2) 2x.x does not bother even trying VAAPI like 19.x, so something changed there. 3) the high cpu load has nothing to do with video acceleration.

intel-gpu-top was right though.

I am whittling down the list of commits. 60% are translations, and half of what then is remaining are unforced updates of modules. I will create some 0.19.2 with relevant backports and one or more commits which reproduce the high cpu usage which is not hw decode related (if i would have to guess now, it's some electron version bump which triggers this).

ngocphamm commented 4 weeks ago

@xsmile I think I'm slowly getting this. It's proably because I enabled DASH AV1 setting (to watch > 1080p videos).

This same one https://www.youtube.com/watch?v=jHP942Livy0, results in Hardware encoder: true if I have DASH AV1 Off, as it stays as H..264 1080p quality. With DASH AV1 On, and I select 1440p quality, for example, then Hardware encoder: false.

xsmile commented 4 weeks ago

@libv AFAIK the only relevant commit is d2f14b072a1fadf81ce49a7516bda2bfd7ce3860. Apart from that you should focus on Electron and the various parameters to enable VA-API. Currenly FreeTube overrides the --enable-features flag, so you will need to use Electron directly for your tests.

libv commented 4 weeks ago

@xsmile I tested this a while ago, and cherry picking d2f14b0 on top of 0.19.2 changes nothing. So that's not it.

As i said, this high cpu usage does not seem to be about hw acceleration.

One thing i would like to see is a freetube 0.19.3 with youtube[i].js, invidiuous list, and some local api updates, and as little as possible else. I'm getting there through sheer brute force, but at least it feels more productive than the bisect or the ages i spent making the 0.19.2 gpu page diffable against the 0.2x.x ;)

Thanks heaps for the dev info stuff, you helped this case along massively.

absidue commented 3 weeks ago

One thing i would like to see is a freetube 0.19.3 with youtube[i].js, invidiuous list, and some local api updates, and as little as possible else.

As we are just a team of volunteers that work on FreeTube in our spare time, we definitely won't be creating lots of different release lines, it's already enough work doing one. Additionally creating releases with out-of-support Electron versions that have a lot of publicly known security problems, would be negligent.

However nobody is going to stop you from creating custom builds for your own use that downgrade dependencies, remove security improvements, features and bug fixes. If you do decide to go along that route, I ask you to please not report any issues on this GitHub that you experience with your custom builds, unless you can also reproduce the exact same problem on the latest official releases or nightly builds, because if you can't reproduce them, then it's a problem with your custom build.

mafclean commented 3 weeks ago

I been following all the discussion that you guys been having and trying to understand more of what is going on. First, thank you very much @libv for the work in investigating the problem; @ngocphamm for participating; and @xsmile and @absidue for mitigating and confirming the cause. Second, please forgive me if I'm not going to add more important or skilled information to the discussion, but I would like to put on record that I am still having the massive leap in CPU usage in FreeTube 0.21.3-portable — I'm on Windows 10.

I went into check what you guys unearth, and so it appears that "the problem" is the same for me on Windows 10, correct?! I took a screenshot from the Developer Tools panel to see which decoder is being used while playing the same 1080p@60 video — while having the massive CPU usage:

1.) FreeTube 0.21.3-portable – FFmpegVideoDecoder 1) FreeTube 0 21 3-portable

2.) FreeTube 0.19.2-portable – VDAVideoDecoder 2) FreeTube 0 19 2-portable

I now understood that the problem is with Electron and that I also need to try to enable the old VDAVideoDecoder in FreeTube on Windows 10 (is it possible?); and/or build a custom build in order to keep it playing smooth for me on my old hardware. Did I miss something or got it wrong in any way?

Please, allow me to thank you all once again for all the hard work. I really appreciate it.

absidue commented 3 weeks ago

@mafclean Interesting that you mention old hardware, could you try running the lastest FreeTube release with --ignore-gpu-blocklist?

If you don't know how to do it here is how you can do it:

  1. Make sure FreeTube isn't running
  2. Go to the folder that contains the exe, in your example the portable one.
  3. Hold the Shift key while right clicking the exe
  4. Click on the Copy as Path option.
  5. Press the Windows and R keys at the same time, that should bring up the Run dialog
  6. Paste the path you copied before add a space after it and then write --ignore-gpu-blocklist. It should look something like this: "C:\something\FreeTube.exe" --ignore-gpu-blocklist
  7. Click OK or press the Enter key
libv commented 3 weeks ago

@absidue I have no intention of maintaining a stable branch.

It is hard enough to keep the tip of freetube development working with youtube side changes as it is.

I am a long time graphics driver developer (I brought you inconsequential things like modesetting, free ATI drivers and free ARM drivers), I live in C and assembly, and this java and chrome stuff is completely alien to me. I actually want as little to do with this code as possible, but needs must.

But these are the facts:

The only logical path forward i see is to whittle down the commits to throw out anything that does not affect usage with modern youtube servers, and to then reshuffle the remainder to isolate the at least 2 commits that cause the increases in CPU usage. This to not only to narrow down which versions of electron cause this (if this is indeed the guilty party) but also so that i can easily and cleanly switch between these commits while further debugging things, without affecting anything else. Only then can i get good measurements, and only then can i go bark up the respective modules tree.

absidue commented 3 weeks ago

Okay so there seems to be two issues here:

mafclean commented 3 weeks ago

@mafclean Interesting that you mention old hardware, could you try running the lastest FreeTube release with --ignore-gpu-blocklist?

Yes, @absidue. As a matter of fact, I already tested that earlier today while reading more about the hardware acceleration types of problem with Electron.

Library (The links I have accessed and read today)

Earlier, I did the test using the flag --ignore-gpu-blacklist (not blocklist) and others (see below) with the build FreeTube-0.21.3-nightly-4618-win-x64-portable. None of them worked and/nor solved the problem.

Now (while I write), I re-did the same test following your instructions for the sake of it: I tested FreeTube-0.21.3-nightly-4629-win-x64-portable (also after the more recent bump of Electron from 31.3.0 to 31.3.1); and the latest official release FreeTube-0.21.3-win-x64-portable.

Task Manager process screenshot

Apart from --ignore-gpu-blocklist I also re-tested both versions (nightly and release) with the flags:

--enable-features=PlatformHEVCEncoderSupport --enable-accelerated-video-decode --enable-accelerated-video

None of them changed the situation in regards to the decoder and/or activating hardware acceleration. This is FreeTube-0.21.3-nightly-4629-win-x64-portable with --ignore-gpu-blocklist:

Developer tools Panel

The soon I 'press play' in a 1080p@60 video the CPU jumps high and stick to a constant high usage while playing — on nightly and release:

A-1) FreeTube-0.21.3-NIGHTLY-4629-win-x64-portable with --ignore-gpu-blocklist A-1) FreeTube-0 21 3-nightly-4629-win-x64-portable with --ignore-gpu-blocklist

B-1) FreeTube-0.21.3-RELEASE-win-x64-portable with --ignore-gpu-blocklist B-1) freetube-0 21 3-win-x64-portable with --ignore-gpu-blocklist

In relation to the "old hardware" I must also say "yes". Mine is a Intel Core i7 3517U / Intel HD Graphics 4000 / GeForce 635M (2GB) from 2013 — still rocking it pretty solid and fast with the right applications & correct configurations. Do you need more specifics?!

I'm not saying that I knew/know what the problem is, but every time I see a changelog with the phrase "Bump Electron from..." I already expect something can break within a given application for me — even more now that the industry is not only dropping support for Windows 7 and Windows 8/8.1, but apparently for older builds of Windows 10 that run on old hardware and the old hardware. But again, everything was working fine with version 0.19.2; and maybe just this change in hardware decoder, and it being on/off, is what is causing the problem?!

At your disposal.

mafclean commented 3 weeks ago

Following in providing more information for Windows 10 machine users on old hardware: Intel Core i7 3517U / Intel HD Graphics 4000 / GeForce 635M (2GB).

GPU Internals Full Report

FreeTube 0.19.2-win-x64-portable 0.19.2-win-x64-portable-OLD-STYLE.txt 0.19.2-win-x64-portable-NEW-STYLE.txt

FreeTube 0.21.3-win-x64-portable 0.21.3-win-x64-portable.txt

Video Acceleration Information

As @xsmile pointed out earlier:

My 0.19.2-win-x64-portable is using hardware acceleration.

Video Acceleration Information
==============================
Decoding:
    Decode h264 baseline: 64x64 to 4096x4096 pixels
    Decode h264 main: 64x64 to 4096x4096 pixels
    Decode h264 high: 64x64 to 4096x4096 pixels

My 0.21.3-win-x64-portable is not using hardware acceleration.

Video Acceleration Information
==============================
Decoding:

Flags Being Used

As @absidue pointed out about flags being removed/changed:

My 0.19.2-win-x64-portable is using the flags:

a) --enable-accelerated-video-decode b) --enable-file-cookies c) --ignore-gpu-blacklist d) --disable-smooth-scrolling

Log report:

Version Information
===================
Command Line: "D:\Program Files\freetube-0.19.2-win-x64-portable\FreeTube.exe" --allow-file-access-from-files --enable-accelerated-video-decode --enable-file-cookies --ignore-gpu-blacklist --disable-smooth-scrolling

My 0.21.3-win-x64-portable is using the flags:

a) --secure-schemes=app b) --fetch-schemes=app c) --standard-schemes=app d) --disable-smooth-scrolling

Log report:

Version Information
===================
Command Line: "D:\Program Files\freetube-0.21.3-win-x64-portable\FreeTube.exe" --allow-file-access-from-files --secure-schemes=app --fetch-schemes=app --standard-schemes=app --disable-smooth-scrolling
xsmile commented 3 weeks ago

@mafclean You should probably open a separate issue specifically for your case. It looks like currently two different issues are being mixed up as @absidue already noted.

AFAIK FreeTube only changes acceleration settings for Linux and the other operating systems should work as is and are generelly less problematic. Make sure your GPU drivers are up to date and verify if acceleration works with Chrome with an H264 video. If it does, then it is an Electron configuration issue. If not, it is an issue with the Chromium codebase. Most likely this has nothing to do with FreeTube.

mafclean commented 3 weeks ago

@xsmile roger that! I was having this discussion here because the problem was/is very similar for libv and me.

AFAIK FreeTube only changes acceleration settings for Linux and the other operating systems should work as is and are generelly less problematic.

Understood. But again, everything was working fine with Freetube-0.19.2 until the industry drop of Windows 7/8/8.1 and probably (?) the list of CPU/GPU that now is being forced out of support — my machine was originally purchased with a Windows 8.1 edition.

Make sure your GPU drivers are up to date

They are. It is a 2013 machine and there are no more driver updates provided. Everything works flawlessly [given the proper support].

verify if acceleration works with Chrome with an H264 video

As you requested, I did a test with SWare Iron v.87.0.4450.0 (Chromium based browser) and it worked perfectly: no high CPU usage nor lags while using H264 with a 1080p@60 video on YouTube:

SWare Iron v 87 0 4450 0 - H264 1080p@60 - avc1 codec

Now, with Chromium itself (version 91.0.4462.0) while using VP9 codec also works, but I feel a subtle stuttering (heaviness) of the YouTube page and the high CPU usage (a little lower the high leap I now get with FreeTube-0.21.3). When I then change to play the same 1080p@60 video with H264/AVC1, I get this:

Chromium 91 0 4462 0 - H264 1080p@60 - avc1 codec

Should we still wait for @absidue final answer to confirm this information and to open a new issue if necessary?! Or does these tests answer the question as to "If it does, then it is an Electron configuration issue. If not, it is an issue with the Chromium codebase. Most likely this has nothing to do with FreeTube" ? (genuine question) — I understood that my CPU/GPU hardware was dropped out of support and blacklisted/blocklisted from Chromium, correct?!

I'll will not be posting anything else here until called into doing so.

Thank you @xsmile for your most welcoming help and everyone else in this issue. I really appreciate for all the support FreeTube community has given me.

xsmile commented 3 weeks ago

@mafclean Hardware video acceleration is officially not supported on Linux but it should be supported and enabled by default on Windows. Is there a reason why you used old Chromium versions during your tests? 87.0.4450.0 is over three years old and does not reflect the versions used by FreeTube: freetube 0.19.3 - electron 22.3.5 - chromium 108.0.5359.215 freetube 0.21.3 - electron 31.1.0 - chromium 126.0.6478.114

Your hardware does not support accelerated VP9 decoding. The higher CPU usage is expected when playing such videos.

I understood that my CPU/GPU hardware was dropped out of support and blacklisted/blocklisted from Chromium

Good question. You should limit your tests to the H264 format only, since you verified that it worked well in previous Chromium versions, and test again with the versions mentioned above.

mafclean commented 3 weeks ago

Is there a reason why you used old Chromium versions during your tests?

@xsmile I just have Chromium browsers in case of testing stuff and for other minor uses as I know some websites "work better there", but it has never been my daily driver. So, for the test, I assumed that I didn't need to use a more recent version because: if Chromium did have tweak something back then — like dropped the support or blocklisted my GPU hardware — on a earlier version (like 91), then it probably already did that on ongoing versions too (like 126). Does that make sense while not necessarily being correct at the same time?!

[That is why I don't "just update" anything, because of exactly what we are talking about here: the inevitable drop of support or tendency to make things a "heavier load" for old hardware given the changes of time.]

Your hardware does not support accelerated VP9 decoding. The higher CPU usage is expected when playing such videos.

Exactly! Thank you for stating that.

I understood that my CPU/GPU hardware was dropped out of support and blacklisted/blocklisted from Chromium, correct?!

Good question. You should limit your tests to the H264 format only, since you verified that it worked well in previous Chromium versions, and test again with the versions mentioned above.

Sir, aye-aye, sir! I did the test as you requested using versions 108 and 126; the ones that I have encountered to download here. I tried to download it from here but I got a little bit confused and could not find the requested versions. I used the same video I have been using until now, and played it at 1080p@60 with AVC1 (H.264) codec. The versions of Chromium that I used were:

(I hope that is not a huge difference)

Results for Chromium 108.0.5359.125 with AVC1 (H.264)

Video Decoder Track #1
===================
Decoder name: VDAVideoDecoder
Hardware decoder: true

A-1.1) Chromium 108.0.5359.125 with AVC1 (H.264) = VDAVideoDecoder A-1 1) Chromium 108 0 5359 125 with AVC1 (H 264) codec

A-1.2) Chromium 108.0.5359.125 with AVC1 (H.264) = VDAVideoDecoder A-1 2) Chromium 108 0 5359 125 with AVC1 (H 264) codec

A-1.3a) Chromium 108.0.5359.125 with AVC1 (H.264) = VDAVideoDecoder A-1 3a) Chromium 108 0 5359 125 with AVC1 (H 264) codec-CROP

A-1.3b) Chromium 108.0.5359.125 with AVC1 (H.264) = VDAVideoDecoder A-1 3b) Chromium 108 0 5359 125 with AVC1 (H 264) codec-CROP

Detail: it plays all the way at a low CPU usage, =/< 20% give or take (as FreeTube 0.19.2 used to).

Results for Chromium 126.0.6478.115 with AVC1 (H.264)

Video Decoder Track #1
===================
Decoder name: FFmpegVideoDecoder
Hardware decoder: false

B-1.1) Chromium 126.0.6478.115 with AVC1 (H.264) = FFmpegVideoDecoder B-1 1) Chromium 126 0 6478 115 with AVC1 (H 264) codec

B-1.2) Chromium 126.0.6478.115 with AVC1 (H.264) = FFmpegVideoDecoder B-1 2) Chromium 126 0 6478 115 with AVC1 (H 264) codec

B-1.3a) Chromium 126.0.6478.115 with AVC1 (H.264) = FFmpegVideoDecoder B-1 3a) Chromium 126 0 6478 115 with AVC1 (H 264) codec-CROP

B-1.3b) Chromium 126.0.6478.115 with AVC1 (H.264) = FFmpegVideoDecoder B-1 3b) Chromium 126 0 6478 115 with AVC1 (H 264) codec-CROP

Detail: it plays all the way at a high CPU usage, =/> 50% give or take (as FreeTube 0.21.3 do now).

So Chromium 108.0.5359.125 did work just as FreeTube 0.19.2 used to. And Chromium 126.0.6478.115 did work just as FreeTube 0.21.3 do now. Also, I was only able to enable AVC1 codec when I used the extension enhanced-h264ify to block VP8/VP9/AV1. Enabling or disabling the flag ignore-gpu-blocklist (override software rendering list) did not change anything on any Chromium version (the old ones or the more recent ones).

To sum up all the tests until now:

Performance wise:

And as I understood:

Enable Hardware Acceleration In Chromium On Ubuntu Or Linux Mint Source: https://www.linuxuprising.com/2018/08/how-to-enable-hardware-accelerated.html

Also, the GPU report of FreeTube 0.21.3-win-x64-portable (here) does state that:

Problems Detected
=================
*   Accelerated video encode has been disabled, either via blocklist, about:flags or the command line.
    Disabled Features: video_encode

(This only appears in the 0.21.3-win-x64-portable log report)

In conclusion, what I have understood with all of this is that: FreeTube now would only properly work for me if a specific build of development would exist to support my kind of hardware (and the proper decoders), on the condition that Chromium would allow/support it (either by flags or by "code forcing" the application), and if Electron would also not block it, correct?! Meaning: there is no solution as to activate hardware acceleration for me given that FreeTube, following Electron, following Chromium, is not enabling hardware acceleration because of the changes of hardware decoders and not supporting old hardware anymore?! Is that right?

Or could it be that all of this is just a Chromium fault/bug at the present moment, while FreeTube is using Chromium 126.0.6478.114?

Being possible, does FreeTube could support the other hardware decoders with no hassle as to modern operations going forward, if Chromium did? Or would that be much more than just "enabling a flag"?

Please, do correct me on anything that I could be and I am wrong about it, okay?! As I said it, I am not a coder/developer and I really appreciate all the help that you, @xsmile, and everybody else has given as to understand this issue, while being so gracious and patient with me. Thank you very much!

Again, at your disposal.

xsmile commented 3 weeks ago

@mafclean Thanks for the detailed writeup. The minor version differences should not matter.

there is no solution as to activate hardware acceleration for me given that FreeTube, following Electron, following Chromium, is not enabling hardware acceleration because of the changes of hardware decoders and not supporting old hardware anymore

It looks like this is correct. Since acceleration does not work with current Chromium versions, it is highly unlikly that it will work with Electron or FreeTube, as they use Chromium as a basis.

According to the Vivaldi forum you could use a flag to enable acceleration for a while but it was dropped with version 116.

absidue commented 3 weeks ago

It could be a bug in Chromium but it is also possible that they dropped support because in your own words, your GPU doesn't get driver updates anymore which means any bugs in that driver are never going to get fixed.

In the same way that Chromium dropped support for Windows 7, 8 and 8.1 because Microsoft decided they would not be releasing anymore updates for those operating system versions.

mafclean commented 3 weeks ago

I slightly edited my last comment on the part of the sum-up of the tests, so to register the decoder name and HW acc. status for the VP9 codec and to indicate the performance of each one.

@xsmile you're welcome. Yes, so it seems... Nice talk over the Vivaldi forum; it gave a lot of important information regarding this subject. And just to be sure about it, I also tested version 111 all the way up to 116 — following Hibbiki builds where I could download the latest version of a given build. Only on Chromium version 111 was I able to use VDAVideoDecoder. On versions 112 throughout 116 I was unable to use hardware acceleration with MojoVideoDecoder or VDAVideoDecoder; they all fall back to FFmpegVideoDecoder when H.264 is to be used, considering you also activate enhanced-h264ify extension to block VP8/VP9/AV1 (changing flags did not do anything again). I also noticed that on version 126 that I have tested before, the "Hardware Acceleration" toggle in the Settings options of Chromium does not even exist anymore.

@absidue let us hope it is a bug/fault in Chromium; I mean, why would you force H.264 into using FFmpegVideoDecoder, if AV1 and VP9 already have their own decoders, right?! But I could guess that some of the reasons (if not being a bug/fault) would be:

To me it is a mix of the two. Even more so that now we live in a world where there has never been so many people connected/online, and the two sides (people and companies) are always in the need to cut costs while always wanting more.

As for my options, I understand that I can:

In conclusion, and as to "close this issue for now", I must say that: to me, on Windows, the issue of the massive leap in CPU usage has absolutely everything to do with hardware acceleration; and the fact that the release of FreeTube (0.20+), following Electron (23+), following Chromium (112+/126), does not support hardware acceleration for old hardware's when it comes to the use of AVC1/H.264 codecs with MojoVideoDecoder or VDAVideoDecoder decoders. Did I leave something out?!

Again, I must thank you all for being so instructive, constructive and for having the patience to answer me regarding this issue. I really, really appreciate you @absidue and @xsmile. Thank you very much and for the others that also contributed/participated.

Long live FreeTube! As free as it can be, while tubing what it matters!

absidue commented 1 week ago

why would you force H.264 into using FFmpegVideoDecoder

Because software decoding works everywhere you just need a CPU, but hardware decoding needs special drivers, special software, extra steps in Chromium's complex video handling pipeline.

I don't blame Chromium for not wanting to support hardware forever that has even been abandoned by the manufacturer no longer releasing driver updates. The more things they have to support the more testing need to be done for every single change, to make sure it doesn't break stuff.

And no I'm not surprised that a program that is just a video player is able to support that abandoned hardware, whereas Chromium is a gigantic monolith, that keeps growing so at some point they need to stop supporting some stuff otherwise it's going to become unmanageable.

In the same way that it's not worth maintaining support and testing every single change on operating systems that no longer receive system updates or driver updates and most of the world no longer uses.

"Sorry I know we promised to release this feature a year ago but it was having problems on Windows 7 that didn't happen on any modern operating system, so because we say we still support this abandoned operating system we had to delay the release by a year so we had time to figure out a hacky workaround around the bug in Windows 7, that Microsoft is never going to fix, so that said feature would work on Windows 7".