- cross-posted to:
- [email protected]
- cross-posted to:
- [email protected]
YouTube warns it might make your viewing experience worse if you don’t turn off your ad-blocker::YouTube has been cracking down on people using ad blockers. Now, a spokesperson says that using ad blockers could lead to “suboptimal viewing.”
YouTube is just messing around. They could encode ads randomly on videos if they wanted to, like podcasts.
There’s already a sponsor blocker extension that skips when a sponsor is even mentioned, it would be trivial to add other embedded ads to it.
They would just be able to create and stream 2 or more ad-encoded versions where ads are encoded in differently positions. Then no sponsorblock could save us since it would skip the wrong segments for some people…
Those ads would need to be unskippable, otherwise we could just pull the timestamps that the Skip button uses and sponsorblock will be all complete again 👌
Fair point! I wasn’t thinking they would be skippable, but boy do I hope that I was wrong…
Even if they’re not natively skippable, ads have to be indicated as such by law. Whatever indication they use can be detected and used to create blockers.
Ad blocking, uh, finds a way.
Just build a database of ads. Then use some kind of image hash to compare against the displayed content.
I like your way of thinking. This isn’t even limited to image. Comparing just a short snippet of the audio from a playing ad to a db could work very well too, thinking of how quickly Shazam etc. are able to identify a song if it’s in the db.
App/plugin idea for the sad future right there: Shazadblock, tuneBlock Origin. Succesful ID leads to skip/mute/ragequit or whatever will kill the noise. Though, the downside of this method would be if an ad in the db uses licensed music that regular content creators use in their videos too, it will eventually lead to blocking some segments wrongly, unless the db excludes this, making it less effective at its purpose… Maybe image is better.
That’s not quite how it works. It’s crowdsourced, someone has to manually add every sponsored segment from a video into Sponsorblock. It can’t detect them on its own.
I never said it did?
cheaper to just have the interns code buggy Javascript then to reencode millions of videos.
This. I don’t exactly know how YouTube’s architecture works, but from running my own mediaserver i woild guess They don’t live transcode because that takes clock cycles on a graphics card or a CPU. They transcode a couple of different bitrate files to serve up and then just serve up direct stream file transfers, thus saving electricity and clock cycles. In order to actively embed an ad in a YouTube video it would have to be done semi-permanently, Decreasing the value of live serve ads.
You’re correct that they’re not doing live transcoding when a video is played. That’s way too expensive in every regard. There are still ways to embed ads dynamically into the video without requiring live transcoding. They likely have 5-10 qualities they encode to, and segment the video into 10s segments, so a 5 minute video would be cut into 30 segments, and then each of those files encoded to multiple qualities upon upload.
That way when playing, if your Internet gets slow, the player can seamlessly downgrade to another quality. These small files concatenated together appear like one long video. Adding some ads served from the same servers as the content could be done dynamically for each request and be difficult to block without impacting the video content delivery, since you can’t have uBlock Origin block the domain hosting the content.
Realistically, they probably don’t do this approach because you don’t know if the ad was loaded because of buffering, but never viewed, so the ad network gets less metrics and therefore the ads are less valuable. Also, I would bet the content upload and distribution team are completely separate from the ad team, so that cross collaboration is more difficult to implement.
I think there’s a simpler reason; if you embed ads as part of the video linking to a specific timestamp becomes a nightmare. One person might have no ad, another might have a 30 second ad, and a third might have 5 minutes of ad. Attempting to link to a time after the ad would give three different timestamps, and loading that timestamp could give you the clip you want or could drop you right in the middle of an ad.
To solve that issue you’d need some way for the client to determine the “true” timestamp, but then you’re also giving ad blockers a way to determine where the ad is so you’re back to square one.
They could, what can go wrong…