Live data from Hacker News

Yt-dlp: External JavaScript runtime now required for full YouTube support

github.com

61–70 of 646 posts

Re: Yt-dlp: External JavaScript runtime now required for full YouTube support

#61
post #27

More and more recently with youtube, they seem to be more and more confrontational with their users, from outright blocking adblockers, which has no bearing on youtube's service, to automatically scraping creators content for AI training and now anything API related. They're very much aware that there is no real competition and so they're taking full advantage of it. At the expense of the 'users experience' but these…

> At the expense of the 'users experience' but these days, large companies simply don't suffer from a bad customer experience anymore.

This is my personal opinion. They're still affected by customer satisfaction and they're still driven by market forces. It's just that you and I are not their customers. It's not even the YT premium customers. Google is and always has been an ad service company and their primary customers have always been the big advertisers. And they do care about their experience. For example, they go overboard to identity the unique views of each ad.

Meanwhile the rest of us - those of us who don't pay, those who subscribe and even the content creators - are their captive resources whose creativity and attention they sell to the advertisers. Accordingly, they treat us like cattle, with poor quality support that they can't be bothered about. This is visible across their product lineup from YouTube and gmail to workspace. You can expect to be demonetized or locked out of your account and hung out to dry without any recourse if your account gets flagged by mistake or falsely suspected of politics that they don't like. Even in the best case, you can only hope to raise a stink on social media and pray that it catches the attention of someone over there.

Their advantage is that the vast majority of us choose to be their slaves, despite this abuse. Without our work and attention, they wouldn't have anything to offer their customers. To be fair to ourselves, they did pull off the bait and switch tactic on us in the beginning by offering YouTube for free and killing off all their competition in the process. Now it's really hard to match their hosting resources. But this is not sustainable anymore. We need other solutions, not complaints. Even paid ones are fine as long as they don't pull these sort of corporate shenanigans.

Re: Yt-dlp: External JavaScript runtime now required for full YouTube support

#62
post #4

Earlier quoted context omitted.

The YouTube web app is so full of bugs it's almost unusable on a phone. Comments also disappear regularly on all platforms...

And the YouTube web interface is full of issues too. For example, livestreams had transient memory leaks for months already, thought to be related to their chat implementation. In the meanwhile, YouTube spends its effort on measures against yt-dlp, which don't actually stop yt-dlp. What the fuck is wrong with Google corporate as of late.

dumb middle management driven by dumb metrics

a very old story...

Re: Yt-dlp: External JavaScript runtime now required for full YouTube support

#63

Perhaps a stupid question, but is there some reason I can't potentially fall back to recording my screen / audio in realtime and saving videos that way? yt-dlp is obviously far superior to this, but just thinking about what my fallback points are.

You definitely can, it's just 1) vastly slower, and 2) you have to recompress the decompressed video, which loses quality. It's therefore an option of last resort. Most people want to be able to download 5 hours of video in the background in 5 minutes. Not wait 5 hours while their computer is unusable.

I wonder if it has to be a real computer, display, and camera, or if doing it with a "headless display" that is nonetheless being fed to a "video recorder" would work...

Funny how it'd be like The Matrix...

Re: Yt-dlp: External JavaScript runtime now required for full YouTube support

#64
post #27

More and more recently with youtube, they seem to be more and more confrontational with their users, from outright blocking adblockers, which has no bearing on youtube's service, to automatically scraping creators content for AI training and now anything API related. They're very much aware that there is no real competition and so they're taking full advantage of it. At the expense of the 'users experience' but these…

I’m recently also encountering more unskippable ads, especially in kids videos. There were always two ads. Sometimes the first wasn’t shippable and the second always was. That has gradually shifted to neither being skippable.

Re: Yt-dlp: External JavaScript runtime now required for full YouTube support

#65

Perhaps a stupid question, but is there some reason I can't potentially fall back to recording my screen / audio in realtime and saving videos that way? yt-dlp is obviously far superior to this, but just thinking about what my fallback points are.

You definitely can, it's just 1) vastly slower, and 2) you have to recompress the decompressed video, which loses quality. It's therefore an option of last resort. Most people want to be able to download 5 hours of video in the background in 5 minutes. Not wait 5 hours while their computer is unusable.

Understood and agreed. I mostly don't even care about keeping videos from Youtube, but some of the most amazing music performances in the world are trapped on Youtube, and in many cases there is no obvious way to purchase or download them elsewhere.

eg: https://www.youtube.com/watch?v=HAi1pn3kBqE

Re: Yt-dlp: External JavaScript runtime now required for full YouTube support

#66
post #36

I use yt-dlp (and back then youtube-dl) all the time to archive my liked videos. Started back in around 2010, now I have tens of thousands of videos saved. Storage is cheap and a huge percent of them are not available anymore on the site. I also save temporary videos removed after a time for example NHK honbasho sumo highlights which are only available for a month or so then they permanently remove them.

Same here and my motivation was that some of my liked videos were randomly removed and it's pretty cool music I wanted to keep forever. I made another script that adds the video thumbnail as album art and somehow tries to put the proper ID3 tags, it works like 90% of the time which is good enough for me. Then I made another script that syncs it to my phone when I connect it. So now I have unlimited music in my phone…

> And yet, none of Google's 900k TOC genius engineers have thought of this as a feature ...

Isn’t that the YouTube Music app?

Re: Yt-dlp: External JavaScript runtime now required for full YouTube support

#67
post #52

Earlier quoted context omitted.

And it's an entirely useless effort. No idea how it is done but the internet is full 4k rips.

They find devices that are easy to hack (and I mean rip and tear) and extract the decryption keys from each of them, from what I have heard cheap chinese tvs and set top boxes, they extract the keys from the chips (hardware hacking, heard some even use microscopes to read the keys by hand), and then use them to decrypt streams, I heard that they catch them pretty fast to they use like 1 device per season. This is why…

Interesting - do you have any sources to read further?

Re: Yt-dlp: External JavaScript runtime now required for full YouTube support

#68
post #13

Earlier quoted context omitted.

They’d need dedicated hardware to enforce any kind of effective DRM. Encrypted bitstream generated on the fly watchable only on L2 attested device.

Can you explain in simple terms what would prevent one from running the decryption programmatically posing as the end client?

Here are a couple ideas:

The decryption code could verify that it's only providing decrypted content to an attested-legitimate monitor, using DRM over HDMI (HDCP).

You might try to modify the decryption code to disable the part where it reencrypts the data for the monitor, but it might be heavily obfuscated.

Maybe the decryption key is only provided to a TPM that can attest its legitimacy. Then you would need a hardware vulnerability to crack it.

Maybe the server could provide a datastream that's fed directly to the monitor and decrypted there, without any decryption happening on the computer. Then of course the reverse engineering would target the monitor instead of the code on the computer. The monitor would be a less easily accessible reverse engineering target, and it itself could employ obfuscation and a TPM.

Re: Yt-dlp: External JavaScript runtime now required for full YouTube support

#69
post #13

Earlier quoted context omitted.

They’d need dedicated hardware to enforce any kind of effective DRM. Encrypted bitstream generated on the fly watchable only on L2 attested device.

Which is why Windows 11 requires TPM.

TPM isn't the only misfeature that makes Windows 11 an abomination. People who don't switch to a respectful platform is in for a lot of pain.

Re: Yt-dlp: External JavaScript runtime now required for full YouTube support

#70

Earlier quoted context omitted.

You definitely can, it's just 1) vastly slower, and 2) you have to recompress the decompressed video, which loses quality. It's therefore an option of last resort. Most people want to be able to download 5 hours of video in the background in 5 minutes. Not wait 5 hours while their computer is unusable.

I wonder if it has to be a real computer, display, and camera, or if doing it with a "headless display" that is nonetheless being fed to a "video recorder" would work... Funny how it'd be like The Matrix...

It depends on a lot of factors. But even if it works in a virtual machine, your CPU is going to be pegged at 100% the whole time to handle the re-encoding. Unless you use a hardware h.264 encoder, but then the quality is pretty terrible since it's explicitly optimized for speed over quality and isn't tunable the way software encoders are.

It's always doable, it's just an option of last resort. You always just want to access the original compressed bitstream if possible.

Post reply on HN