Hacker News Reader

Comment by jack_pp | Hacker News Reader

I'm still baffled that youtube doesn't simply splice ads in the video stream directly and relying on client insertion through API endpoints which can be blocked. If they did video injection on the backend they wouldn't have any problems with ad blockers, it would literally be impossible to block. Even if the client would recognise ads somehow the server can just decide to serve the video of the ad while ignoring any seeking from the client so at best the client can mute the ad.

View on HN

Its not too hard to detect ads in video streams, even old school analog VCR's could do that.

Watching TV shows without adds was one of the selling points of those back in the day.

Some more modern digital ones had near real time features where they would play with a delay of a lets say half an hour and used that time to remove the ads.

If you have stream from Youtube containing ads you can trivially skip ahead.

And Youtube could do nothing about it because random skipping is one of the base features of every video player ever.

Then, the ad-adverse users will just use software that downloads the video and reprocesses the file to remove the ads. Ytdlp already does this with SponserBlock integration, and I imagine detecting ads is something AI would be pretty good at.

Of course, you lose the ability to mindlessly browse YT with no ads or get the dopamine hit of clicking an interesting video. I'm sure that's something YT considered if they pushed this option. They don't want you to just watch the few vids from your subscriptions per day and close the app.

> Even if the client would recognise ads somehow

Sponsorblock uses community driven marking of ads edited into the video.

I think you're right, that you wouldn't be able to skip an ad at the beginning of the video - you would need to predict for the user he will want to watch a video to load it earlier in the background to skip the ad, so only skipping ads in middle of the video would be possible.

> you would need to predict for the user he will want to watch a video to load it earlier in the background to skip the ad

Not sure I understand this. I don't think it's possible even now to load the video in the background, youtube is already smarter than this and it will load a short period of time whenever u seek anywhere, it doesn't just download the whole thing if you pause the video.

And the way I'm suggesting wouldn't be mitigated by sponsorblock since you wouldn't be able to skip it if you want to stream the video. Only way would be to use yt-dlp and remove the ads automatically but I suspect a tiny percentage of users would go to that length to avoid ads

> Not sure I understand this.

Imagine that you open the video on one tab, see where the ad IN MIDDLE of the video is (e.g. because of a system like Sponsorblock, other users reported it), click on progress bar to go after the ad, the system is probably smart enough to show the ad anyway - OK, you mute the ad, and open the same video again, and watch it from the beginning. By the time you get to the ad, you can switch to the other tab, where the ad already played.

Of course it wouldn't work if the ad was at the beginning.

The way I imagined it you wouldn't know where the ad is, they can insert it on the fly at any point. It wouldn't count in the video seek bar.. at any random point they want they can just insert it and you can do nothing about it except mute it and wait it out.

In such case take the worst (maybe disregarding 20% worst) ad length, and open a copy of the video advanced by that length. As soon as the ad starts to play, switch to the copy of the video. Of course you could be unlucky and the copy could get the ad at the different video time but same playback time. You could decrease the chance of it happening by additional copies, but the ads take small enough percentage of the time for 3-4 copies to make it very rare for such an overlap to happen.

Edit: actually, you could make a double buffer, so if you assume the ad takes up to 10 s, the copy of your video can skip 20 first seconds, play, eventually play an ad if it happens first on that copy, continue playing, and as soon as the main video get an add, go back on the copy to the right spot. So in order for this to fail, with just one copy, you need to either get an ad during the first 10 seconds, or the ad has to start exactly (within the lag time of let's say 50-200 ms) at the same time on both copies.

Video is not a single stream, but many smaller chunks daisy chained after each other. Reason for this is that you can then change i.e. quality of video and it will seamlessly change - because it will start daisy chaining higher quality chunks and show them in the player.

So what you are describing is already happening, ads are added directly into video stream, problem is that ads need to have access to API, because you don't want to show an ad for menstruation pad to a guy so you also need to know which user is watching and that's what cookies and the whole login is for, so you are effectively hitting a design limitation of the system.

And no, you can't do this ad selection on the server, because for example when you have 10 users behind a NAT how are you going to tell which user is which from the server point of view? So you need to be calling these APIs from the client side.

This is close to being correct, but it isn't. Server side ad insertion is possible, and the tech already exists. See, your browser by default sends cookies to the server with every web request, no JS required. Simply* add the ad videos to the list of chunks.

*By "simply" I mean it's technically possible, I know it's not simple to implement.

It's also already done for many podcasts, they'll have changing/seasonal ads for all episodes they're hosting. Which is confusing if you're listening to a 10 year old episode and get some new ad.

> Video is not a single stream, but many smaller chunks daisy chained after each other. Reason for this is that you can then change i.e. quality of video and it will seamlessly change - because it will start daisy chaining higher quality chunks and show them in the player.

Don't think this is correct, if you're on a slower connection you will see it takes a while when changing stream quality, the video "seamlessly" changes because it's still playing the current quality stream while the new quality stream loads. It would make no sense to send more than one quality at the same time because it would incur higher bandwidth costs and they care a LOT about bandwidth costs. I'm a premium user and even though I have higher quality enabled by default they STILL downgrade and not showing the highest quality possible unless I force it on specific videos.

> So what you are describing is already happening, ads are added directly into video stream, problem is that ads need to have access to API, because you don't want to show an ad for menstruation pad to a guy so you also need to know which user is watching and that's what cookies and the whole login is for, so you are effectively hitting a design limitation of the system.

They can do the tracking by user all the same, as long as the user is logged in they know what ads to show on the server already. This is already a problem when the user is using youtube without an account in an incognito window so if the client hacks the tracking side just show them default ads for their region. This is already a solved problem

Don't give them ideas! Also I think that there's a non trivial engineering effort required to inject ads into the video stream as well, for example with bookmarks and so on. Probably they'll do it but as last resort.

I suspect this war on adblockers is also non trivial and the "last resort" would win them this war forever. For a company the size of youtube the effort would be trivial.

There would likely be huge processing overhead for splicing ads into a stream, right?

No, you can concatenate video segments with basically zero cost if the segments are encoded using the same encoding parameters and afaik youtube already re-encodes user videos.

What's to prevent ad-blockers from just skipping ahead when there's an ad playing?

Simply refuse to send original stream packets / ignore seek requests by the client until the ad duration has passed. Sure you could pause / mute / alt tab for that duration but the point is being annoying so people buy premium if they hate ads so much.

Reply on news.ycombinator.com