the reason they are not doing it is because the ads are personalized. So if they want to bake an ad onto a video they will end up with countless videos each on with their own unique ads which is not viable logistically. So they can only do it on-the-fly. But re-encoding each video on-the-fly for each user is also a nightmare logistically, if not impossible at all.
I don't think you'd need to re-encode the whole thing on the fly. More frigging the container data around, than the video/audio codec itself.
That way I could request some_pointless_video.mp4 and it sends me 95% the same thing as is already on their server, with adverts jammed into it at defined intervals.
They probably think they can win for now by messing with individual ad-blockers, but with 3rd party players becoming more popular, I can see that being a catch-all solution.
isn't this more or less what they're doing now? The difference is that the ads are coming from different server and have an overlay on top with a timer and a skip. As long as the ads are coming from a different server they will be detectable. Also as long as the ads have overlays they are also detectable. They would need to make the ads be served from the same server that serves the video and eliminate the overlays.
That's the difference. The ads are coming from somewhere else and displayed in a different way.
By injecting it into the stream, there's no way to detect that. To your player it would all look like it's coming from the same place. Instead of a ten minute video and a couple of 20 second ads, it's now just 11 minutes of video.
yes. But then they have different problems. Now it is the ad company who is responsible to serve the ads and the personalization comes from there. This is achieved by the client directly "asking" the ad company for ads. If they want the ads to come from the same stream this means that the customer identity is passed to youtube, then youtube requests the ads in behalf of the client, and then serves them mixed in the video stream. I'm not a lawyer but I think that this causes different legal problems for youtube on the part that they will need to ask the ads on behalf of someone else.
Also apart from that, technically, the part of the video that is an ad, will be associated with a call-to-action URL and an overlay on top of the video, since they need that by clicking on the video it will go to a the ad's call-to-action instead of just pausing the video. This will still make them detectable
The ad company is Google, no? So they already have that logic ready to go.
Does anybody actually click the ads in YT videos? The only clickable thing I ever see is "Skip Ad".
Clicks are a metric that Google/YouTube tracks to determine whether a business has to pay for that ad, so it's necessary for ads to be clickable.
Don't they have standardized resolutions and the file broken into hundreds/thousands of parts anyways? Couldn't they just add in ads to some of those parts in those same resolutions?
Similar to Apple's HTTP Live Streaming (HLS) solution, MPEG-DASH works by breaking the content into a sequence of small segments, which are served over HTTP.
isn't this more or less what they're doing now? The difference is that the ads are coming from different server and have an overlay on top with a timer and a skip. As long as the ads are coming from a different server they will be detectable. Also as long as the ads have overlays they are also detectable. They would need to make the ads be served from the same server that serves the video and eliminate the overlays.
We could build a public database (like SponsorBlock) of known ad video slices and detect them that way.
There will always be a way to detect and block ads.
I'm not worried.
That's why Google is pushing hard their Web Environment Integrity. It's DRM for the browser! They want the TPM chip in your computer to attest that the code running processing the video stream is authentic. Then you can't slice out the ads because you do not have physical access to the inside of TPM. With HDCP encryption on the HDMI video output, you gonna need to point a literal video camera at the physical screen to DVR the video and slice out the ads later.
They've been working hard for decades to lock down the video pipeline with TPM and HDCP and now WEI. They said "don't worry about it" and we let them. They are really close to snapping the trap shut!
Now please excuse me, my tongue is falling off with all the acronyms...
the reason they are not doing it is because the ads are personalized. So if they want to bake an ad onto a video they will end up with countless videos each on with their own unique ads which is not viable logistically. So they can only do it on-the-fly. But re-encoding each video on-the-fly for each user is also a nightmare logistically, if not impossible at all.
I don't think you'd need to re-encode the whole thing on the fly. More frigging the container data around, than the video/audio codec itself.
That way I could request some_pointless_video.mp4 and it sends me 95% the same thing as is already on their server, with adverts jammed into it at defined intervals.
They probably think they can win for now by messing with individual ad-blockers, but with 3rd party players becoming more popular, I can see that being a catch-all solution.
isn't this more or less what they're doing now? The difference is that the ads are coming from different server and have an overlay on top with a timer and a skip. As long as the ads are coming from a different server they will be detectable. Also as long as the ads have overlays they are also detectable. They would need to make the ads be served from the same server that serves the video and eliminate the overlays.
That's the difference. The ads are coming from somewhere else and displayed in a different way.
By injecting it into the stream, there's no way to detect that. To your player it would all look like it's coming from the same place. Instead of a ten minute video and a couple of 20 second ads, it's now just 11 minutes of video.
yes. But then they have different problems. Now it is the ad company who is responsible to serve the ads and the personalization comes from there. This is achieved by the client directly "asking" the ad company for ads. If they want the ads to come from the same stream this means that the customer identity is passed to youtube, then youtube requests the ads in behalf of the client, and then serves them mixed in the video stream. I'm not a lawyer but I think that this causes different legal problems for youtube on the part that they will need to ask the ads on behalf of someone else.
Also apart from that, technically, the part of the video that is an ad, will be associated with a call-to-action URL and an overlay on top of the video, since they need that by clicking on the video it will go to a the ad's call-to-action instead of just pausing the video. This will still make them detectable
The ad company is Google, no? So they already have that logic ready to go.
Does anybody actually click the ads in YT videos? The only clickable thing I ever see is "Skip Ad".
Clicks are a metric that Google/YouTube tracks to determine whether a business has to pay for that ad, so it's necessary for ads to be clickable.
Don't they have standardized resolutions and the file broken into hundreds/thousands of parts anyways? Couldn't they just add in ads to some of those parts in those same resolutions?
e.g: https://en.wikipedia.org/wiki/Dynamic_Adaptive_Streaming_over_HTTP
isn't this more or less what they're doing now? The difference is that the ads are coming from different server and have an overlay on top with a timer and a skip. As long as the ads are coming from a different server they will be detectable. Also as long as the ads have overlays they are also detectable. They would need to make the ads be served from the same server that serves the video and eliminate the overlays.
We could build a public database (like SponsorBlock) of known ad video slices and detect them that way.
There will always be a way to detect and block ads.
I'm not worried.
That's why Google is pushing hard their Web Environment Integrity. It's DRM for the browser! They want the TPM chip in your computer to attest that the code running processing the video stream is authentic. Then you can't slice out the ads because you do not have physical access to the inside of TPM. With HDCP encryption on the HDMI video output, you gonna need to point a literal video camera at the physical screen to DVR the video and slice out the ads later.
They've been working hard for decades to lock down the video pipeline with TPM and HDCP and now WEI. They said "don't worry about it" and we let them. They are really close to snapping the trap shut!
Now please excuse me, my tongue is falling off with all the acronyms...