YouTube has found a new way to bypass ad blockers by integrating ads directly into video content via "server-side ad insertion," complicating the detection and blocking of ads. How will ad blockers respond?
Because it’s much more expensive. What they’re talking about here is basically modifying the video file as they stream it. That costs CPU/GPU cycles. Given that only about 10% of users block ads, this is only worth doing if they can get the cost down low enough that those extra ad views actually net them revenue.
It wouldn’t cost any CPU with custom software that Google can afford to write. The video is streamed by delivering blocks of data from drives where the data isn’t contiguous. It’s split across multiple drives on multiple servers. Video files are made of key frames and P frames and B in between the key frames. Splicing at key frames need no processing. The video server when sending the next block only needs a change to send blocks based on key frames. It can then inject ads without any CPU overhead.
Wouldn’t it still need overhead to chose those blocks and send them instead of the video? Especially if they’re also trying to do it in a way that prevents the user from just hitting the “skip 10 seconds” button like they might if it was served as part of the regular video.
It has to know which blocks to chose to get the next part of the file anyway. Except the next part of the file is an ad. So yes there is overhead but not for the video stream server. It doesn’t need to re encode the video. It’s not any more taxing than adding the non skip ads at the beginning that they already do.
This isn’t how YouTube has streamed videos for many, many years.
Most video and live streams work by serving a sequence of small self-contained video files (often in the 1-5s range). Sometimes audio is also separate files (avoids duplication as you often use the same audio for all video qualities as well as enables audio-only streaming). This is done for a few reasons but primarily to allow quite seamless switching between quality levels on-the-fly.
Inserting ads in a stream like this is trivial. You just add a few ad chunks between the regular video chunks. The only real complication is that the ad needs to start at a chunk boundary. (And if you want it to be hard to detect you probably want the length of the ad to be a multiple of the regular chunk size). There is no re-encoding or other processing required at all. Just update the “playlist” (the list of chunks in the video) and the player will play the ad without knowing that it is “different” from the rest of the chunks.
You could only use this new system if the old one fails, ie. only for the say 10% of users that block ads, and so even if it were more expensive it would still be more profitable than letting them block all ads.
But I don’t think even that is the case, as they can essentially just “swap out” the video they’re streaming (as they don’t really stream “one video” per video anyway), bringing additional running costs to nearly zero.
The only thing definitely more expensive and resource intensive is the development of said custom software
But I don’t think even that is the case, as they can essentially just “swap out” the video they’re streaming
You’re forgetting that the “targeted” component of their ads (while mostly bullshit) is an essential part of their business model. To do what you’re suggesting they’d have to create and store thousands of different copies of each video, to account for all the different possible combinations of ads they’d want to serve to different customers.
Because it’s much more expensive. What they’re talking about here is basically modifying the video file as they stream it. That costs CPU/GPU cycles. Given that only about 10% of users block ads, this is only worth doing if they can get the cost down low enough that those extra ad views actually net them revenue.
It wouldn’t cost any CPU with custom software that Google can afford to write. The video is streamed by delivering blocks of data from drives where the data isn’t contiguous. It’s split across multiple drives on multiple servers. Video files are made of key frames and P frames and B in between the key frames. Splicing at key frames need no processing. The video server when sending the next block only needs a change to send blocks based on key frames. It can then inject ads without any CPU overhead.
Wouldn’t it still need overhead to chose those blocks and send them instead of the video? Especially if they’re also trying to do it in a way that prevents the user from just hitting the “skip 10 seconds” button like they might if it was served as part of the regular video.
It has to know which blocks to chose to get the next part of the file anyway. Except the next part of the file is an ad. So yes there is overhead but not for the video stream server. It doesn’t need to re encode the video. It’s not any more taxing than adding the non skip ads at the beginning that they already do.
Compared to the cost of reencoding the video (or even segments of it) it would be basically nothing, though.
You’re forgetting the part where the video is coming from a cache server that isn’t designed to do this
They’re already appending ads to the front of the video. Instead of appending an ad at key frame 1 they append the ad at key frame 30,000.
This isn’t how YouTube has streamed videos for many, many years.
Most video and live streams work by serving a sequence of small self-contained video files (often in the 1-5s range). Sometimes audio is also separate files (avoids duplication as you often use the same audio for all video qualities as well as enables audio-only streaming). This is done for a few reasons but primarily to allow quite seamless switching between quality levels on-the-fly.
Inserting ads in a stream like this is trivial. You just add a few ad chunks between the regular video chunks. The only real complication is that the ad needs to start at a chunk boundary. (And if you want it to be hard to detect you probably want the length of the ad to be a multiple of the regular chunk size). There is no re-encoding or other processing required at all. Just update the “playlist” (the list of chunks in the video) and the player will play the ad without knowing that it is “different” from the rest of the chunks.
This is not necessarily the case.
You could only use this new system if the old one fails, ie. only for the say 10% of users that block ads, and so even if it were more expensive it would still be more profitable than letting them block all ads.
But I don’t think even that is the case, as they can essentially just “swap out” the video they’re streaming (as they don’t really stream “one video” per video anyway), bringing additional running costs to nearly zero.
The only thing definitely more expensive and resource intensive is the development of said custom software
You’re forgetting that the “targeted” component of their ads (while mostly bullshit) is an essential part of their business model. To do what you’re suggesting they’d have to create and store thousands of different copies of each video, to account for all the different possible combinations of ads they’d want to serve to different customers.
10% where do you get that. The data I have heard is it’s around a third of all internet users globally.
To say that it’s just much more expensive would be a huge understatement. This is not going to work, at least not in a near future…