Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Yt-dlp: Upcoming new requirements for YouTube downloads

github.com

Post reply on HN
Print view View original

231–240 of 635 posts

Re: Yt-dlp: Upcoming new requirements for YouTube downloads

#231

Post by Aperocky »

Andrews54757 wrote: post #30

Nsig/sig - Special tokens which must be passed to API calls, generated by code in base.js (player code). This is what has broken for yt-dlp and other third party clients. Instead of extracting the code that generates those tokens (eg using regular expressions) like we used to, we now need to run the whole base.js player code to get these tokens because the code is spread out all over the player code. PoToken - Proof…

And barely a few days after google did it the fix is in.

Amazing how they simply couldn't win - you deliver content to client, the content goes to the client. Could be the largest corporation of the world and we still have yt-dlp.

That's why all of them wanted proprietary walled gardens where they would be able to control the client too - so you get to watch the ads or pay up.

Re: Yt-dlp: Upcoming new requirements for YouTube downloads

#232

Post by codedokode »

baxuz wrote: post #174
codedokode wrote: post #150

Earlier quoted context omitted.

Music labels publish the music on YT in exchange for ad revenue, they won't be happy if someone would download their music for free, and making music is expensive, google how much just a single drum mic costs and you need lot of them.

> for paying customers

YT shares income from subscriptions with music labels? I didn't hear about this, and even if they shared the download must be paid much higher than a view because after downloading a person could potentially listen for a track hundred times in a row.

Re: Yt-dlp: Upcoming new requirements for YouTube downloads

#233

Post by HankStallone »

mavhc wrote: post #105
phplovesong wrote: post #103

Youtube is the real monopoly. Creators are also slaves, as they cant monetize elsewhere, and also they cant let their users download their own content. And the icing on the cake is youtube is unbearable without an ad-blocker, and even with that youtube has started throttling ad-block users. Its such a shithole, with no real replacement, sad state of affairs.

why can't they monetize elsewhere?

Some do, and those who are able to make the move to patronage or subscriber monetization seem much happier for it. But that's most viable for creators who have already built up a viable customer base, which usually started on YouTube. It's much harder if you start out somewhere else.

Re: Yt-dlp: Upcoming new requirements for YouTube downloads

#234

Post by moralestapia »

beala wrote: post #64
piyuv wrote: post #9

I’m a paying YouTube premium subscriber. Last weekend, I wanted to download something so I can watch it on my way in the train. The app got stuck at “waiting for download..” on my iPad. Same on iPhone. Restart did not work. I gave up after an hour (30 mins hands on trying stuff, 30 mins waiting for it to fix itself). Downloaded the video using yt-dlp, transferred it to my USB c flash drive, and watched it from that.…

I'm also a premium subscriber, and have struggled with the same issues on the iPad app. I try to keep some shows downloaded for my toddler, and the download feature never seems to work on the first try. I finally got so fed up, I bought a Samsung Galaxy Tab A7 off ebay for $50 and flashed it with LineageOS. I can now load whatever media I want onto the 1 TB sdcard I've installed in it. The 5 year old hardware plays v…

Tangential.

The TIDAL app is absolute trash, it has this same issue all the time; not just that, but also, if a download fails it just hangs there and does not download the rest of the album/playlist.

Also, why would you want to download things in the first place? To watch them offline, right? Well, guess what happens when you open the app w/o an internet connection ... it asks you to login, so you cannot even access your music. 900k/year TOC genius work there.

The only reason why I haven't canceled is because I'm too lazy to reset my password in order to login and cancel, lol. Might do it soon, though.

Re: Yt-dlp: Upcoming new requirements for YouTube downloads

#236

Post by m_ke »

raincole wrote: post #186
m_ke wrote: post #24

I used to work on video generation models and was shocked at how hard it was to find any videos online that were not hosted on YouTube, and YouTube has made it impossibly hard to download more than a few videos at a time.

> YouTube has made it impossibly hard to download more than a few videos at a time I wonder why. Perhaps because people use bots to mass-crawl contents from youtube to train their AI. And Youtube prioritizes normal users who only watch a few videos at most at the same time, over those crawling bots. Who knows?

I wonder how Google built their empire. Who knows? I’m sure they didn’t scrape every page and piece of media on the internet and train models on it.

My point was that the large players have monopoly hold on large swaths of the internet and are using it to further advantage themselves over the competition. See Veo 3 as an example, YouTube creators didn’t upload their work to help Google train a model to compete with them but Google did it anyways, and creators didn’t have a choice because all eye balls are on YouTube.

Re: Yt-dlp: Upcoming new requirements for YouTube downloads

#237

Post by eth0up »

sphars wrote: post #40
jumpocelot wrote: post #27

Earlier quoted context omitted.

"In 2025, YouTube started rolling out a new streaming protocol, known as SABR, which breaks down the video into smaller chunks whose internal URLs dynamically change rather than provide one whole static URL. This is problematic because it prevents downloaders (such as yt-dlp) from being able to download YouTube videos at resolutions higher than 360p due to only detecting format code 18 (which is the only format code…

Thanks for the comment, OP just throwing out just "SABR" like we're all supposed to know what it means.

Sorry, I saw the submission (no votes and aging), upvoted it and left the comment thinking the post would die. But someone thankfully did what I should have.

Re: Yt-dlp: Upcoming new requirements for YouTube downloads

#238

Post by Beretta_Vexee »

dylan604 wrote: post #224
Beretta_Vexee wrote: post #133

Earlier quoted context omitted.

Once JavaScript is running, it can perform complex fingerprinting operations that are difficult to circumvent effectively. I have a little experience with Selenium headless on Facebook. Facebook tests fonts, SVG rendering, CSS support, screen resolution, clock and geographical settings, and hundreds of other things that give it a very good idea of whether it's a normal client or Selenium headless. Since it picks a ce…

why can a bot dev not just get all of these values from the laptop's settings and hardwire the headless version to have the same values?

Because the expected values are not fixed, it is possible to measure response times and errors to check whether something is in the cache or not, etc.

There are a whole host of tricks relating to rendering and positioning at the edge of the display window and canvas rather than the window, which allow you to detect execution without rendering.

To simulate all this correctly, you end up with a standard browser, standard execution times, full rendering in the background, etc. No one wants to download their YouTube video at 1x speed and wait for the adverts to finish.

Re: Yt-dlp: Upcoming new requirements for YouTube downloads

#239

Post by supriyo-biswas »

ACCount37 wrote: post #124
supriyo-biswas wrote: post #117

Earlier quoted context omitted.

From my perspective both problems are effectively the same. I want to count unique users by checking for asset downloads and correlating unique session IDs. People can request the static assets directly, leading to view booting and waste of egress bandwidth. The solution: have clients prove they are a legitimate client by running some computationally intensive JS that interacts with DOM APIs, etc. (which is not in an…

No, the difference is: if I'm fighting viewbots, I want zero cues to be emitted to the client. The client should NEVER know whether its view is being counted or not, or why. Having no reliable feedback makes it so much harder for a viewbotter to find a workaround. If there's a visible block on video downloads? They're not fighting viewbots with that.

For general spam deterrence I agree, but how do you prevent paying for the bandwidth in this case?

Re: Yt-dlp: Upcoming new requirements for YouTube downloads

#240

Post by codedokode »

AbuAssar wrote: post #120

on why they chose Deno instead of node: "Other JS runtimes (node/bun) could potentially be supported in the future, the issue is that they do not provide the same security features and sandboxing that deno has. You would be running untrusted code on your machine with full system access. At this point, support for other JS runtimes is still TBD, but we are looking in to it."

While deno has sandboxing, it also has potential access to hundreds of dangerous functions, it might be better just to write a tiny wrapper around JS engine that adds only the function to write to stdout.
Post reply on HN