Those certainly are words, but how does this jump cut detection algorithm work?
Embedding an ad doesn’t need to change any of the video stream information in a serious way. It’s not like they’re going to do something obvious like change the colorspace and encoding scheme several times just for ads, because that would provide artifacts for these types of mitigation techniques. And even if they did, how is that any different from changing the quality of the stream to continue serving video despite degraded or improved network connections? Google could decide to implement random quality changes and break this particular workaround.
Plus, if they’re embedding ads into the data stream, how exactly is the metadata going to change? It’s the same connection, served from the same location, over the same socket. It’s not like sections of video need to have “AD” in the middle of their encoded data streams.
The “proper” solution here is to embed the ad in the stream and transfer the resulting higher with DRM protections. You can still probably get around it with add-ons like SponsorBlock, but that takes way more effort and YouTube could randomly distribute them in the video so they aren’t as easy to detect.
It’s totally possible and probably not that hard, so I’m grateful YouTube hasn’t done it.
No, but Netflix and other video services do it, so it’s totally feasible. I assume most of the cdn infra YouTube already does would stay the same, the main change would be the insertion of ads (they already do video processing) and encryption (which is probably not that hard).
DRM adds such a massive amount of overhead and is an absolute bastard to implement properly. Plus, it’s pretty easy to circumvent most DRM schemes when it comes to media.
But the ad blocking algorithm can notice the jump cut, (simple audio/video/meta data.) irregularities and then just jump forward to the regular video.
Those certainly are words, but how does this jump cut detection algorithm work?
Embedding an ad doesn’t need to change any of the video stream information in a serious way. It’s not like they’re going to do something obvious like change the colorspace and encoding scheme several times just for ads, because that would provide artifacts for these types of mitigation techniques. And even if they did, how is that any different from changing the quality of the stream to continue serving video despite degraded or improved network connections? Google could decide to implement random quality changes and break this particular workaround.
Plus, if they’re embedding ads into the data stream, how exactly is the metadata going to change? It’s the same connection, served from the same location, over the same socket. It’s not like sections of video need to have “AD” in the middle of their encoded data streams.
The “proper” solution here is to embed the ad in the stream and transfer the resulting higher with DRM protections. You can still probably get around it with add-ons like SponsorBlock, but that takes way more effort and YouTube could randomly distribute them in the video so they aren’t as easy to detect.
It’s totally possible and probably not that hard, so I’m grateful YouTube hasn’t done it.
I’m guessing you never had to implement drm and caching on a large scale video cdn before.
No, but Netflix and other video services do it, so it’s totally feasible. I assume most of the cdn infra YouTube already does would stay the same, the main change would be the insertion of ads (they already do video processing) and encryption (which is probably not that hard).
DRM adds such a massive amount of overhead and is an absolute bastard to implement properly. Plus, it’s pretty easy to circumvent most DRM schemes when it comes to media.
Sure, but it’s another barrier to entry, and it gives Google more license to sue under the DMCA.