My gut reaction is that this won't work long-term. Users on youtube often point to specific timestamps in a video in comments or link to specific timestamps when sharing videos, meaning there needs to be some way to identify the timestamp excluding ads. And if there's a way to do that there's a way to detect ads.
Of course, there's always the chance they just scrap these features despite how useful they are and how commonly they're used; they've done similar before.
Feedback across the Firefox and YouTube subreddits highlighted that it could break timestamped video links and chapter markers. However, YouTube knows the length of the ads it would inject, and can offset subsequent timestamps suitably.
The move also adds a layer of unnecessary complexity in saving Premium viewers from these ads. If they are added server-side, the YouTube client would have to auto-skip them for Premium members, but that also means ad segment info will be relayed to the client, opening up a window of opportunity for ad blockers to use the same information meant for Premium subscribers and skip injected ads automatically.
It sounds like there's a silver lining after all.
The ads won’t be baked in beforehand, they’ll be injected into the stream in real time. Videos are broken into chunks and sent over HTTP, they’ll just put ad chunks in during playback. There is no need to re-encode anything. If you deep link to a timestamp, the video just starts from that timestamp as normal. If you are a Premium user, the server just never injects the ads.
But you are correct that the client needs to be aware that ads are happening, so they can be indicated on screen, and so click-throughs are activated.
This is why Chrome went to Manifest v3 - so you can’t have any code looking for ad signals running on the page to try to counter it.
But you are correct
That's what the article says, not me! lol
Surely at the server side it knows the premium status of the user it is supplying the video to, so just wouldn't insert the ads? I don't see why that would need to be client side.
YT already scrapped (or broke) setting the start/end timestamps for embedded videos. That hasn't worked for at least the last few weeks. Embed videos now always start at 0
I embedded a video yesterday with a start timestamp and it worked
Did they change the params or something?
I have YT embed support in Tesseract, and videos with timestamps broke a few weeks ago (they all start at 0 now). I've tried both t= and start= formats: neither worked.
You can still link to the YT video directly with those, though, but I've been unable to get embeds to honor them.
't=' works for me, but I'm just right clicking and getting it manually to put in docs.
Hmm. Like a Word doc? Maybe it's just embeds (with timestamps) on other websites that are broken?
I tried using the embed URLs directly in a browser tab, and those refuse to play at all (they still work embedded, though).
Definitely something that changed in the last few weeks. The test posts I had are from months ago and worked then.
Ya on second thought, I don't think I'm using embedding in the best way and what I'm saying isn't really related to that. I'm not actually embedding anything.
I'm prette sure they have to send the metadata to the client where an ad starts and ends. Just to make the ad clickable.
Timestamps can be calculated on the server, but maybe there will be an api endpoint that can be abused to search for the ads.
My gut reaction is that this won't work long-term. Users on youtube often point to specific timestamps in a video in comments or link to specific timestamps when sharing videos, meaning there needs to be some way to identify the timestamp excluding ads. And if there's a way to do that there's a way to detect ads.
Of course, there's always the chance they just scrap these features despite how useful they are and how commonly they're used; they've done similar before.
It sounds like there's a silver lining after all.
The ads won’t be baked in beforehand, they’ll be injected into the stream in real time. Videos are broken into chunks and sent over HTTP, they’ll just put ad chunks in during playback. There is no need to re-encode anything. If you deep link to a timestamp, the video just starts from that timestamp as normal. If you are a Premium user, the server just never injects the ads.
But you are correct that the client needs to be aware that ads are happening, so they can be indicated on screen, and so click-throughs are activated.
This is why Chrome went to Manifest v3 - so you can’t have any code looking for ad signals running on the page to try to counter it.
That's what the article says, not me! lol
Surely at the server side it knows the premium status of the user it is supplying the video to, so just wouldn't insert the ads? I don't see why that would need to be client side.
YT already scrapped (or broke) setting the start/end timestamps for embedded videos. That hasn't worked for at least the last few weeks. Embed videos now always start at 0
I embedded a video yesterday with a start timestamp and it worked
Did they change the params or something?
I have YT embed support in Tesseract, and videos with timestamps broke a few weeks ago (they all start at 0 now). I've tried both
t=andstart=formats: neither worked.You can still link to the YT video directly with those, though, but I've been unable to get embeds to honor them.
't=' works for me, but I'm just right clicking and getting it manually to put in docs.
Hmm. Like a Word doc? Maybe it's just embeds (with timestamps) on other websites that are broken?
I tried using the embed URLs directly in a browser tab, and those refuse to play at all (they still work embedded, though).
Definitely something that changed in the last few weeks. The test posts I had are from months ago and worked then.
Ya on second thought, I don't think I'm using embedding in the best way and what I'm saying isn't really related to that. I'm not actually embedding anything.
I'm prette sure they have to send the metadata to the client where an ad starts and ends. Just to make the ad clickable.
Timestamps can be calculated on the server, but maybe there will be an api endpoint that can be abused to search for the ads.