[Bug]: v.0.22.0 High CPU/GPU usage at 60fps videos. Inconsistent behavior.

[riverpiers]

Guidelines

• I have encountered this bug in the latest release of FreeTube.
• I have encountered this bug in the official downloads of FreeTube.
• I have searched the issue tracker for open and closed issues that are similar to the bug report I want to file, without success.
• I have searched the documentation for information that matches the description of the bug I want to file, without success.
• This issue contains only one bug.

Describe the bug

In v0.22.0 Beta there is a problem with 60fps video. CPU usage is very high 55%+ at x1 speed. (CPU i5 3.39GHz) At higher speeds up to x2, even 80-100% of the CPU. For comparison, in the previous version v0.21.3 Beta, at x1 speed: CPU 9% (x2: 9-14%) and GPU (x2: max 30%, integrated Intel UHD 620 card). The behavior is inconsistent across different 60fps videos, i.e. sometimes there is only higher GPU usage and sometimes both CPU+GPU usage occurs. Link to a video where this issue occurs: https://youtu.be/Sbmub5d1A-Q

Another video in v0.22.0 with 60fps that works ~correctly: https://youtu.be/beRMP4wuvWw
Speed x1: CPU ~7% / GPU 18%. Speed x2: CPU 8%, GPU 30%.

"Second" related issue: There is also a different proportion of 'Dropped Frames' between versions of the program at 1920x1080@60 and speed x1.1+
Data for the 2nd link v0.22.0: https://youtu.be/beRMP4wuvWw

1. Playback time 30s/speed x1.0 = Dropped Frames: 0/Total Frames: 1839
2. Playback time 30s/speed x1.1 = Dropped Frames: 163/Total Frames: 1834
3. Playback time 30s/speed x1.5 = Dropped Frames: 512/Total Frames: 1834
4. Playback time 30s/speed x2.0 = Dropped Frames: 861/Total Frames: 1832

For comparison, the same video v0.21.3: https://youtu.be/beRMP4wuvWw

1. Playback time 30s/speed x1.0 = Dropped Frames: 0/Total Frames: 1852
2. Playback time 30s/speed x1.1 = Dropped Frames: 166/Total Frames: 1831
3. Playback time 30s/speed x1.5 = Dropped Frames: 32/Total Frames: 1855
4. Playback time 30s/speed x2.0 = Dropped Frames: 110/Total Frames: 1865
   Difference: x1.5 speed = x16 increase Dropped Frames. Speed ​​x2.0 = ~x8 increase Dropped Frames.

Other video 1920x1080@60 v.0.22.0 https://youtu.be/rUtpoImc-Yo
Speed ​​x1.0, CPU 45-60+%, GPU 17%. Playback time 2:39, Dropped Frames 2/Total Frames 9637.

Expected Behavior

Consistent CPU/GPU usage at 60fps as in v.0.21.3 Beta.

Issue Labels

data loss, inconsistent behavior, usability issue

FreeTube Version

v0.22.0-win-x64-portable

Operating System Version

Windows 10, v19045

Installation Method

Portable

Primary API used

Local API

Last Known Working FreeTube Version (If Any)

v.0.21.3 Beta

Additional Information

N/A

Nightly Build

• I have encountered this bug in the latest nightly build.

[absidue]

Please try the lastest nightly and see if that is better 0.22.0.

https://github.com/FreeTubeApp/FreeTube/actions/runs/11803018589 (due to GitHub limitations you have to be logged into GitHub to download those).

[riverpiers]

1st video: https://youtu.be/Sbmub5d1A-Q works consistently as in v.0.21.3
'Dropped Frames/Tota Frames' for video: https://youtu.be/beRMP4wuvWw the same as in v.0.22.0 according to previous data.
3rd video: https://youtu.be/rUtpoImc-Yo also works as in v.0.21.3.
2. Another 'problem' appeared, i.e. when starting the nightly portable version: https://github.com/FreeTubeApp/FreeTube/actions/runs/11803018589/artifacts/2177882320 (double packed), which I tested, at startup it appears white background for a moment and then gray for a long second before the default view loads. There is a noticeable delay. This takes place inside the application window where the top bar of the window is normally visible. In contrast to the first version of freetube-0.22.0-win-x64-portable available on the program's website, it takes at least half the time.
3. I also noticed that the original audio track is being selected, which was not the case in the first v.0.22.0. The first available audio track in the list was selected.

Bottom line: The issue appears to have been resolved in my hardware configuration. As for the 'Dropped Frames/Total Frames' thread, I don't know what is the norm and how it should behave, whether according to v.0.22.0 or v0.21.3 or otherwise. There are still videos with 50fps, but judging by those running at 60fps, there shouldn't be a problem if I come across such a video.

[absidue]

(double packed)

That is expected and is a "feature" of GitHub actions artifacts (because you can also upload multiple files and it will combine them into a zip, so it wraps everything in a zip when you download it).

3. I also noticed that the original audio track is being selected, which was not the case in the first v.0.22.0. The first available audio track in the list was selected.

We added support for auto-dubbed audio tracks, so now it is working correctly and selecting the default track, the same as it does with every other video with multiple audio tracks.

As for the 'Dropped Frames/Total Frames' thread, I don't know what is the norm and how it should behave, whether according to v.0.22.0 or v0.21.3 or otherwise. There are still videos with 50fps, but judging by those running at 60fps, there shouldn't be a problem if I come across such a video.

As long as it is 0 for videos playing at 1x speed it's good or close to zero on a device like yours it is fine, you are not going to notice 2 dropped frames across the whole video. Playing at higher speeds is a lot more demanding on your computer, as it has to do all the same work that it has to do for 1x speed, but in a much shorter space of time/a lot faster, so I'm not surprised that a lower powered machine needs to drop frames (skip doing a bunch of work) to keep up.

at startup it appears white background for a moment and then gray for a long second before the default view loads. There is a noticeable delay. This takes place inside the application window where the top bar of the window is normally visible. In contrast to the first version of freetube-0.22.0-win-x64-portable available on the program's website, it takes at least half the time.

Was that just the first time after installing or does it happen every time? If it is just the first time, that is expected as the files changed so the caches are no longer valid and it can't use them as a shortcut to speed it up, so it has to treat it essentially as a fresh install, future startups should be faster as it can cache stuff.

[riverpiers]

My screen has a maximum refresh buffer of 60fps/s, so at x2 speed, 50% Frames "must" be dropped, because I won't see them within 1 second anyway. Then how to explain the 'Dropped Frames' result in v.0.21.3, at x1.5 and x2.0 speeds?
It seems that the data from v0.22.0 is more accurate: Playback time 30s/speed x2.0 = Dropped Frames: 861/Total Frames: 1832/60=~30s. Rounded 'Dropped Frames' to 900x2 =1800 Total Frames. So, according to the maximum buffer, it refreshes 60fps/s.
(I have an additional, more powerful graphics card, but I don't use it because Windows manages hardware acceleration as it wants while dividing the load between 2 graphics cards.)

Was that just the first time after installing or does it happen every time? If it is just the first time, that is expected as the files changed so the caches are no longer valid and it can't use them as a shortcut to speed it up, so it has to treat it essentially as a fresh install, future startups should be faster as it can cache stuff.

Yes, it took a little longer, a few seconds, the first time I started it. It got shorter in the next ones, but it's still ~x3+ longer than in v.0.21.3, where it takes a fraction of a second. Is this some kind of background/placeholder with the FreeTube logo turned off? Judging by the default graphic style, these are the colors of the background behind the thumbnails (white) and outside the thumbnails, free vertical space on the periphery (gray). As if loading a 'template'/thumbnail layout in the default tab setting: Subscriptions/'All Channels'. Maybe it's on YouTube's side, because it seems to load faster today. There is also a time difference depending on what option is selected as the default start card. Or the default expansion of the settings section (does it load in parallel in the background?), in v0.21.3 you could collapse the settings. The devil is in the details…