Hacker News Reader

Comment by clishem | Hacker News Reader

I don't get it. I can still make a recording of my screen can't I?

The purpose of DRM is not to stop piracy, but to have legal and technical leverage over player makers:

https://plus.google.com/+IanHickson/posts/iPmatxBYuj2

It's more difficult. For example on Safari you can't take full-res screenshots. https://www.quora.com/How-can-I-screenshot-Netflix-without-g... But I think the point is that you don't know what code or data is being run on your computer. You can only see the end result.

There are quite many ways "pirates" capture a video. Recording the screen is probably the last resort and makes you end up with a very low quality copy.

But yes, until they also build in the technology they have in PlayStations (Cinavia) to video cameras, that is the most obvious leak.

I would think you could hook into X11 to do this quite nicely.

Problem is that grabbing the last frame buffer would mean you're doing it post decompression. To distribute something you grabbed like that you'd need to recompress it and then have a generation degradation of lossy compression.

That's not how that works.

It's one thing if you're converting from one compressed format to another, or recompressing an already compressed file.

It's another to simply grab the pixels off of screen and compress those. You won't get as good of a shot because of the original decompression, but your description of why is inaccurate.

algesten's comment seems entirely accurate to me. He's not claiming that the captured frame buffer will be of lower quality, but that in order to distribute it afterwords, you would need to recompress the captured frames. That recompression is where the quality reduction would occur.

Everything I just said is rephrasing what is already in algesten's comment.

Because it has nothing to do with the original compression.

Think of it like this.

If you compress and distribute someone's wavy hand-cam pirating of a movie, the poor experience isn't due to the compression, but the way the move was recorded in the first place.

likewise, recording a stream and then compressing it later, the quality isn't because of the original compression, it's because of the quality of the original stream.

Now that poor quality may partially be the result of the initial compression, but recompressing it isn't why the quality isn't great.

Recompression matters because most video compression is lossy. Every compress/decompress cycle introduces noise and artifacts.

right, which means by definition any compression is going to lose quality, even if done directly off the original, lossless versions.

that's the point, it's the quality of the input that matters, not the fact that it's been compressed previously.

Netflix sends you a video that has been lossy compressed once. If you lossy compress that lossy compressed video, then you will have a video of worse quality than the video that was only lossy compressed once.

Original source video > Netflix video stream (1 level of lossy encoding) > Recompressed video stream (2 levels of lossy encoding)

I think you'll find if you record and compress a netflix 4k video, the resulting quality will be just fine, especially if you're recording it and compressing it later (rather than doing it realtime).

That's because, while it may have been compressed going over the wire, it's 4k and the quality is pretty stinkin' good.

what you don't do is try to simply recompress the signal that netflix is sending you, you uncompress and then compress.

At which point you're not "recompressing", what you're doing is compressing a stream that may not be as high quality as the original, uncompressed form, but it's a truckload better than sneaking into the theater and recording that way.

Nobody has said that the quality would be bad, just that some amount of generation loss [1] will occur when you use a lossily compressed [2] video (the netflix stream) as input for the creation of another lossily compressed video (the "recompressed" video file). The "recompressed" video would be slightly worse than the streamed video, which would be slightly worse than the original video.

An approximation of an approximation of a video is going to be worse than an approximation of a video.

1: https://en.wikipedia.org/wiki/Generation_loss

2: https://en.wikipedia.org/wiki/Lossy_compression

right, but what algesten originally said was (emphasis mine):

> _Problem is_ that grabbing the last frame buffer would mean you're doing it post decompression. To distribute something you grabbed like that you'd need to recompress it and then have a generation degradation of lossy compression.

In the context of getting a decent pirated copy, that's not really a problem due to how good those streams are.

That was my point, anyway.

You can in the sense of pointing a video camera at the screen and recording it.

But if you want to capture the pixels before they are converted into light, HDCP may prevent you from doing so [1].

[1]. https://en.wikipedia.org/wiki/HDCP

Nope, there's a company in Shenzhen that makes a plug-and-play bypass device: https://arstechnica.com/tech-policy/2016/01/warner-bros-sues...

I used the hdfury years ago. the output quality wasn't anywhere near the quality of the input signal. but it did technically give you a signal without hdcp.

Different generations, and presumably you were going DAC, to VGA, rather than staying digital.

And you could always in the last resort hook up to the DLP projector screen copy the outputted data just before light.

Very messy but it should work.

HDCP stripping has been a thing for a while now: https://www.tweaking4all.com/home-theatre/remove-hdcp-hdmi-s...

The HDFury devices work great: https://www.hdfury.com/tag/hdcp-stripper/

Reply on news.ycombinator.com