←back to thread

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

(github.com)
798 points bertman | 1 comments | 12 Nov 25 10:12 UTC | HN request time: 0.001s | source
Show context
embedding-shape ◴[12 Nov 25 14:06 UTC] No.45900337[source]▶
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] [jsc:deno] Solving JS challenges using deno
    [youtube] [jsc:deno] Downloading challenge solver lib script from  https://github.com/yt-dlp/ejs/releases/download/0.3.1/yt.solver.lib.min.js
It would be great if we could download the solver manually with a separate command, before running the download command, as I'm probably not alone in running yt-dlp in a restricted environment, and being able to package it up together with the solver before runtime would let me avoid lessening the restrictions for that environment. Not a huge issue though, happy in general the start of downloads seems much faster now.
replies(8): >>45900780 #>>45901047 #>>45901146 #>>45901292 #>>45902245 #>>45902494 #>>45903312 #>>45906436 #
WD-42 ◴[12 Nov 25 14:59 UTC] No.45901047[source]▶
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!

replies(6): >>45901546 #>>45901717 #>>45901739 #>>45902053 #>>45902158 #>>45903145 #
gilfoy ◴[12 Nov 25 15:42 UTC] No.45901546[source]▶
I use YouTube daily in safari and edge, this is complete hyperbole.
replies(4): >>45901585 #>>45901960 #>>45901961 #>>45902316 #
embedding-shape ◴[12 Nov 25 16:42 UTC] No.45902316[source]▶
That's a bit like complaining no cars have trouble because your Fiat doesn't have a problem. There are more browser engines out there than the ones you use, some in direct competition with Google themselves, maybe people using those engines are experiencing issues? Jumping to calling out "hyperbole!" sounds like hyperbole itself, since you don't actually have broad experience enough to say if that's true or not.

FWIW, when I use Chromium (logged out/in) on Linux, everything works fine. If I use Firefox (logged in), it works worse. If I change the user-agent to Chromium in Firefox, I get faster buffering than when I use the default user-agent. Make of that what you will.

replies(1): >>45903477 #
darkwater ◴[12 Nov 25 18:05 UTC] No.45903477{3}[source]▶
> That's a bit like complaining no cars have trouble because your Fiat doesn't have a problem.

No. Because even if it might be complicated, any website developer can test their website against a wide array of browsers, in a more or less automated way.

replies(2): >>45903573 #>>45906462 #
1. Too ◴[12 Nov 25 20:50 UTC] No.45906462{4}[source]▶
When it comes to video it’s not only the browser. It’s also your gpu, your OS and your gpu drivers.

Notably, YouTube these days prioritize AV1 codec even if you don’t have gpu acceleration for it, making lots of systems fall back to CPU decoding and making it completely unusable. Install the h264ify extension to force h264 during content negotiation and get your gpu decoding back.

Even if you can make a matrix of all those combinations, it’s even more complex than that to test in practice. Take my laptop for example, it starts off good and manages the cpu decoding for a while, a few minutes into a video it overheats and throttles, causing stutter.

What YouTube should do on the other hand, and I’m sure they already do, is to collect metrics from all playbacks. That should show black on white how many users struggle with each codec.

I don’t think I’m in any minority here given how many million installations the h264ify extension has. Google simply care more about their bandwidth cost than the user experience.