This memory leak happens very often to me in GitHub, not sure why, and not sure if it's Microsoft's fault, or Firefox's. I actually have no idea at all on how to debug this...

Given their actions the last two years or so unfortunately the default assumption is (reasonably) “probably something intentional to get people to stop doing something they don’t want, like using ad blockers.”

Hanlon's Razor: https://en.m.wikipedia.org/wiki/Hanlon%27s_razor

    api.XL("innertubeCommand",{openPopupAction:{popup:{notificationActionRenderer:{responseText:{runs:[{text:"Experiencing interruptions?"}]},actionButton:{buttonRenderer:{style:"STYLE_OVERLAY",size:"SIZE_DEFAULT", text:{runs:[{text:"Find out why"}]},navigationEndpoint:{commandMetadata:{webCommandMetadata:{url:"https://support.google.com/youtube/answer/3037019#check_ad_blockers

That's not plausible.

If someone sees, oh YouTube is making my computer hot, the last thing that's going to occur to them is, "wait let me try turning off my adblocker."

When corporations try to change people's incentives, they are obvious about it, so people know what to change.

In contrast, changing CPU usage on video playback for people who use adblockers and then not telling anyone is... just not a strategy that makes any sense at all.

Possibly You are conflating CPU usage with halting of video for length of the ad? ad blocker halts the video i.e.spinner widget appears for length of the ad.

I work for another large streaming site where people like to use adblockers. These adblockers also cause similar performance issues that are entirely caused by awful code in these blockers. I've studied the code for all of these blockers and they do stuff like:

- Constantly hammering the playlist endpoint to try and get something without an ad stitched in

- Constantly tearing down and remaking the player

- During an ad, requesting the playlist for every other quality to see if those do not have any stitched ads

- Proxying all traffic to servers the adblocker people own in countries where ads are not typically served (eg Russia)

- Intercepting playlist requests and simply deleting segments that they believe are ads (oh no why is my stream broken!!! stupid streaming website!!)

Youtube _could_ be doing something here, but there is also a very real chance your adblocker code is simply bad.

Do you have an iGPU+dGPU combo like in a gaming laptop? For my 2019 gaming laptop with a i915+RTX2060, if I leave the switchable option on in the hardware settings (meaning the OS can choose which GPU to use ie. iGPU for low power), I end up with similar behavior in Linux/Win10. The external port actually uses the dGPU so rendering must go through it but it will struggle with the switchable option and I end up with freezing or stutters. In Linux, I explicitly configure Xorg to only use the iGPU and reserve the dGPU for model inference which fixes the stuttering issue. When booting into Win10, I explicitly disable the iGPU and turn off the external monitor so my VR playing doesn't stutter or youtube doesn't freeze or stutter.

And do you notice high CPU usage or stuttering?

Just out here raw-dogging the internet...

I run an extension that allows to automatically request h.264 streams from YouTube even when av1 is also available. Saves a lot of CPU, at the cost of some bandwidth.

That's intentional on YouTubes end, they aim to serve more bitrate-efficient codecs wherever possible, even if it's a high burden on the client due to a lack of hardware acceleration. They'll only fall back to older codecs if the client is completely incapable of handling the modern ones. It's annoying but at their scale it no doubt saves them a shitload of bandwidth.

I believe Youtube's player is driving codec selection, not the browser (i.e. the player requests a list of supported codecs and then picks the one most beneficial for Google, not the other way around).

That said, I've solved this problem for myself on macOS and Firefox by setting media.webrtc.codec.video.av1.enabled to false on about:config, as all other codecs used by Youtube are hardware accelerated on my Mac.

Same. I recall the "stable volume" setting also eating cpu.

I like imagine the stuttering and jagged reflows are the result of uBlock origin violently battling the page and destroying all the ads.

The experience suddenly gets mysteriously better if you switch your user agent to Chrome's, though.

Hell, I have to use my phone instead if I want to go to any of those pages nowadays. And even my phone now gets a random crash from chrome or the page itself.

I wonder if it’s proof of work bullshit. For those to be effective, they have to slow down whatever machine is running in an LLM farm.

That generally means they have to peg a desktop GPU for long enough to make a dent larger than LLM inference time.

Browsing with a 2 core box is like using a musket to blow a hole in a wall that’s optimized for armor piercing rounds.

Is this dumb? Of course. Your best recourse is probably to work around the anti-LLM blocks by having an agent read and summarize the page for you.

Are there any decent cloud based web renderers yet? Something like vnc or rdp backed by a shared 4090 could solve the problem. For static content, it’d only have to run proof of work once, then serve the result from cache.

Will Google ban your account if you login?

Either download ahead, or turn down the bitrate via ytdl format expressions; see the latter's docs for how to express your desires.