Live data from Hacker News

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

github.com

291–300 of 646 posts

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

#291
post #186

Seems its already in Arch's repositories, and seems to work, just add another flag to the invocation: yt-dlp --cookies-from-browser firefox --remote-components ejs:github -f "bestvideo[ext=mp4]+bestaudio[ext=m4a]/best[ext=mp4]/best" 'https://www.youtube.com/watch?v=XXX' It is downloading a solver at runtime, took maybe half a second in total, downloads are starting way faster than before it seems to me. [youtube] [js…

Glad to hear it’s faster now! YouTube barely works in a full-on browser these days, props to the team that keeps it accessible via a Python script!

> YouTube barely works in a full-on browser these days

Agreed. Shorts about half the time don't display comments, the back button breaks in mysterious ways. And I use Chrome on both Intel and M macOS machines, so the best in class there is, but my Windows Chrome doesn't fare much better. And Adblock ain't at fault, I pay for premium.

And that's just the technical side. The content side is even worse, comments sections are overrun by bots, not to mention the countless AI slop and content thieves, and for fucks sake I get that high class youtubers have a lot of effort to do to make videos, but why youtube doesn't step in and put clear regulations on sponsorship blocks is beyond me. Betterhelp, AG1, airup, NordVPN (and VPNs in general) should be outright banned.

And the ads, for those who aren't paying for premium, are also just fucked up. Fake game ads (Kingshot who stole sound effects from the original indie Thronefall ...) galore.

Google makes money here, they could go and actually hire a few people to vet ads and police the large youtubers with their sponsors.

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

#292
post #34

Earlier quoted context omitted.

This is obviously not plausible. They're never going to shut off browser access on people's laptops. Watching YT at work is a major thing. I have to assume you're joking, but I honestly can't figure out what point you're even trying to make. Do it think it's surprising that an ad-supported site has anti-scraping/anti-downloading mechanisms? YouTube isn't a charity, it's not Wikipedia.

>Watching YT at work is a major thing. Where are these jobs where I can get paid to watch YouTube?

Working in infrastructure design (specifically railways), cab ride videos are often useful to fill in gaps in as-built plans or the pictures you took on a site visit (you'll always miss out to photograph something that'll be of major interest later), especially in early planning phases. Plus there's the odd software tutorial video here and there, too, of course.

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

#293

Earlier quoted context omitted.

Youtube is pretty unusable, as they throttle videos, and links sometimes dont work. It has gone downhill fast in recent years.

I have no problems with YouTube at all. Perhaps it's because I pay for Premium (primarily to get YouTube music). Regardless, Google services getting worse over time is becoming a law rather than a tendency.

I don't get the value ad of youtube music. Everything's already on youtube and they let you make playlists, and they have playlists of the top charts already.

What else does youtube music get you? I can play on my phone with the screen off with yt vanced ( and I would never pay just for that feature, because I remember when it was free and they took it away )

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

#294

Seems its already in Arch's repositories, and seems to work, just add another flag to the invocation: yt-dlp --cookies-from-browser firefox --remote-components ejs:github -f "bestvideo[ext=mp4]+bestaudio[ext=m4a]/best[ext=mp4]/best" 'https://www.youtube.com/watch?v=XXX' It is downloading a solver at runtime, took maybe half a second in total, downloads are starting way faster than before it seems to me. [youtube] [js…

What environment are you using that: - Has access to Youtube - Can run Python code - Can’t run JS code If the concern is security, it sounds like the team went to great lengths to ensure the JS was sandboxed (as long as you’re using Deno). If you’re using some sort of weird OS or architecture that Deno/Node doesn’t support, you might consider QuickJS, which is written in pure C and should work on anything. (Although…

> What environment are you using that: - Has access to Youtube - Can run Python code - Can’t run JS code

Nothing specific, just tend to run tools in restricted VMs where things are whitelisted and it's pretty much as locked down as it can be. It can run whatever I want it to run, including JS, and as the logs in my previous comment shows, it is in fact running both Python and JS, and has access to YouTube, otherwise it wouldn't have worked :)

I tend to have the rule of "least possible privileges" so most stuff I run like that has to be "prepped" basically, especially things that does network requests sometimes (updating the solver in this case), just a matter of packaging it before I run it, so it's not the end of the world.

No weird OS or architecture here, just good ol' Linux.

> IMO it seems like it should safe to trust code being served by Google on the official Youtube domain

The JS script being downloaded is from the yt-dlp GitHub organization (https://github.com/yt-dlp/ejs/releases/download/0.3.1/yt.sol...), not from Google or any websites, FWIW.

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

#295
post #186

Earlier quoted context omitted.

Glad to hear it’s faster now! YouTube barely works in a full-on browser these days, props to the team that keeps it accessible via a Python script!

I use YouTube in a browser (Brave) almost everyday. Works great for me.

you don't get the "are you still watching" popups? sometimes it buffers hard for me. They also removed dislikes and constantly push shitty clickbai AI thumbnails. They're also adding shitty ai translation, so if you like learning languages you're SOL. They also changed thier rec algo to be more "right wing\tech bro" leaning

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

#296
post #237

Earlier quoted context omitted.

I use YouTube daily in safari and edge, this is complete hyperbole.

As a counter-anecdote, I use YouTube daily in Safari and it will not infrequently hang for tens of seconds when trying to load a video, occasionally play the sound without the video, reasonably frequently put the video over most of the page with no way to get to the controls, etc. (This may be because I have a whole swathe of adblockers, etc., plus I do a lot of `yt-dlp`ing from the same IP which may have me on a nau…

I have the same issue. I think it's because I'm adblocking because if I try in chrome with no adblocker it loads the ads instantly.

But eh either 5s of black screen or 60s of ads. I tried watching a 15 min yt video without adblock and it had 5 ad breaks with some unskippable ads.

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

#297

Earlier quoted context omitted.

> It's absolutely insane to me how bad the user experience is with video nowadays Has nothing to do with video per se. Normal embeddings, using the standard ` ` element and no unnecessary JS nonsense, still work the same way they did in the 90s: Right click the video and download it, it's a media element like any other. The reason why user experience is going to shite, is because turbocapitalism went to work on what…

The problem with a standard video element is that while it's mostly nice for the user, it tends to be pretty bad for the server operator. There's a ton of problems with browser video, beginning pretty much entirely with "what's the codec you're using". It sounds easy, but the unfortunate reality is that there's a billion different video codecs (and a heavy use of Hyrum's law/spec abuse on the codecs) and a browser on…

Chrome desktop has just landed enabled by default native HLS support for the video element within the last month. (There may be a few issues still to be worked out, and I don't know what the rollout status is, but certainly by year end it will just work). Presumably most downstream chromium derivatives will pick this support up soon.

My understanding is that Chrome for Android has supported it for some time by way of delegating to android's native media support which included HLS.

Desktop and mobile Safari has had it enabled for a long time, and thus so has Chrome for iOS.

So this should eventually help things.

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

#298

Seems its already in Arch's repositories, and seems to work, just add another flag to the invocation: yt-dlp --cookies-from-browser firefox --remote-components ejs:github -f "bestvideo[ext=mp4]+bestaudio[ext=m4a]/best[ext=mp4]/best" 'https://www.youtube.com/watch?v=XXX' It is downloading a solver at runtime, took maybe half a second in total, downloads are starting way faster than before it seems to me. [youtube] [js…

yt-dlp --cookies-from-browser firefox --remote-components ejs:github -f "bestvideo[ext=mp4]+bestaudio[ext=m4a]/best[ext=mp4]/best" 'https://www.youtube.com/watch?v=XXX'

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

#299

Earlier quoted context omitted.

What environment are you using that: - Has access to Youtube - Can run Python code - Can’t run JS code If the concern is security, it sounds like the team went to great lengths to ensure the JS was sandboxed (as long as you’re using Deno). If you’re using some sort of weird OS or architecture that Deno/Node doesn’t support, you might consider QuickJS, which is written in pure C and should work on anything. (Although…

> What environment are you using that: - Has access to Youtube - Can run Python code - Can’t run JS code They didn't say “can't run JS code”, but that from that location the solver could not be downloaded currently. It could be that it is an IPv6-only environment (IIRC youtube supports IPv6 but github does not), or just that all external sites must be assessed before whitelisted (I'm not sure why youtube would be but…

It's just me being paranoid after seeing npm/pypi supply chain attacks, and since then I basically run most software touching the internet in a VM one way or another.

I think in this case, my own laziness is what makes it worse than it has to, currently I'm doing whitelisting by domains, so youtube.com for the yt-dlp runner is obviously OK, and I'd want to avoid whitelisting github.com for that, since it's just downloading one JS file.

For now manually copying the config file into my SCM or just whitelisting GitHub for initial download does the trick. I guess I just had to squeeze in one complaint in my previous comment so I could get the HN stamp of approval, can't be too positive.

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

#300
post #289

I remember when QuickTime came out in 1991 and it was obvious to everyone that video should be copied, pasted and saved like any arbitrary data. It's absolutely insane to me how bad the user experience is with video nowadays, even video that's not encumbered by DRM or complex JavaScript clients.

YouTube should have been a distributed p2p system with local storage of your favorite videos. A man can dream...

Didn't work because asymmetric upload/download speeds (which now are a thing of the past; however, it gave youtube an early advantage).
Post reply on HN