YouTube warns it might make your viewing experience worse if you don’t turn off your ad-blocker::YouTube has been cracking down on people using ad blockers. Now, a spokesperson says that using ad blockers could lead to “suboptimal viewing.”

  • mvirts@lemmy.world
    link
    fedilink
    English
    arrow-up
    26
    arrow-down
    1
    ·
    1 year ago

    YouTube is just messing around. They could encode ads randomly on videos if they wanted to, like podcasts.

    • FartsWithAnAccent@lemmy.world
      link
      fedilink
      English
      arrow-up
      26
      arrow-down
      1
      ·
      edit-2
      1 year ago

      There’s already a sponsor blocker extension that skips when a sponsor is even mentioned, it would be trivial to add other embedded ads to it.

      • n0xew@lemmy.world
        link
        fedilink
        English
        arrow-up
        7
        arrow-down
        2
        ·
        1 year ago

        They would just be able to create and stream 2 or more ad-encoded versions where ads are encoded in differently positions. Then no sponsorblock could save us since it would skip the wrong segments for some people…

      • ArxCyberwolf@lemmy.ca
        link
        fedilink
        English
        arrow-up
        2
        arrow-down
        1
        ·
        1 year ago

        That’s not quite how it works. It’s crowdsourced, someone has to manually add every sponsored segment from a video into Sponsorblock. It can’t detect them on its own.

    • Justin@lemmy.jlh.name
      link
      fedilink
      English
      arrow-up
      8
      ·
      1 year ago

      cheaper to just have the interns code buggy Javascript then to reencode millions of videos.

      • MiltownClowns@lemmy.world
        link
        fedilink
        English
        arrow-up
        10
        arrow-down
        2
        ·
        edit-2
        1 year ago

        This. I don’t exactly know how YouTube’s architecture works, but from running my own mediaserver i woild guess They don’t live transcode because that takes clock cycles on a graphics card or a CPU. They transcode a couple of different bitrate files to serve up and then just serve up direct stream file transfers, thus saving electricity and clock cycles. In order to actively embed an ad in a YouTube video it would have to be done semi-permanently, Decreasing the value of live serve ads.

        • bamboo@lemmy.blahaj.zone
          link
          fedilink
          English
          arrow-up
          9
          ·
          1 year ago

          You’re correct that they’re not doing live transcoding when a video is played. That’s way too expensive in every regard. There are still ways to embed ads dynamically into the video without requiring live transcoding. They likely have 5-10 qualities they encode to, and segment the video into 10s segments, so a 5 minute video would be cut into 30 segments, and then each of those files encoded to multiple qualities upon upload.

          That way when playing, if your Internet gets slow, the player can seamlessly downgrade to another quality. These small files concatenated together appear like one long video. Adding some ads served from the same servers as the content could be done dynamically for each request and be difficult to block without impacting the video content delivery, since you can’t have uBlock Origin block the domain hosting the content.

          Realistically, they probably don’t do this approach because you don’t know if the ad was loaded because of buffering, but never viewed, so the ad network gets less metrics and therefore the ads are less valuable. Also, I would bet the content upload and distribution team are completely separate from the ad team, so that cross collaboration is more difficult to implement.

          • my_hat_stinks@programming.dev
            link
            fedilink
            English
            arrow-up
            4
            ·
            1 year ago

            I think there’s a simpler reason; if you embed ads as part of the video linking to a specific timestamp becomes a nightmare. One person might have no ad, another might have a 30 second ad, and a third might have 5 minutes of ad. Attempting to link to a time after the ad would give three different timestamps, and loading that timestamp could give you the clip you want or could drop you right in the middle of an ad.

            To solve that issue you’d need some way for the client to determine the “true” timestamp, but then you’re also giving ad blockers a way to determine where the ad is so you’re back to square one.