I don't think he's referring to actually baking in the ads into the video stream, but rather just having video URLs transparently redirect to ad content. So fo

I don't think he's referring to actually baking in the ads into the video stream, but rather just having video URLs transparently redirect to ad content. So for instance, if normally the first 100 bytes of the video (as fetched via yt-dl) are like "googlevideo.com/gibberish-id?signature&rage=0-100", then you could transparently insert an ad into the next 100 bytes by making "googlevideo.com/gibberish-id?signature&rage=100-200" return the ad. Of course this makes the serving logic much more complicated, so it's probably why they don't do it. You'd also have to appropriately cut on a keyframe, muck around with muxing so things splice properly, and so on. Another possibility to enforce that ads are seen (or at least things are appropriately delayed) is to simply only return video URLs if there was a "pingback" that an ad was seen. So if you serve a 10 sec ad, but the user requests a video URL before the 10 seconds are up, just reject it. This requires a bit more logic on the serving end to track state, but is easier than the previous proposal.