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.
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.
Ah ok I didn’t know the EU thing. For the algorithm it’s a cat and mouse game. You could try to detect it by hash signatures of the segments or some kind of image detection but they could in turn add bytes to change the signature or other attributes. Could require a lot of effort on the blocking site to have the indicators up to date.
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.
You would also have to make skipping to any point in the video impossible then as folks could just jump ahead until they are past the embedded ad.
Out of order requesting of segments could be detected as well as faster requests. This would at least lead to a waiting time for the length of the ad.
What if all ads are 30seconds long, would it be impossible to lock skipping anywhere for the first 30seconds of every video?
Yes for example if you return always the same segment when skipping.
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.
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.
Even at randomized times, we could create an algorithm to detect them.
Especially since they are obliged by the EU to clearly label ads. So just look for the label.
Ah ok I didn’t know the EU thing. For the algorithm it’s a cat and mouse game. You could try to detect it by hash signatures of the segments or some kind of image detection but they could in turn add bytes to change the signature or other attributes. Could require a lot of effort on the blocking site to have the indicators up to date.
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.
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.