PiHole not working for YouTube Ads

Next step, server-side ad injection.

I know I watch way too much YT, and that I find YT ads absolutely unbearable. So for people like me, this is a good thing because I'll just stop using YT unless it is absolutely necessary. Google probably knows the numbers better than me, but they should look into the elasticity of demand for these ad-blocking users that they're trying to force ads on. I think a good chunk will just leave rather than watch ads, which will be worse for the platform overall.
 
There are way too many people who just coughed up the money for YT Premium for google to consider it, unless there's some major breakthrough in video encoding, there's no way it would work embedding content in the video stream itself, the hardware costs are way too high considering the throughput google goes through for YT, the main issue is dynamic advertising, they'll need to encode videos in real time for billions of users at a time, each time, they'll need to use adsense and insert an appropriate advert for a user and even that is a monumental task in a normal scenario, imagine doing it in a video? nah, aint no way, Streaming services have been grappling with this issue for a long time now, and they just have to servr content to users, they dont need any dynamic advert in the video itself and even they have pretty much hit the wall for scalability, there's a reason why bitrates dropped dramatically during covid, why even now, bitrates for streaming services wont exceed 15-25mbps and even at that, its rare you ever hit the full bitrate for a stream, Scalability is a massive issue, specially for something like encoding where there's just no way they can ignore the blocking IO in cpu/storage for each video.

The only way I can figure is they'll cut the videos into clips, insert adverts dynamically and try to make it as seamless as possible, and even this is pretty easy to work around, the only way it'll work is if the video from server itself has adverts embedded in it which is what it says in the article

yep, that they are, Revanced has been a lot less stable these days, I think google is counting on the fact that premium is cheap enough for people, that they'd rather pay for it then go through this PITA process of having to build/install revanced again.
Server side ad injection is not that complicated as it has been in use for several years even for live content and doesn't have much processing overhead. Basically the content is split into multiple random segments in a playlist (which can be done without re-encoding) and then based on the client/user ID, customized ad segments are added by the ad service in the playlist, in between the content segments of the playlist.

The client player basically receives a playlist with multiple segments, which is always unique on every playback. The client cannot differentiate between content and ad segments as they are served from the same CDN with similar URL.

Presently, the ads are blocked because the client invokes them locally using Javascript which can simply be blocked. The only way to block ads in case of server side injection would be if the client can somehow figure out which is an ad or content segment based on real-time content analysis which is complex to say the least. May be simplest solution will be to manually skip a segment, but then I am not sure to what extent a playlist can be obfuscated (eg. hide duration of segment).

The only time the playlist may be the same is if it is a Premium user, so timestamp based services like Sponsorblock may work for Premium. For others, the duration of overall ads can be determined based on duration difference from Premium, but determining the location in the playlist will still be difficult.
 
Last edited:
Maybe a simple way to get around server side ad injection would be to have a browser extension that hashes every, say, 1 in 10 frames of the video stream, then compares it to a central database of hashes for ads and detects if it should be skipped. You would have to store different hashes for each ad, and for each resolution and codec, and routinely crawl YT to collect every ad for every region, but if it comes to that, clearly the motivation is there for people to try it.

A potential optimization might be using perceptual hashing instead of the normal kind.
 
The client player basically receives a playlist with multiple segments, which is always unique on every playback. The client cannot differentiate between content and ad segments as they are served from the same CDN with similar URL.
Because YT wants you to watch ads, they will make it unskippable and that will be the chink in their armour

A potential optimization might be using perceptual hashing instead of the normal kind.
Or audio track recognition may be
 
Back
Top