I am not for ads but what is so difficult about adding them to the video stream. This should make adblockers useless since they can’t differentiate between the video and the ad. I could just imagine it would be difficult to track the view time of the user and this could make the view useless since they can’t prove it to the ad customer. I have no in depth knowledge about hls but as I know it’s an index file with urls to small fragments of the streamed file. The index file could be regenerated with inserted ad parts and randomized times to make blocking specific video segments useless.
I worked at a video ad server that offered a stream stitched solution going back to 2013. It comes down to development work/cost that the companies need to take on. Ultimately they would benefit from the cost required, but they wanted to be cheap and do a client side solution instead.
The HLS integration we offered definitely had a premium attached to it as well as an additional cost to the CDN that required the integration to live on. So it’s not cheap.
It is weird that Google, with it’s infinite pockets, hasn’t pushed a stream stitched solution all these years until recently.
YouTube serves probably dozens of formats/bitrates, and has spent years tweaking how it ingests, transcodes, and serves videos. Adding in-stream ads might have been a bigger engineering task in that environment. Depending on the percentage of users/viewers avoiding ads, it might not have been worth the return.
Twitch already does this for their livestreams and has been doing it for years. I’m just surprised that YouTube has taken this long to get around to injecting advertisements into the video stream. Although I think if YouTube decided to try ad injection the adblocking community would fire back with something novel to thwart their efforts and the eternal arms race would continue.
It already happens, videos contain sponsored segments added by the creator.
But even those have a solution in the form of Sponsorblock, which crowdfunds the location in the video containing sponsored segments in order to skip them.
Google should face the fact that they won’t ever be able to win.
Cause you need to insert it every time for every viewer. People get different ads and those ads obviously change over time. So embedding one ad into the video permanently makes no sense.
I’m pretty sure YouTube does it the way they do cause the alternative is not feasible.
You can still do dynamic ad serving in a stream stitched integration. It’s just that the content and the ads are being served by the same CDN, hence why you can’t block the ads without also blocking the content. In the manifest file there are m3u8 chucks, the file is essentially broken up into 5/10 second chunks, and when the video segment chunk is coming to an ad break, it stitches in dynamically an ad m3u8 chunk that the ad server dynamically selects based on the ads they currently have trafficked in their system.
That wouldn’t make sense in the case of hls since the stream consists of multiple fragments of a video and you would just insert the ad fragments. This would only require changing the index file which could be done again and again with no effort and needs no reencoding of the video file.
I am not for ads but what is so difficult about adding them to the video stream. This should make adblockers useless since they can’t differentiate between the video and the ad. I could just imagine it would be difficult to track the view time of the user and this could make the view useless since they can’t prove it to the ad customer. I have no in depth knowledge about hls but as I know it’s an index file with urls to small fragments of the streamed file. The index file could be regenerated with inserted ad parts and randomized times to make blocking specific video segments useless.
I worked at a video ad server that offered a stream stitched solution going back to 2013. It comes down to development work/cost that the companies need to take on. Ultimately they would benefit from the cost required, but they wanted to be cheap and do a client side solution instead.
Ah yes that makes a lot of sense. Googles war on adblockers seems really expensive but we don’t know the numbers maybe it’s still cheaper.
The HLS integration we offered definitely had a premium attached to it as well as an additional cost to the CDN that required the integration to live on. So it’s not cheap.
It is weird that Google, with it’s infinite pockets, hasn’t pushed a stream stitched solution all these years until recently.
YouTube serves probably dozens of formats/bitrates, and has spent years tweaking how it ingests, transcodes, and serves videos. Adding in-stream ads might have been a bigger engineering task in that environment. Depending on the percentage of users/viewers avoiding ads, it might not have been worth the return.
Twitch already does this for their livestreams and has been doing it for years. I’m just surprised that YouTube has taken this long to get around to injecting advertisements into the video stream. Although I think if YouTube decided to try ad injection the adblocking community would fire back with something novel to thwart their efforts and the eternal arms race would continue.
I’ve read in that thread that there are already ad blockers for twitch too but I haven’t looked up how they work or how twitch inserts the ads.
They work, most of the time. Just a bit clunky.
The most likely situation is just having apps that watch the content, trim the ads off, then drop it off into a folder.
You get home, watch your downloads, put it up for the night.
It already happens, videos contain sponsored segments added by the creator.
But even those have a solution in the form of Sponsorblock, which crowdfunds the location in the video containing sponsored segments in order to skip them.
Google should face the fact that they won’t ever be able to win.
Sponsorblock works with static timestamps provided by users. This would not work if the ads are inserted at randomized times.
Cause you need to insert it every time for every viewer. People get different ads and those ads obviously change over time. So embedding one ad into the video permanently makes no sense. I’m pretty sure YouTube does it the way they do cause the alternative is not feasible.
maybe ads should not be targeted.
You can still do dynamic ad serving in a stream stitched integration. It’s just that the content and the ads are being served by the same CDN, hence why you can’t block the ads without also blocking the content. In the manifest file there are m3u8 chucks, the file is essentially broken up into 5/10 second chunks, and when the video segment chunk is coming to an ad break, it stitches in dynamically an ad m3u8 chunk that the ad server dynamically selects based on the ads they currently have trafficked in their system.
Exactly
That wouldn’t make sense in the case of hls since the stream consists of multiple fragments of a video and you would just insert the ad fragments. This would only require changing the index file which could be done again and again with no effort and needs no reencoding of the video file.