There seems to be an abundance of the false notion that large corporations are somehow above governments on Lemmy ... and that's simply not true, at least for corporations that want have legitimate business within the country.
EDIT: So as to say ... perhaps the commenter (at least in the moment) was a bit awestruck seeing laws apply to tech (which often seems to feel as though it's above the law in some way).
It kinda depends where. GDPR in the EU is certainly an example of governments imposing their will on corporations. In the US, not so much, as corporations dump tons of money on lobbying that allow to them influence how they are regulated.
Myanmar, as a country, has a GDP of 62.26 billion usd.
Google has a market cap of 2.17 Trillion usd and made a profit of $305 billion usd last year.
Google makes more money in profit than moves through Myanmar in a year by nearly 5 times.
If Google chooses not to operate in their country because of some law they don't like, what's to stop them?
Google definitely has national government level influence, especially considering the pervasiveness of their product suite. Implying that they're above the law might be too far, but they for sure influence it.
If the most extreme happens and Google decided that some EU law was too much to deal with compared to the gains, a lot of Europeans could find themselves in a position where Google doesn't operate in their country. Imagine every Android device becoming unable to use the majority of the service they operate on, or the most common browser, search engine, email service, and video streaming services simultaneously being disabled. I can't imagine the people will be very happy about that.
Myanmar's average internet speed looks to be around 10-20mbps, so they probably stream with lower quality. Their GDP per capita is ~$1,150, so ads being shown to people in Myanmar wouldn't be worth much anyway.
Oh well. Youtube is useful as a podcast/streamer host now; no ads with sponsor block/ublock. Once that isn't the case they (Google) will get network blocked.
No real loss to me. I tend to prefer local download/host for convenience. Most channels are chaff anyway.
Sample the color of a specified pixel (or something recognizable in the streaming format) every 30 frames from the original video.
Store collection of pixels in a database and share in a peer to peer network or stored on invidious instances. Because the sample size is small, and the database can be split up by youtube channel, the overall size and traffic should remain low.
When streaming a youtube video, if the plugin detects that the pixel in the video doesn't match the one in the database, automatically skip until where the pixel matches the data in the database.
That is prone to error, just a pixel can be too small of a sample. I would prefer something with hashes, just a sha1sum every 5 seconds of the current frame. It can be computed while buffering videos and wait until the ad is over to splice the correct region
The problem with (good) hashes is that when you change the input even slightly (maybe a different compression algorithm is used), the hash changes drastically
Yes, that's why I'm proposing it as opposed to just one pixel to differentiate between ad and video. Youtube videos are already separated in sections, just add some metadata with a hash to every one.
I think that downsizing the scene to like 8x8 pixels (so basically taking the average color of multiple sections of the scene) would mostly work. In order to be undetected, the ad would have to match (at least be close to) the average color of each section, which would be difficult in my opinion: you would need to alter each ad for each video timestamp individually.
It's illegal to not identify an ad as an ad (unless you're a movie maker, but that's a different topic). All ad blockers need to do is read that indicator. That might not be super simple, but I have faith in the abilities of the brilliant people behind many ad-blocking technologies.
That's actually hurt by this because it uses timestamps supplied by users to work. But now they are off because the ads are of variable length. We can just hope that YouTube keeps the ability to link to a specific timestamp because then it has to calculate the difference and that can be used by Sponsorblock and adblockers alike.
The problem is those blocking extensions are based on timestamps. Those timestamps are added by the users, it's a crowdsourced thing. But the ads a single user will see differ from what another user will see. It's likely the length of the ads is different, which makes the whole timestamp thing a no go.
Along with the timestamp, there needs to be a way to detect where the actual video begins. That way at least an offset can be applied and timestamps maintained, but it would introduce a certain level of error.
The next issue would be to then advance the video to the place where the actual video begins. This can be very hard, as it would need to include some way of recognizing the right frame in the buffer. One requirement is that the starting frame is actually in the buffer (with ads more than a few seconds, this isn't guaranteed). The add-on has access to this buffer (depending on the platform, this isn't guaranteed). And there's a reliable way to recognize the right frame, given the different encoding en quality setups.
And this needs to be done cheap, so with as little as infrastructure as possible. A database of timestamps is very small and crowdsourcing those timestamps is relatively easy. But recognizing frames requires more data to be stored and crowdsourcing the right frame is a lot harder than a timestamp. If the infrastructure ends up being complex and big, someone needs to pay for that. I don't know if donations alone would cut it. So you would need to play ads, which is exactly what you intend on not doing.
I'm sure the very smart and creative people working on these things will find a way. But it won't be easy, so I don't expect a solution very soon.
You need more data to recognize frames, but not a lot more data. A hash for each quality setting would be sufficient as long as they don't start fuzzing the videos, which would be very expensive on their part.
Not really. They can precompute those and inject it in an MP4 file so long as the settings match and it's inserted right before an i-frame so that it doesn't corrupt b-frames. They already reencode everything with their preferred settings, so they only need to encode the ads for those same settings they already do. Just needs to be spliced seamlessly.
But YouTube uses DASH anyway, it's like HLS, the stream is served in individual small chunks so it's even easier because they just need to add chunks of ads where they can add mismatched video formats, for the same reason it's able to seamlessly adjust the quality without any audio glitches.
Re-encoding is one thing, but ads are more or less supposed to be dynamic based on user location and likely some other data to target them.
Offloading that to the client made a lot of sense but now they have to do this server-side, they have very smart people working on making this as efficient as possible using tricks you've mentioned and more but it is still more effort than before. All for something that will likely be circumvented eventually.
All of that targeting data lives on Google’s servers already. Your computer isn’t trying to figure out who you are and what you like each ad play, Google already knows who you are when your browser makes a request for a video. Everything you are talking about is already server-side.
Every bit of effort and resourcing they spend on this returns revenue directly. Which is more than they can probably say for a lot of things they do. And they’re smart enough to know that they can’t eliminate blocking, just make it harder and harder so that fewer and fewer people do it.
Paid subscriptions per month, you watch the newest video for free. Have the youtuber host the server themselves for their own videos and federate that access.
You can solve any problem with a Molotov cocktail. Any time I had a problem and I threw a Molotov cocktail, boom, right away, I had a different problem!
