When ads are a distinct bit of content recognized by the client, then the casual user with the stock client/no add-ons can’t overcome the UI choice to block you from seeking unless youtube lets you. But this allows ad blockers to skip even downloading the ad, because it’s clear what is content and what is ad.
If the ad is completely “just part of the stream” with zero indication where ads begin and end, then you can at least seek back and forth, with not even the official client able to block you from seeking, because it doesn’t know where the ads are either. The client downloads the stream.
If the stream is accompanied by some metadata letting the client know when to block seeking, then ad blockers can use that to auto-seek.
I suspect the last one is going to be the case, because they both want to limit seeking during ad, and they also want to change things to an ad experience so that you ‘click through’ to what the ad is trying to get you to do.
You can fast forward on yt though :p, so unless they remove that for the duration of the ad (in which case an addon could possibly use that to determine if an ad is being played) you could at least skip it manually. And maybe there’d be a crowd sourced solution to somehow determine the actual videos beginning (like detecting the first frame of the actual video or something, idk).
What’s to stop them from timestamping the time they sent you the ad and wait until like 90% of that time has gone by until they send you the video? It’s all server-side, nothing a plugin can do.
Plugins could have lengthy buffers and a start-up delay, not ideal obviously, but some people and for some videos, people might be willing to wait. Alternatively as many others have mentioned in this post, a plugin could mute the audio and/or black out the video if it detects an ad playing. There are trade offs, but it’s a workable approach as well.
Honestly that’s not much better than muting and doing something else like we used to do with cable. If it gets to this point, I’ll be long gone, probably to curiositystream or nebula.
Image Recognition could attatch the first frame of an ad to the length of time the ad plays for, then add it to an online DB a la sponserblock.
They might try to block seeking during these sections, but YouTube usually has raw mp4 streams available under the hood. You can even pull them using invidious or newpipe. Take that out and we might be fucked.
A good way to block this kind of thing is just to use DRM. Most platforms now provide a completely blocked off and secure hardware DRM solution that makes it impossible to grab video frames or view decrypted data in any way from the host operating system or any app running on it.
Ripping the video segments would just give you encrypted and useless data without the license.
These kinds of systems would need to be attacked by HDMI or other downstream hacks, or an HD video camera pointed at the screen in a dark room :)
I don’t know youd be able to do it within a browser extension but something like newpipe or yt-dlp?
Public Invidious Instances would be tough because that’s a lot of load to stick on a server, especially one run by a hobbiest. But self-hosted single/low user instances could also feasibly do this.
Obviously its gonna take a good bit of work, but it IS doable.
In the extremely rare event that I watch a youtube video on a my phone, and an ad comes on, I mute sound and literally turn my head away. Advertisers can’t do shit about that lol.
If they do it properly, you won’t be able to do it.
There will always be a way
Can you skip ads on live TV? No.
With a DVR? Yes.
When ads are a distinct bit of content recognized by the client, then the casual user with the stock client/no add-ons can’t overcome the UI choice to block you from seeking unless youtube lets you. But this allows ad blockers to skip even downloading the ad, because it’s clear what is content and what is ad.
If the ad is completely “just part of the stream” with zero indication where ads begin and end, then you can at least seek back and forth, with not even the official client able to block you from seeking, because it doesn’t know where the ads are either. The client downloads the stream.
If the stream is accompanied by some metadata letting the client know when to block seeking, then ad blockers can use that to auto-seek.
I suspect the last one is going to be the case, because they both want to limit seeking during ad, and they also want to change things to an ad experience so that you ‘click through’ to what the ad is trying to get you to do.
You can fast forward on yt though :p, so unless they remove that for the duration of the ad (in which case an addon could possibly use that to determine if an ad is being played) you could at least skip it manually. And maybe there’d be a crowd sourced solution to somehow determine the actual videos beginning (like detecting the first frame of the actual video or something, idk).
What’s to stop them from timestamping the time they sent you the ad and wait until like 90% of that time has gone by until they send you the video? It’s all server-side, nothing a plugin can do.
Plugins could have lengthy buffers and a start-up delay, not ideal obviously, but some people and for some videos, people might be willing to wait. Alternatively as many others have mentioned in this post, a plugin could mute the audio and/or black out the video if it detects an ad playing. There are trade offs, but it’s a workable approach as well.
Honestly that’s not much better than muting and doing something else like we used to do with cable. If it gets to this point, I’ll be long gone, probably to curiositystream or nebula.
Image Recognition could attatch the first frame of an ad to the length of time the ad plays for, then add it to an online DB a la sponserblock.
They might try to block seeking during these sections, but YouTube usually has raw mp4 streams available under the hood. You can even pull them using invidious or newpipe. Take that out and we might be fucked.
A good way to block this kind of thing is just to use DRM. Most platforms now provide a completely blocked off and secure hardware DRM solution that makes it impossible to grab video frames or view decrypted data in any way from the host operating system or any app running on it.
Ripping the video segments would just give you encrypted and useless data without the license.
These kinds of systems would need to be attacked by HDMI or other downstream hacks, or an HD video camera pointed at the screen in a dark room :)
Its bad enough they use widevine on their free movies/shows but the idea of them requiring widevine for regular YouTube sounds awful.
Hopefully legacy clients/devices will stave that off until something else comes along.
Actually, they might “win” the ad block arms race with drm. Shit. It’s the atomic option
Show me the image recognition API in the browser docs :)
I don’t know youd be able to do it within a browser extension but something like newpipe or yt-dlp?
Public Invidious Instances would be tough because that’s a lot of load to stick on a server, especially one run by a hobbiest. But self-hosted single/low user instances could also feasibly do this.
Obviously its gonna take a good bit of work, but it IS doable.
Train an AI to detect ads and voila
Product review video, blocked. Product is mentioned in a video, blocked. Product is shown too long, blocked.
“AI” isn’t smart enough to do it and it would require your computer to be powerful enough to not convert videos to PowerPoints.
Sounds like a win-win situation. 🤷♂️
Lmao
It’s fairly easy to block any user access to video buffers using DRM
I am 100% fine with letting it play realtime in the background, having a plugin record that like ye olde VCR, and then skipping adds manually.
You typically can’t record DRM content, you might be able to crack HDMI security and record that way.
Hardware DRM doesn’t expose decrypted video data to anything in the host operating system
In the extremely rare event that I watch a youtube video on a my phone, and an ad comes on, I mute sound and literally turn my head away. Advertisers can’t do shit about that lol.