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

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.

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.

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.

I don't know if Youtube cares, but other website do attempt to block this as well. They will either black your screen or prevent playback if you try to screen record, even encrypting to prevent recording the HDMI/DP output.

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

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

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.

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.

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 level - they capture the audio/video stream from the hdmi cable output for example.

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.

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.

On Linux you can feed the GPU encoded bitstream and then GPU will use hardware to decode and display it as overlay.

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?

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.

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

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.

It's a lost battle in the purist sense, but impure things can go far in real life. DRM is like my lock on the door. I'm sure it's a joke for LockpickLawyer and even a good many more people out there, but, it has successfully defended my household so far.

DRM just raises the bar a bit for access. For example in gaming, it gives the publishers a head start over pirates. If the game is unavailable for pirates during the largest hype, a lot more people buy the product than otherwise.

Also, sometimes DRM wins. For example, right now, Denuvo is undefeated. Some hardware dongle authenticated software are also unavailable in pirated form. Of course one could argue that eventually these would be defeated as well, but, DRM still served its purpose, in defending the product from unauthorized copying in times when it was most desirable.

To me, DRM hasn't made sense when I was looking at it from a Free Software standpoint, but it now makes sense from a product management standpoint.

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