this post was submitted on 12 Jun 2024
374 points (99.2% liked)

Piracy: ꜱᴀɪʟ ᴛʜᴇ ʜɪɢʜ ꜱᴇᴀꜱ

53763 readers
1039 users here now

⚓ Dedicated to the discussion of digital piracy, including ethical problems and legal advancements.

Rules • Full Version

1. Posts must be related to the discussion of digital piracy

2. Don't request invites, trade, sell, or self-promote

3. Don't request or link to specific pirated titles, including DMs

4. Don't submit low-quality posts, be entitled, or harass others

Loot, Pillage, & Plunder

💰 Please help cover server costs.

Ko-FiLiberapay

founded 1 year ago
MODERATORS
db0@lemmy.dbzer0.com
sunbrothersco@lemmy.dbzer0.com
dataprolet@lemmy.dbzer0.com
Flatworm7591@lemmy.dbzer0.com
RandomLegend@lemmy.dbzer0.com
374
SponsorBlock (and DeArrow): "YouTube is currently experimenting with server-si…" - Fosstodon (fosstodon.org)
submitted 2 months ago by sabreW4K3@lazysoci.al to c/piracy@lemmy.dbzer0.com
91 comments fedilink hide all child comments
 

YouTube is currently experimenting with server-side ad injection. This means that the ad is being added directly into the video stream.

This breaks sponsorblock since now all timestamps are offset by the ad times.

For now, I set up the server to detect when someone is submitting from a browser with this happening and rejecting the submission to prevent the database from getting filled with incorrect submissions.

you are viewing a single comment's thread
view the rest of the comments
[–] ReversalHatchery@beehaw.org 9 points 2 months ago

Ads need to be tailored to the user when delivered

  1. It does not. If you install a new browser and open YouTube the first time, they'll be able to show ads to you
  2. They could be tailored based on other factors too, like country, region, or even household by the IP

I think the backend could just generate the ad ridden video feed for the specific user. Most probably it would be very resource intensive, but I can only hope so.. but then I also don't know much about HLS and other fragmented streams so it might not be a performance problem at all.

like a linked list

I think the full list of chunks is (currently) known beforehand. That's how yt-dlp can download on multiple threads, but also how it can show the number of total fragments relatively quickly on the progress bar