Live data from Hacker News

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

github.com

261–270 of 646 posts

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

#261
post #246

Earlier quoted context omitted.

"Fitting into my pocket so I can use it in line at the post office" is a capability that desktop PCs have yet to manage to achieve.

> use it in line at the post office If it were a powerful, useful device that I could load my own software onto and make programmable without jumping through a bunch of hoops, instead of the ad-laden crapware that resulted from primarily two megacorps duking it out over how to best extort billions from app developers and users for their own benefit, then sure, I'd agree. But phones aren't awesome little PCs, they're…

> ut phones aren't awesome little PCs, they're zombifying the majority of the public. They also, incidentally, are insidious little snitches busy at work trying to monetize every single thing about our daily lives.

Yes, and corporations are doing all the same stuff to our PCs as well.

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

#262
post #238

Earlier quoted context omitted.

> 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. The video experience for typical video files is great these days compared to the past. I think you may be viewing the past through rose colored glasses. For years it was a pain to deal with video because you had to navigate third party players (remember Real Player?…

Real player was one of the first real video players, it wasn't a pain, it was a genuine addon. Flash, also almost came built into every browser. By the time both had gone away, HTML video built in was here. Of course, there were players like jwPlayer what played video fine. Today, most browsers have most codecs.

Real Player was an early innovator. Mostly in dark patterns.

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

#263

Earlier quoted context omitted.

1991 was the vibrant, exciting, crazy "adolescence" of the PC age and well into the period where it was cool to have a desktop PC and really learn about it. Phones are dominant now and have passed the PC generation by - in number, not capability. The concept of copy/paste/save for arbitrary data lives on for the non-tech masses only in the form of screenshots and screen recording features.

"Fitting into my pocket so I can use it in line at the post office" is a capability that desktop PCs have yet to manage to achieve.

Well… https://www.zotac.com/page/zotac-vr-go-4

There are also various handheld PCs.

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

#264
post #12

I wonder why YouTube doesn't implement full DRM, such as Widevine, at this point. Is it because it would break compatibility with some devices? Is it too expensive? (not that I'd like that; I always download videos from YouTube for my personal archive, and I only use 3rd party or modified clients)

I think because it cost money and they get little benefit on doing so.

Major platform like Netflix etc. don't implement that DRM since they care, it's because they content they distribute requires that they employ that measures, otherwise who produces the content doesn't give it to them. Content on YouTube does not have this requirement.

Also: implementing a strict DRM on all videos is probably bad for their reputation. That would restrict the devices that are able to play YouTube, and probably move a lot of content creators on other platforms that does not implement these requirements.

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

#265

Earlier quoted context omitted.

I'm absolutely not viewing the past through rose colored glasses. RealPlayer was a dumpster fire, but that came later. I could hold shift and drag on the timeline to select, copy, then paste it into a document or another video. I can't do that with VLC today. Apple removed the feature in later releases too.

What you’re describing with QuickTime was a proprietary nightmare that didn’t even work correctly across Apple products, let alone Microsoft or Linux. Today with modern tools like VLC or MPV and ffmpeg nearly anything can be viewed, streamed, or locally saved by your average user with basic Google search skills. And the number of free and paid video editing tools as far beyond what we ever had in the past. Then there…

One issue GP may be referring to is the bifurcation of video viewing tools and video editing tools. There are excellent video editing tools: on the desktop from paid ones like Premiere to free (as in beer) ones like DaVinci Resolve, not to mention mobile apps behind the TikTok culture. There are also excellent and built-in video players in every browser and every OS.

But in the modern age viewing and editing a video are seen as two entirely separate tasks. You simply do not expect the video player that comes with the OS to cut, copy, and paste videos, even though cut, copy, and paste are basic OS-level features. This is very much different from the experience of almost all other kinds of files. You use Microsoft word to view and edit your word processing documents. Or if you aren’t fancy you use notepad to view and edit your plain text documents. These text documents easily allow cut, copy, and paste.

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

#266
post #237

Earlier quoted context omitted.

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

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

No idea what you are talking about. I don’t have premium and use in both logged in and logged out.

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

#267

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…

Plain elements are easy to download, but not great for streaming, which is what most people are doing nowadays. Much of the JS complexity that gets layered on top is to facilitate adaptive bitrate selection and efficient seeking, and the former is especially important for users on crappier internet connections. I'm not a fan of how much JS is required to make all that work though, especially given the vast majority o…

Chrome has finally just landed enabled by default native HLS playback support within the past month. See http://crrev.com/c/7047405

I'm not sure what the rollout status actually is at the moment.

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

#269

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.

In the current times yes, you can basically record your screen with whatever tool you fancy. But even now, many video sites employ DRM, and only the weakest levels of DRM streams can be recorded off the screen. If they crank that up, which is perfectly possible today, the screen recordings only shows a blank rectangle, because the encryption goes from server to video card. At this stage, "hdmi recorders" are the next…

> Even further, there is technology to encrypt from server to screen. I'm not sure on the rollout on this one. I think we have a long time until this is implemented, and even then, I'm sure we will have the ability to buy screens that fake the encryption, and then let us record the signal. And, for mainstream media, there will be pirated copies until the end of time I think.

In the end, nobody will ever avoid people from having a camera pointed to a screen. At least till they can implant a description device in our brain, the stuff coming out of the screen can be recorded. Like in the past when people used to record movies at the cinema with cameras and upload them on emule. Sure, it would not be super high quality, but considering that is free compared to something you pay, who cares?

To me DRM is just a lost battle: while you can make it inconvenient to copy a media, people will always try to find a way. We used to pirate in the VHS era and that was not convenient, since you would have needed 2 VCR (quite expensive back then!) and it took the time of the whole movie to be copied.

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

#270

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…

Plain elements are easy to download, but not great for streaming, which is what most people are doing nowadays. Much of the JS complexity that gets layered on top is to facilitate adaptive bitrate selection and efficient seeking, and the former is especially important for users on crappier internet connections. I'm not a fan of how much JS is required to make all that work though, especially given the vast majority o…

I totally agree. And much of the JS complexity on smaller niche video sites aren’t even implemented properly. On some sites I just open developer console, find the m3u8 file URL and cookies in the request, and download it to view locally.

Browsers generally do allow native seeking if the video is properly encoded and the site supports such niceties as Accept-Range: bytes.

Post reply on HN