If they carry on with this bullshit I'll be dropping them entirely for Nebula. I quite enjoy Nebula so far.

Almost certainly not, although fair disclaimer, I don't actually know. Ads need to be tailored to the user when delivered, so it's likely the YouTube frontend requesting the next chunk of video to be an ad instead of the next chunk of video from blob storage. yt-dlp likely just requests successive chunks straight from blob storage, passing this.

If YouTube served ads by saying "point to an ad chunk next" in their blob storage, 1. Everyone would see the same ad and 2. Premium users would still see ads.

To patch this, YouTube really needs to stop serving video chunks directly from storage, but I forget the reason they haven't done that already.

(Technical note; I'm assuming blob storage chunks contain 1-2 seconds of video and metadata pointing to the next one, like a linked list. I'm not sure if this is how YouTube works, but many video platforms do this)

The server must have to send some metadata to the client telling when it's running an ad because there are other things that need to happen client side during that like adjusting of the time or making the ad clickable

I have actually been seeing some timestamps that are completely wrong lately, maybe this is why.

Video length is incredibly important to The Algorithm and a LOT of content creators time their videos to the second. Taking away control of that (even if the end result ins the exact same length) is going to ruffle a lot of feathers and lead to a lot of people who want to "be a champion for the viewers who should like, comment, and subscribe and use my referral code for war thunder" as a result.

Sounds wasteful, detection of ads could be detected with regular software, no?

That would be cool.

I guess my AMD Bulldozer TV PC is gonna have to go in the ewaste bin though. Its already stretched to its limit running Linux Mint, Firefox, uBlock Origin and Sponsorblock as it is

imagine using Gemini for this, would be peak irony.

It'll be difficult for a while until someone figures it out and then it'll be easy again. It's just an arms race.

Sponsorblock "just" needs to transition from timestamps to timestamps + image hash. Not easy, but not impossible.

Only if the ads are a fixed length and always in the same place for each playback of the same video.

Inserting ads of various lengths in varying places throughout the video will alter all the time stamps for every playback.

The 5th minute of the video might happen 5min after starting playback, or it could be 5min+a 2min ad break after starting. This could change from playback to playback; so basing ad/sponsor blocking on timestamps becomes entirely useless.

Different users would see unique ads. So your ad could be 12 seconds long while my ad is 30 seconds long. A timestamp based skip would no longer work universally.

Nah, it would just circumvent them.

If they are injecting ads into the actual video stream; it won't matter what client you use. You request the next video chunk for playback and get served a chunk filled with advertising video instead. The clients won't be able to tell the difference unless they start analyzing the actual video frames. That's an entirely server-side decision that clients can't bypass.