←back to thread

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

(github.com)
810 points bertman | 6 comments | 12 Nov 25 10:12 UTC | HN request time: 0.001s | source | bottom
Show context
everdrive ◴[12 Nov 25 13:31 UTC] No.45899905[source]▶
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.
replies(4): >>45899931 #>>45899953 #>>45899983 #>>45900704 #
1. crazygringo ◴[12 Nov 25 13:34 UTC] No.45899931[source]▶
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.

replies(2): >>45900031 #>>45900049 #
2. netsharc ◴[12 Nov 25 13:40 UTC] No.45900031[source]▶
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...

replies(2): >>45900097 #>>45900766 #
3. everdrive ◴[12 Nov 25 13:41 UTC] No.45900049[source]▶
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

4. crazygringo ◴[12 Nov 25 13:45 UTC] No.45900097[source]▶
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.

replies(1): >>45902569 #
5. npteljes ◴[12 Nov 25 14:38 UTC] No.45900766[source]▶
I have written software to do this kind of recording on a laptop, running 4 of the stream itself (different episodes of the same show).

It opened DRM enabled browsers side by side, ffmpeg captured the video from the respective parts of the screen, and each browser's audio was piped into a different dummy output, which ffmpeg also captured of course.

The tech stack was linux, bash, PHP, php-webdriver, Selenium, Firefox, ffmpeg. So yes, this idea absolutely works! That is, until they crank up the DRM so that software screen capture doesn't work.

6. tracker1 ◴[12 Nov 25 17:00 UTC] No.45902569{3}[source]▶
I think the real key is to only compress enough initially so that you don't blow out your storage in terms of size and throughput... Once you have the stream captured at a higher quality, you can always recompress more optimally.

A relatively low compression with hardware h.264 will still take up a lot less space and throughput than mpeg-2 or raw.