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

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

github.com

Post reply on HN
Print view View original

521–530 of 646 posts

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

#521

Post by extraduder_ire »

s3graham wrote: post #513
Figs wrote: post #274

I do not understand why Google doesn't just explicitly permit people who pay for premium to use yt-dlp or other tools to watch YouTube however the fuck they want . Put that in your terms, Google -- so people aren't afraid they'll lose their GMail because they wanted to watch a video -- and you'll get more paying customers...

Seriously, there's even that "Download" button but it goes to some weird janky browser-local storage instead of just giving me a damn file. (I don't think they'd realistically get more paying customers, but I would appreciate it anyway.)

Youtube used to have working download buttons on any video that the uploader licenced as creative commons.

The version of their app that used their V2 API also allowed downloading any video (local to the app, not easily copied) or even setting it to auto-download all of your subscription feed as videos came out.

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

#522

Post by jasomill »

amelius wrote: post #300
dev0p wrote: post #289

Earlier quoted context omitted.

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).

1000/40 is rather asymmetric and the fastest service available in my area.

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

#523

Post by tshaddox »

devsda wrote: post #239
oblio wrote: post #33

Earlier quoted context omitted.

I guess at that point we could do it the old fashioned way by pointing a camera at the screen. Or, I guess, a more professional approach based on external recording.

I might be recalling it wrong,but I remember reading that there was some old hardware that refused to record protected TV/Movies probably a VCR or a DVR. Camera manufacturers can easily refuse to record a stream of they detect it is protected, may be via watermarks or other sidechannel.

HDCP is how modern digital displays (and digital display recorders) do it.

You might be thinking of Macrovision, which was integrated in a lot of DVD players and would embed pulses into the vertical blanking interval of the analogy video output. These pulses could be detected by compliant DVD recorders and used to refuse recording. The pulses would also cause playback defects in some older VCRs and TVs.

I remember connecting my first DVD player to an old TV via a VCR (effectively using the VCR as an RF modulator) and being plagued with the image brightness constantly lowering and rising. At the time, I fixed this by switching to a dedicated RF modulator. I now suspect Macrovision is what caused this.

https://en.wikipedia.org/wiki/Analog_Protection_System

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

#524

Post by fragmede »

titzer wrote: post #472
fragmede wrote: post #441

Earlier quoted context omitted.

If you think having a developer mode switch on your smartphone that would enable shell access and a build env is what's stopping "the majority of the public" from "zombifying", either you need to talk with more "majority of the public", or I've been talking to the wrong "majority of the public". The general public doesn't know how to program. They don't know what variables are, that they have types, they think functi…

There's definitely a mismatch between expectations between what you inferred I meant and what I really mean. We agree that the majority of people are not going to suddenly stop being zombies if the platform were more open for development. It's a complex societal issue that's driven by the media atmosphere and the attention economy and affects all platforms. But smartphones are the platform that seems to be the most e…

It's not a question of being technical enough. It's actually a question of being too technical. You're here, which for me garners youa base level of respect if only because I've had the creators of certain subjects of discussion have responded directly to me grousing here.

Because you're technical, the iOS restriction that code must be signed seems insurmountable, because it is. But if you know less about computers, you'd find bitrig or swift playgrounds or Pythonista. And knowing even less, you get into building web apps. For what people want to do and create; they don't know frontend from backend and are just getting their feet wet, a phone does alright.

Could it better at it? Absolutely, no question about that! But so could everything else in life. It depends on where on the spectrum you exist, A laptop is better than a phone for writing code for a lot of reasons, but when we're looking at the bigger picture, a phone is better than nothing.

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

#525

Post by 1vuio0pswjnm7 »

1vuio0pswjnm7 wrote: post #431

"Support for YouTube without a JavaScript runtime is now considered "deprecated." It does still work somewhat; however, format availability will be limited, and severely so in some cases (e.g. for logged-in users). " The devil is in the details There are some formats, perhaps the one(s) the user wants, that do not require a JS runtime Interesting that "signing up" for a website publishing public infomation and "loggi…

s/infomation//information/

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

#526

Post by seg_lol »

kragen wrote: post #301
doublerabbit wrote: post #155

Earlier quoted context omitted.

Some of the old YTPs were fantastic. They don't exist now. Generations of talent & creativity just gone.

What's a "YTP"?

I recommend starting with Mom https://www.youtube.com/watch?v=z7opxguZWns

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

#527

Post by bpye »

gruez wrote: post #172
vachina wrote: 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.

>They’d need dedicated hardware to enforce any kind of effective DRM. That's already here. Even random aliexpress tablets support widevine L1 (ie. highest security level)

How often are their keys extracted?

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

#528

Post by anabis »

This is where I would guess the world destroing AGI/ASI will come about. The neverending cat-and-mouse game of ads/blockers driven by profit motive. LLMs will used by both sides in a escalating game, with humans with its attention and wallet stuck in the middle.

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

#529

Post by charcircuit »

jcalvinowens wrote: post #383
charcircuit wrote: post #366

Earlier quoted context omitted.

It provides a good incentive for manufacturers to invest into security for their devices.

No, it provides no incentive at all! It's the users who suffer when this happens, not the manufacturers. The manufacturers couldn't care less, the money is already in the bank. If the manufacturers were required to replace all the revoked devices at their cost, that would be a real incentive.

Manufactures suffer reputational damage from it. Also keys could be revoked before they finish selling through all of their stock of produced phones.

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

#530

Post by Wowfunhappy »

rdtsc wrote: post #361
Wowfunhappy wrote: post #205

> if using QuickJS, version 2025-4-26 or later is strongly recommended for performance reasons Oh, I wonder if they got performance to a reasonable level then? When the external JS requirements were first announced, they said it took upwards of half an hour, and a QuickJS developer wrote in the ticket that they didn’t see a path towards improving it significantly enough.

It wasn't a QuickJS developer but developer from a fork: https://github.com/bellard/quickjs/issues/445

Oh, so with QuickJS it only takes a few seconds at worst. That's great news for portability!
Post reply on HN