That sounds like it would take way too much processing power. Google is not like Twitch where relatively few streams are served to many millions, it's more like many millions of videos to many millions of users.

The argument I've heard against this is its much harder to report views this way. It basically becomes an honor system between Google and the advertiser, when today its the user getting the ad, so it's easier to verify.

Google is big enough where they could eventually do this most likely, but smaller sites won't have the 'credit' to pull this off.

Re-encoding is probably too expensive. And storing the same variant for everyone would effectively double the storage requirement (for ad-free users) and will be quickly defeated with Sponsorblock

Re-encoding is difficult but you don't necessarily have to do that. As far as I know it's possible to just splice segments of video between "key" frames without otherwise re-encoding the full video.

YouTube already re-encodes every uploaded video into multiple formats; it would be possible for them to develop a "smart" encoder to be aware of the visual content of the video in order to place "key" frames at natural breaking points of the video, such that subsequent ad insertion would be semantically correct and not too jarring.

With SponsorBlock, blocking such ads on YouTube is already a solved problem for sufficiently popular videos. Unless YouTube goes further and disables seeking during the portion of the video with ads. Then we're back to ad blockers removing some page functionality (the Javascript that disables seeking).

They can switch to HLS and dynamically insert ad segments randomly in the video duration. Of course it costs them to build such a system, but if the adblockers are already costing them money to begin with...

You could detect transitions and strip the ads client side with ffmpeg. Bonus points if you advertise the output in the torrent DHT using the YouTube id as the torrent identifier.

Easy to create per-user ad insertions.

Also easy to fetch more than one stream to fingerprint content vs ads for trimming. Admittedly whack a mole and cat & mouse.

Right, but that’s just a problem with not inserting it in the same places for everyone. Don’t even need JS to disable syncing, the events can be tripped but the service can just ignore them, it’s one video stream

It’s more work since that’s switching from shoving bytes over a network socket as quickly as possible to knowing where in a stream they can start inserting new frames, and they have to have versions of the ads in each format and resolution, but I’d be surprised if they haven’t already built that so they’d know exactly where the threshold is when more ad views pay for the additional hosting costs.

We developed and used that technique in production in the 00s, it's surprisingly easy with HLS, and doesn't cost more. On the contrary, being able to segment that way costs less as you only need to cache hot segments on the CDN and sequence/assemble on the fly based on server side ad inserts and client side player controls.

We didn't try it with VP8/VP9 (previously On2 / Duck TrueMotion) or whatever Google seems to prefer to push instead of the emerging "standard" challenging Flash back then, so I can't comment on that particular flavor.

Much more difficult if you're trying to support multiple types of streaming to multiple eras of clients (e.g. legacy TVs and handsets with earlier YouTube clients), as they surely still have to.

Thanks for confirming - basically my fear is that if ad blocking continues to grow, it’ll lead to an even bigger moat for YouTube because Google will be able to tell advertisers they have the resources to do it but self-hosting won’t. Whether or not that’s actually true, I’d expect them to find a receptive audience.

If you want to serve different ads dynamically you'd have to reencode every stream on the fly or find a way to dynamically insert segments into the existing encoded stream. Not sure the second is feasible with current codecs.

You can do that with m3u8 files. This is done for example by Pluto TV. Sure it is easily circumvented by simply stripping out these URLs, especially if they are marked as ads (And removing a m3u8 tag)

But in the end it would be again an arms race of adblockers and Google, so it would change basically nothing.

An easier way would be to do what Twitch does and not send video to the client while an ad is supposed to be running(also not buffer video when an ad is due). That way even the best adblocker can only show a blank screen while the ad is supposed to be shown.

Couldn't you theoretically show the video 30 seconds later to the user so that if there are a total of 3 ads in the video, you can automatically detect when they play and then skip it? Idk how to explain this better since English isn't my main language.

That's what happens on Twitch even with advanced blockers.