920
No ads here!
(lemmy.world)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 10 Oct 2024
920 points (97.8% liked)
memes
9894 readers
3201 users here now
Community rules
1. Be civil
No trolling, bigotry or other insulting / annoying behaviour
2. No politics
This is non-politics community. For political memes please go to !politicalmemes@lemmy.world
3. No recent reposts
Check for reposts when posting a meme, you can only repost after 1 month
4. No bots
No bots without the express approval of the mods or the admins
5. No Spam/Ads
No advertisements or spam. This is an instance rule and the only way to live.
Sister communities
- !tenforward@lemmy.world : Star Trek memes, chat and shitposts
- !lemmyshitpost@lemmy.world : Lemmy Shitposts, anything and everything goes.
- !linuxmemes@lemmy.world : Linux themed memes
- !comicstrips@lemmy.world : for those who love comic stories.
founded 1 year ago
MODERATORS
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.
I was having some problems with playback on youtube with "buffering", random skips, the video reloading, etc. It turns out that those pauses and skips were for ads that uBlock stopped. Channels with more ad placements(new videos from large channels, large companies) would stop more often. Looking at the logs for Ublock showed me that yt does track how much of the video you have watched regardless of where you started. Say I load a video and skip to the middle. It will do a callout for time watched.
I am not sure if I'm right but anyone else could correct or expand on this as I am no expert in how youtube does anything these days.
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.
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.
You are correct, which goes into the cost category of doing a stream stitched integration. Also, when I left said ad server in 2016, I think I recall HLS streaming primarily supported by Apple devices. Devices like Roku's (don't quote me on that) didn't support it at the time so a lot of companies looked at where the majority of their streaming was occurring and decided it wasn't worth the hit.
As I know they transcode every uploaded video to their preferred format. They could use the same infrastructure for the ads. But maybe it's really too expensive.
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.
If there's timed annotations (like say for closed captions or chapters/sections), then there will be some sort of mechanism to line them up with the modified stream. Then compare that with a stream without ads (which might require manually removing all ads or using a premium account where ads aren't inserted) and you'll be able to estimate regions of the stream where ads have been inserted. If the timed annotations are dense, you could see where the ad begins and ends just from that.
Also if the ads themselves include timed annotations, there would be a difference in that meta data that would give it away immediately.
Or if ads are supposed to be unskippable, the metadata will need to let the client know about that. Though they could also do that on the server side and just refuse to stream anything else while it's serving an ad.
Given that, the solution might be to have a seperate program grab the steam and remove the ads for later playback. Or crowdsource that and set up torrents, though that would be exposing it to copyright implications.
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.
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.
For even trying to come up with ideas of how Google can fuck us even harder, some of these posters need a necktie from Colombia.
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
maybe ads should not be targeted.
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.