←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: 1.143s | 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. matsemann ◴[12 Nov 25 13:35 UTC] No.45899953[source]▶
With browser's and hardware's support for DRM they could make it impossible if they want to. Basically the OS / recording software sees a blank screen.

I was on live TV recently and wanted to keep a recording for myself, that wasn't just filming the screen with my phone. I first tried screen recording watching the show in my browser in their streaming service. Got a black video. Then I tried their phone app, got a black video. Finally, using my phone but the web page they enabled playback without DRM and I could record and store it. When more devices support DRM they will probably get rid of that fallback as well.

replies(2): >>45900444 #>>45901449 #
2. ethmarks ◴[12 Nov 25 14:13 UTC] No.45900444[source]▶
I imagine there would be ways around this. I know from personal experience that Kazam screen recorder on Firefox on Ubuntu can record anything and everything, including YouTube as well as DRM content on Disney+ and Prime Video.

I bet that it Google really wanted to it could force Firefox in line, but I imagine that actually preventing screen recording would require compliance at the OS level too, and I don't think that even Google could demand changes like that to Linux. Best they could do is block Linux clients from YouTube, but user agent spoofing or emulation could probably circumvent that.

And even if Google does somehow manage to entirely block screen recording, we can always exploit the analog loophole.

replies(1): >>45900809 #
3. anal_reactor ◴[12 Nov 25 14:41 UTC] No.45900809[source]▶
On Linux you can feed the GPU encoded bitstream and then GPU will use hardware to decode and display it as overlay.
replies(1): >>45900944 #
4. ethmarks ◴[12 Nov 25 14:51 UTC] No.45900944{3}[source]▶
Why is this relevant? To be clear, I'm asking from a place of ignorance. Are you saying that because the video player can have the video decoding happen entirely on the GPU, screen recording software can't pick it up? Couldn't the software just read from the GPU buffer?
replies(1): >>45902765 #
5. Maskawanian ◴[12 Nov 25 15:35 UTC] No.45901449[source]▶
There is always the analog hole. Even HDCP can be worked around. Even if they do manage to stop all computers from doing direct bit copies, there are still old things such as Kinescopes which they used to use to broadcast television from film. There of course is a quality loss, but that's kind of irrelevant to the point.
6. anal_reactor ◴[12 Nov 25 17:15 UTC] No.45902765{4}[source]▶
> Couldn't the software just read from the GPU buffer?

The GPU would simply return all zeros for area where DRM-protected video is being played. Duh.