That's actually an important distinction. You can recapture the DRM protected (and then decoded) video pretty much always indeed, but then you degrade the quality by having to encode it again.

Well, not important to some, but for enthusiasts and people looking to actually archive things, it is very important.

Case in point, hilariously, the last time I used YouTube's video download feature bundled with their Premium offering, I got a way worse quality output than with yt-dlp, which actually ripped the original stream without reencoding it.

I think I saw an idempotent h264 encoder at some point, where you wouldn't suffer generational loss if you matched the encoder settings exactly from run to run. But then you might need the people mastering the content (in this case YouTube) to adopt that same encoder, which they're not going to be "interested" in.

▲

kuschku 5 days ago | parent [-]

Even with DRM video you can fetch it losslessly. At some point, some part of your system requires access to the raw, decrypted video stream.

As long as that's the case, you can get bit-perfect netflix rips.

▲

Marsymars 5 days ago | parent [-]

The problem is that if you have the raw data, you’ve lost the original compression information, so you can’t get it back to a sensible size without double compressing. e.g. Think about what you get when you save a jpeg as a bitmap.

▲

kuschku 5 days ago | parent [-]

You can get the original compressed h264/h265/etc stream back out, that's the entire point.

Even DRM media is using regular accelerated video decode.

▲

perching_aix 5 days ago | parent [-]

The "entire point" of contemporary lossy-media DRM [0] is to prevent you from doing that. You can only do so if the DRM scheme is circumvented or unsound [1].

That is not what we're talking about - the working assumption here is that the DRM scheme is sound and effective. In which case your only possible but also guaranteed stage of recapture is at the analog hole, by which point the media encoding is already undone, incurring a generational loss.

[0] I consider presently existing and historical DRM implementations deeply flawed and misguided; they severely overstep their boundaries implied by the name "DRM", in certain cases quite disgustingly - hence the many added adjectives for clarification

[1] puzzlingly, any access control will actually get you in the same legal situation, regardless of whether the access control mechanism is effective or sound, so this is actually a design decision; but it's pretty universally taken afaik.

▲

kuschku 5 days ago | parent [-]

> That is not what we're talking about - the working assumption here is that the DRM scheme is sound and effective.

Lol. That is not possible.

If I'm able to watch something, my device must be able to decrypt the DRM. If my device can decrypt the DRM, I can take my device apart and figure out how it does this, and do it myself.

The most DRM encumbered format is DCP, used my cinemas. Each projector has a unique key burnt into it, the decryption, decoding and watermarking happen on the same piece of silicon, and the entire device is built like an HSM, opening it wipes the keys.

There are bit-perfect DCP rips on the high seas, with the original compressed data.

HDCP is meant to prevent me from copying HDMI signals. Every conference center and lecture hall has cheap Chinese devices that remove it.

Regarding the analog hole, with a properly calibrated professional video camera recording in RAW, with both camera and monitor genlocked and color calibrated, and the proper postprocessing, you can capure the original pixel values exactly.

I've done that part more often than I'd like...

And worst case, you can then brute force which parameters the original encode used to re-encode your data without generation loss.

▲

perching_aix 4 days ago | parent [-]

> Lol. That is not possible.

It is possible, both under the conservative interpretation of the word (like how AACS is continuously updated as security holes are found and compromises happen, with the keys being rotated each time), and on a theoretical level (FHE). The latter is not being done because it is not nearly performant enough, and the former is an ongoing cat and mouse game that is once again irrelevant to what we were discussing here.

With FHE, the "take the machine apart and analyze what it does to get the original bitstream" would be cryptographically hard, so good luck with that. With the usual DRM schemes it isn't, so they are pretty much always cracked in a few months or a few years, but until that point they are both sound and effective.

> Regarding the analog hole, with a properly calibrated professional video camera recording in RAW, with both camera and monitor genlocked and color calibrated, and the proper postprocessing, you can capure the original pixel values exactly.

Yes, that's what I'm suggesting too...

> And worst case, you can then brute force which parameters the original encode used to re-encode your data without generation loss.

Can you? I mean in practice, in a practical amount of time. And is that actually done?

	▲	kuschku 4 days ago \| parent [-]
		> like how AACS is continuously updated as security holes are found and compromises happen, with the keys being rotated each time And yet with consumer hardware you can accurately rip every UHD Bluray right on release day, without any trouble. > Can you? I mean in practice, in a practical amount of time. And is that actually done? Most of the time effort of encoding is already spent on brute forcing these parameters to most effectively match the original input. You just need to change the way the encoder scores each possible result. > With FHE, the "take the machine apart and analyze what it does to get the original bitstream" would be cryptographically hard, so good luck with that. So what? You could just distribute the encrypted datastream and the key you've extracted from a device, say a smartphone you bought from an electronics recycler. Also, I don't see how FHE with video would be possible in the next decades, considering the limitations to Moore's Law in recent years. Video codecs are extremely complicated, requiring lots of memory and processing power. Ten years ago, even the best gaming PCs couldn't handle software decoding. Even today many mid-range systems can't handle software video decoding. Even hardware implementations regularly require more power and memory than the entire rest of the system. There's a reason Raspberry Pi's are primarily a video decoding chip with a CPU as coprocessor, which is why the GPU runs the bootloader. Video is constantly at the limitations of what we can physically accomplish. Your suggestion would require spending a massive chunk of silicon area of a SoC on a FHE decoding ASIC that would only be useful for the small minority of DRM-encumbered content people watch. And every manufacturer, every device, would have to join, for it to make any sense at all.