←back to thread

428 points Leftium | 1 comments | | HN request time: 0.204s | source
Show context
molticrystal ◴[] No.45306399[source]
The claim that Google secretly wants YouTube downloaders to work doesn't hold up. Their focus is on delivering videos across a vast range of devices without breaking playback(and even that is blurring[0]), not enabling downloads.

If you dive into the yt-dlp source code, you see the insane complexity of calculations needed to download a video. There is code to handle nsig checks, internal YouTube API quirks, and constant obfuscation that makes it a nightmare(and the maintainers heroes) to keep up. Google frequently rejects download attempts, blocks certain devices or access methods, and breaks techniques that yt-dlp relies on.

Half the battle is working around attempts by Google to make ads unblockable, and the other half is working around their attempts to shut down downloaders. The idea of a "gray market ecosystem" they tacitly approve ignores how aggressively they tweak their systems to make downloading as unreliable as possible. If Google wanted downloaders to thrive, they wouldn't make developers jump through these hoops. Just look at the yt-dlp issue tracker overflowing with reports of broken functionality. There are no secret nods, handshakes, or other winks, as Google begins to care less and less about compatibility, the doors will close. For example, there is already a secret header used for authenticating that you are using the Google version of Chrome browser [1] [2] that will probably be expanded.

[0] Ask HN: Does anyone else notice YouTube causing 100% CPU usage and stattering? https://news.ycombinator.com/item?id=45301499

[1] Chrome's hidden X-Browser-Validation header reverse engineered https://news.ycombinator.com/item?id=44527739

[2] https://github.com/dsekz/chrome-x-browser-validation-header

replies(14): >>45306431 #>>45307288 #>>45308312 #>>45308891 #>>45309570 #>>45309738 #>>45310615 #>>45310619 #>>45310847 #>>45311126 #>>45311155 #>>45311160 #>>45311645 #>>45313122 #
geokon ◴[] No.45311126[source]
I never understood why do they not limit downloading data to the speed at which you could be possibly watching it. Yesterday I downloaded a 15hour show in like 20 minutes. There is no way I could have downloaded that much data in a legit way through their website/player

Im glad I wasn't blocked or throttled, but it seems like it'd be trivial to block someone like me

Am I missing something? It does sort of feel like they're allowing it

EDIT: Spooky skeletons.. Youtube suddenly as of today forces a "Sign in to confirm you’re not a bot" on both the website and yt-dl .. So maybe I've been fingerprinted and blacklisted somehow

replies(5): >>45311200 #>>45311207 #>>45311213 #>>45311224 #>>45313176 #
axiolite ◴[] No.45311200[source]
You could have been a legit viewer... clicking to skip over segments of the video, presumably trying to find where you left off last time, or for some scene you remember, or the climax of the video... whatever.

Youtube does try to throttle the data speeds, when that first happened, youtube-dl stopped being useful and everyone upgraded their python versions and started using yt-dlp instead.

replies(1): >>45311580 #
brutal_chaos_ ◴[] No.45311580[source]
If you click to skip over, even clicking every minute, you're still not grabbing the whole thing, right? Whereas downloading is grabbing every second.
replies(1): >>45311717 #
1. zenmac ◴[] No.45311717[source]
Depending on the player and how they cache it. Yes, if google monitor every byte to which client had downloaded, but that just seems like ultra micro managing, and have no idea how many players will it break. Youtube seems like one of those site, should allow people to download or make them a public utility on IPFS or something like that.