So you would need buffer barrieres essentially.
Still user watches video. Ad avoidance skips forward to buffer barrier to play ad in the background. Streamed ad is thrown away and new buffer data is received. User does not notice if the video is long enough.
In this case the buffer limit is the metadata.
Yeah I’m thinking of a system like this:
A user opens a session to watch a video, the user is assigned a token to watch the requested video. When the user isn’t a premium subscriber and the video is monetized the token is used to enforce ads. To get video data from the server, the user needs to supply the token. That token contains a “credit” with how many seconds (or whatever they use internally) the user can watch for that video. In order to get seconds credited to the token, the user needs to stream ad content to their player. New ad content is only available to stream, once the number of seconds they were credited have been elapsed.
One way to get around this is to have something in the background “watch” the video for you, invisible, including the ads. Then records the video data, so it’s available for you to watch without ads. But it would be easy to rate limit the number of tokens a user can have. There’s ways to get around that as well. But this seems to me well beyond what a simple browser plugin can do, this would require a dedicated client.
The idea is to make it harder for users to get around the ads, so they’ll watch them instead of looking for a way to block ads. In the end there isn’t anything to be done, users can get around the ads. Big streaming services use DRM and everything and their content gets ripped and shared. With YouTube it would be easy for someone to have a Premium account, rip the vids and share them. But by putting up a barrier, people watch the ads. YouTube doesn’t care if a percentage of users doesn’t watch the ads, as long as most of them do.
My point was, there’s ways to implement the ads without sending metadata about the ads to the client.
