9 ms·

> So, even if you're hiding the video, you're still punished by the wait, as your ad-blocker simulates an ad-watch. This is what happens in the TV app (or at l

> So, even if you're hiding the video, you're still punished by the wait, as your ad-blocker simulates an ad-watch. This is what happens in the TV app (or at least on my old tv) when the adserver legitimately times out. The solution (from YouTube’s pov) is of course super simple and we all pray the engineers at Google don’t think about it: inject the ad into the video stream.

tentacleuno 3y ago
An even "better" solution would be to bake the ads into the video stream at random intervals, to prevent something like SponsorBlock but for ads.
thejarren 3y ago
Well, the benefit then is that crowdsourced tools can skip directly over portions of the video. I already use an app called sponsor block that skips in video sponsored sections.
- zztop44 3y ago
  Not if it’s randomised. However that would make the video stream harder to cache.
  - lamontcg 3y ago
    That just moves the battle into identifying the ads when they play and then skipping over them and updating and maintaining the ad-identifier database. And heuristics/ML can probably be used to identify likely unknown ads.
    - ryandrake 3y ago
      You could probably detect 95% of randomly-inserted ads by just looking at 1. the abrupt change in audio volume and 2. a material change in some visual "fingerprint" of the video scene. If I'm watching Mister Influencer walking around outside talking with their face framed in the middle of the shot, and then all of a sudden, mid-stream, the audio gets 15% louder and the video changes to a meadow to advertise Tide detergent, that can be reliably detected without even ML.
      - moritzwarhier 3y ago
        Regardless of the 95% accuracy claim, I think this would cause to many false positives to be usable. Cuts that change visiual content and audio volume exist in original content, too.
LeafItAlone 3y ago
> the engineers at Google don’t think about it It’s an almost certainty that they’ve thought of it. This has been a worry for at least over a decade. So there must be some reason they “can’t” or don’t want to. Such as getting more valuable interaction data otherwise.
- Kon-Peki 3y ago
  > So there must be some reason they … don’t want to. …Starting with the fact that it would no longer be user-generated content that provides Google with Section 230 protection.
  - mikrotikker 3y ago
    The toothless section 230... Will they ever get that particular hammer out of its case?
- MrDrMcCoy 3y ago
  I would imagine it would be computationally untenable because it would mean the videos have to be re-encoded every time the ads need to be changed, which would be frequent enough to be very expensive. Plus, I'm not sure if they keep the original videos stored somewhere to re-use as a source to prevent degradation from re-encoding.
  - chii 3y ago
    i would imagine the video stream is spliced, such that the ad video stream is spliced into an existing pre-encoded video stream, may be between some keyframes or some such. This is how most livestreams works today - you have separate chunks of video streams that are spliced together. The only real problem is if the end user can detect (reliably) where a splice _could_ happen, they can just ignore the spliced video. This is what some old twitch adblocking methods did iirc - and just show a blank screen.
  - wodenokoto 3y ago
    But the videos are streamed to the users. So on the backend the could switch source back and forth and feed everything through the same endpoint

tentacleuno 3y ago

An even "better" solution would be to bake the ads into the video stream at random intervals, to prevent something like SponsorBlock but for ads.

thejarren 3y ago

Well, the benefit then is that crowdsourced tools can skip directly over portions of the video. I already use an app called sponsor block that skips in video sponsored sections.

zztop44 3y ago
Not if it’s randomised. However that would make the video stream harder to cache.
- lamontcg 3y ago
  That just moves the battle into identifying the ads when they play and then skipping over them and updating and maintaining the ad-identifier database. And heuristics/ML can probably be used to identify likely unknown ads.
  - ryandrake 3y ago
    You could probably detect 95% of randomly-inserted ads by just looking at 1. the abrupt change in audio volume and 2. a material change in some visual "fingerprint" of the video scene. If I'm watching Mister Influencer walking around outside talking with their face framed in the middle of the shot, and then all of a sudden, mid-stream, the audio gets 15% louder and the video changes to a meadow to advertise Tide detergent, that can be reliably detected without even ML.
    - moritzwarhier 3y ago
      Regardless of the 95% accuracy claim, I think this would cause to many false positives to be usable. Cuts that change visiual content and audio volume exist in original content, too.

LeafItAlone 3y ago

> the engineers at Google don’t think about it It’s an almost certainty that they’ve thought of it. This has been a worry for at least over a decade. So there must be some reason they “can’t” or don’t want to. Such as getting more valuable interaction data otherwise.

Kon-Peki 3y ago
> So there must be some reason they … don’t want to. …Starting with the fact that it would no longer be user-generated content that provides Google with Section 230 protection.
- mikrotikker 3y ago
  The toothless section 230... Will they ever get that particular hammer out of its case?
MrDrMcCoy 3y ago
I would imagine it would be computationally untenable because it would mean the videos have to be re-encoded every time the ads need to be changed, which would be frequent enough to be very expensive. Plus, I'm not sure if they keep the original videos stored somewhere to re-use as a source to prevent degradation from re-encoding.
- chii 3y ago
  i would imagine the video stream is spliced, such that the ad video stream is spliced into an existing pre-encoded video stream, may be between some keyframes or some such. This is how most livestreams works today - you have separate chunks of video streams that are spliced together. The only real problem is if the end user can detect (reliably) where a splice _could_ happen, they can just ignore the spliced video. This is what some old twitch adblocking methods did iirc - and just show a blank screen.
- wodenokoto 3y ago
  But the videos are streamed to the users. So on the backend the could switch source back and forth and feed everything through the same endpoint