6 ms·

Haha, wow, I hadn't realized they'd finally moved ahead with blocking screenshots on my own computer. Anyone know what level that's happening at and how hard it

Haha, wow, I hadn't realized they'd finally moved ahead with blocking screenshots on my own computer. Anyone know what level that's happening at and how hard it is to circumvent? The article says that the DRM block is "reassuring on the surface, but it's still far too vague for anyone to actually have any faith in it." I disagree--it's not reassuring on any level whatsoever.

madeofpalk 2y ago
Operating systems have been doing this for... 10-15 years?
- deleted 2y ago
  [deleted]
- jasonfarnon 2y ago
  10-15 years ago was windows 7
  - deleted 2y ago
    [deleted]
derefr 2y ago
When you play a video, you're (usually) sending the encoded video to the GPU for hardware-accelerated decode. The resulting decoded frames then live purely on the GPU. However, rather than each video frame being decoded into a distinct VRAM texture with its own manipulable GPU handle, with hardware-accelerated decode, you just tell the GPU to allocate a single buffer — a mutable canvas, or "draw context" — and then tell it that, as the chunks of your encoded video stream are being played, decoded, and rasterized into frames by the GPU, the GPU should be writing each successive frame it's generating into this buffer. In this setup, the only thing you can get a GPU handle for (besides the encoded video stream) is that buffer. That buffer is special, being the target of the GPU's own asynchronous hardware-accelerated rendering process; so that buffer is referred to as a "hardware-accelerated draw context." (These days GPUs have enough VRAM that you really could get away with dumping each frame out to its own immutable VRAM texture buffer; but back in the early '90s when hardware-accelerated video decode was first invented, reusing a single buffer [or maybe a pair of them] for decoding was a practical necessity. Hardware-accelerated draw contexts have been core to how GPUs work since there were GPUs.) In general, the GPU doesn't allow you to read directly from the VRAM backing a hardware-accelerated draw context (because doing so could block the GPU from writing to it, and also because doing so wouldn't get you a coherent single frame's state out.) The GPU locks that VRAM up and considers it to be "its to use" for as long as the draw context is the target of a hardware-accelerated pipeline. So the GPU will ignore any attempt to use any existing handle you had to the VRAM backing the draw context; only the handle to the wrapping draw-context ADT will work, and that handle doesn't have "read from" as part of its command-set. So how does such a draw context even end up on the screen, then? When a desktop window compositor sets up the GPU to display your windows, it takes various draw-contexts — some of which may be hardware-accelerated — and lays them out in 3D space, with a (usually orthographic) projection. The GPU itself is then told to take care of the rest (the final toplevel "get this scene out and onto a screen" part) internally. There's never a point under normal GPU rendering, where your entire screen-contents are rendered out to a single (externally-addressable) VRAM texture. What happens when you take a screenshot, then? Usually, the compositor is pinged to ask it to render that screenshot; and it does so by allocating a screen-sized VRAM buffer, and then taking each GPU handle in turn and telling the GPU to copy the VRAM underlying that buffer, into the target buffer. But oh no — HW-accel draw-contexts don't have exposed VRAM handles! It used to be (until... Windows Vista, I think?) that hardware-accelerated draw contexts in general (like videos being played using hardware decoding, or like 3D games) just weren't ever captured in screenshots, DRM or no. This was purely a question of GPU performance: a GPU with an architecture that could snapshot a frame of an HW-accel context, wouldn't perform as well as a GPU with an architecture that couldn't. When this ability was later added, it was done so by adding a feature to the GPU: a command was added on HW-accel draw contexts, that would prompt them to stop whatever rendering is happening into the buffer for a moment, at a coherent point; to snapshot that coherent state of the internal VRAM state, copying it over into a non-HW-accelerated buffer; and to then get the accelerated rendering going again. The compositor therefore now had the ability to ask the such draw-contexts for such snapshots, to then be re-copied out into a WIP screenshot. But I emphasize "ask" here — you really are just asking the GPU to do it. The GPU can always just refuse! (OSes had to support GPUs refusing to do it, because many GPUs were old enough that they couldn't manage to do it, even given updated drivers that allowed software to ask the GPU the question; even given newer firmware pushed to the GPU by said drivers.) So DRMed video was implemented simply by telling the GPU that there are some HW-accel draw-contexts that are special, and so the GPU should refuse any requests to snapshot them. (And also, telling the GPU that the encoded video itself is also special — so the GPU should taint any draw-contexts it decodes that video onto with the same specialness.) I believe that DRMed video streams get decrypted on the CPU before being sent to the GPU. So while you can't capture a screenshot of the decoded frame, you could in theory capture the (encoded) video in RAM. Sadly, that RAM is protected by the OS and the decoding happens using Intel SGX or something. So it's impossible to "get in under" the OS to grab the encoded video, either. (Unless you compile a custom kernel... but that's why these extensions have an in-kernel component that doesn't ship with the Windows or macOS DDKs, and why Linux doesn't even get DRMed-video support except in proprietary spins.)
- derefr 2y ago
  A bonus tangent: > there's never a point under normal rendering where your entire screen-contents are flattened into a single (externally-addressable) VRAM texture. ...although there used to be, back at the dawn of GPUs. The first "3D acceleration cards" didn't do any 2D drawing — and so PCs would actually have distinct 2D and 3D video cards! The oldest 2D video cards for PCs, were just persistent framebuffers — their "VRAM" being just for what was on the screen. They relied on the OS to find anything that had been uncovered, and tell the app to repaint it. But the last and greatest 2D video cards, from before 3D took over, were masters of copying memory around. Each frame, they'd be doing all of these huge accelerated rectangular blits of windows and their controls — some VRAM-to-VRAM, some from main memory using DMA — to bake down a VRAM buffer. They were hardware-accelerated 2D compositors, and they were great at it. When early 3D cards came along, all that changed at first, was that your OS would tell your 2D card that there was a certain region it was to avoid drawing anything on. The 2D card would leave a black rectangle there. The 2D card would render and rasterize its VRAM to VGA — and the 3D accelerator card would then be passed this same VGA signal, along a cable, as if it was a display. It would mostly just repeat everything it saw. But when the signal hit the timings for where those black rectangles should appear, then it would instead emit its rendering of the 3D content. (In other words: early 3D cards were https://en.wikipedia.org/wiki/Genlock https://en.wikipedia.org/wiki/Genlock cards!) A "hardware-accelerated draw context", in this very early conception of the term, was precisely the geometry, defined by your OS, that your 2D card knew to not bother to draw; which was also the geometry that your 3D card knew was its to draw on. 2D and 3D video cards later merged, and at first you just got one card that did both of these things, as separate phases, with the bridging now internal. But the concept of an HW-accel context lived on. But later on, actual "GPUs" emerged — in the form of 3D hardware that was now sorta-okay at doing VRAM-to-VRAM copies, and also provided legacy VGA BIOS emulation. So people ditched their 2D cards. But this change actually kind of sucked, because it meant that all the per-frame 2D blitting (which, again, GPUs were just barely passable at) was now contending for GPU time with 3D stuff. And modern OSes had grown highly dependent on being able to do lots of 2D blitting each frame. This was why "full-screen mode" was, for the longest time, the way to get the best 3D performance out of a GPU, even at the same display resolution. If you tell the GPU that you want to cover the entire screen with a 3D hardware-accelerated draw context... then it will realize that it'd be pointless to keep drawing the "2D world", and so it will stop spending its time each frame doing 2D VRAM copies to render the 2D-composited layer. It takes the whole OS window-drawing VRAM-copy command-queue out of the loop. (And also — once there was OS support for this — switching to full-screen mode would also cause the GPU to flush out all the VRAM textures for rendered windows, fonts, icons, etc — giving a 3D app or game far more VRAM to work with. Coming out of full-screen mode would likewise ping the OS to reload all the system brushes and textures into VRAM; and then ping all the running apps to redraw themselves.)
kalleboo 2y ago
> Haha, wow, I hadn't realized they'd finally moved ahead with blocking screenshots on my own computer Windows has been doing this since Vista, 17 years ago https://en.wikipedia.org/wiki/Protected_Media_Path https://en.wikipedia.org/wiki/Protected_Media_Path

madeofpalk 2y ago

Operating systems have been doing this for... 10-15 years?

deleted 2y ago
[deleted]
jasonfarnon 2y ago
10-15 years ago was windows 7
- deleted 2y ago
  [deleted]

derefr 2y ago

When you play a video, you're (usually) sending the encoded video to the GPU for hardware-accelerated decode. The resulting decoded frames then live purely on the GPU. However, rather than each video frame being decoded into a distinct VRAM texture with its own manipulable GPU handle, with hardware-accelerated decode, you just tell the GPU to allocate a single buffer — a mutable canvas, or "draw context" — and then tell it that, as the chunks of your encoded video stream are being played, decoded, and rasterized into frames by the GPU, the GPU should be writing each successive frame it's generating into this buffer. In this setup, the only thing you can get a GPU handle for (besides the encoded video stream) is that buffer. That buffer is special, being the target of the GPU's own asynchronous hardware-accelerated rendering process; so that buffer is referred to as a "hardware-accelerated draw context." (These days GPUs have enough VRAM that you really could get away with dumping each frame out to its own immutable VRAM texture buffer; but back in the early '90s when hardware-accelerated video decode was first invented, reusing a single buffer [or maybe a pair of them] for decoding was a practical necessity. Hardware-accelerated draw contexts have been core to how GPUs work since there were GPUs.) In general, the GPU doesn't allow you to read directly from the VRAM backing a hardware-accelerated draw context (because doing so could block the GPU from writing to it, and also because doing so wouldn't get you a coherent single frame's state out.) The GPU locks that VRAM up and considers it to be "its to use" for as long as the draw context is the target of a hardware-accelerated pipeline. So the GPU will ignore any attempt to use any existing handle you had to the VRAM backing the draw context; only the handle to the wrapping draw-context ADT will work, and that handle doesn't have "read from" as part of its command-set. So how does such a draw context even end up on the screen, then? When a desktop window compositor sets up the GPU to display your windows, it takes various draw-contexts — some of which may be hardware-accelerated — and lays them out in 3D space, with a (usually orthographic) projection. The GPU itself is then told to take care of the rest (the final toplevel "get this scene out and onto a screen" part) internally. There's never a point under normal GPU rendering, where your entire screen-contents are rendered out to a single (externally-addressable) VRAM texture. What happens when you take a screenshot, then? Usually, the compositor is pinged to ask it to render that screenshot; and it does so by allocating a screen-sized VRAM buffer, and then taking each GPU handle in turn and telling the GPU to copy the VRAM underlying that buffer, into the target buffer. But oh no — HW-accel draw-contexts don't have exposed VRAM handles! It used to be (until... Windows Vista, I think?) that hardware-accelerated draw contexts in general (like videos being played using hardware decoding, or like 3D games) just weren't ever captured in screenshots, DRM or no. This was purely a question of GPU performance: a GPU with an architecture that could snapshot a frame of an HW-accel context, wouldn't perform as well as a GPU with an architecture that couldn't. When this ability was later added, it was done so by adding a feature to the GPU: a command was added on HW-accel draw contexts, that would prompt them to stop whatever rendering is happening into the buffer for a moment, at a coherent point; to snapshot that coherent state of the internal VRAM state, copying it over into a non-HW-accelerated buffer; and to then get the accelerated rendering going again. The compositor therefore now had the ability to ask the such draw-contexts for such snapshots, to then be re-copied out into a WIP screenshot. But I emphasize "ask" here — you really are just asking the GPU to do it. The GPU can always just refuse! (OSes had to support GPUs refusing to do it, because many GPUs were old enough that they couldn't manage to do it, even given updated drivers that allowed software to ask the GPU the question; even given newer firmware pushed to the GPU by said drivers.) So DRMed video was implemented simply by telling the GPU that there are some HW-accel draw-contexts that are special, and so the GPU should refuse any requests to snapshot them. (And also, telling the GPU that the encoded video itself is also special — so the GPU should taint any draw-contexts it decodes that video onto with the same specialness.) I believe that DRMed video streams get decrypted on the CPU before being sent to the GPU. So while you can't capture a screenshot of the decoded frame, you could in theory capture the (encoded) video in RAM. Sadly, that RAM is protected by the OS and the decoding happens using Intel SGX or something. So it's impossible to "get in under" the OS to grab the encoded video, either. (Unless you compile a custom kernel... but that's why these extensions have an in-kernel component that doesn't ship with the Windows or macOS DDKs, and why Linux doesn't even get DRMed-video support except in proprietary spins.)

derefr 2y ago
A bonus tangent: > there's never a point under normal rendering where your entire screen-contents are flattened into a single (externally-addressable) VRAM texture. ...although there used to be, back at the dawn of GPUs. The first "3D acceleration cards" didn't do any 2D drawing — and so PCs would actually have distinct 2D and 3D video cards! The oldest 2D video cards for PCs, were just persistent framebuffers — their "VRAM" being just for what was on the screen. They relied on the OS to find anything that had been uncovered, and tell the app to repaint it. But the last and greatest 2D video cards, from before 3D took over, were masters of copying memory around. Each frame, they'd be doing all of these huge accelerated rectangular blits of windows and their controls — some VRAM-to-VRAM, some from main memory using DMA — to bake down a VRAM buffer. They were hardware-accelerated 2D compositors, and they were great at it. When early 3D cards came along, all that changed at first, was that your OS would tell your 2D card that there was a certain region it was to avoid drawing anything on. The 2D card would leave a black rectangle there. The 2D card would render and rasterize its VRAM to VGA — and the 3D accelerator card would then be passed this same VGA signal, along a cable, as if it was a display. It would mostly just repeat everything it saw. But when the signal hit the timings for where those black rectangles should appear, then it would instead emit its rendering of the 3D content. (In other words: early 3D cards were https://en.wikipedia.org/wiki/Genlock https://en.wikipedia.org/wiki/Genlock cards!) A "hardware-accelerated draw context", in this very early conception of the term, was precisely the geometry, defined by your OS, that your 2D card knew to not bother to draw; which was also the geometry that your 3D card knew was its to draw on. 2D and 3D video cards later merged, and at first you just got one card that did both of these things, as separate phases, with the bridging now internal. But the concept of an HW-accel context lived on. But later on, actual "GPUs" emerged — in the form of 3D hardware that was now sorta-okay at doing VRAM-to-VRAM copies, and also provided legacy VGA BIOS emulation. So people ditched their 2D cards. But this change actually kind of sucked, because it meant that all the per-frame 2D blitting (which, again, GPUs were just barely passable at) was now contending for GPU time with 3D stuff. And modern OSes had grown highly dependent on being able to do lots of 2D blitting each frame. This was why "full-screen mode" was, for the longest time, the way to get the best 3D performance out of a GPU, even at the same display resolution. If you tell the GPU that you want to cover the entire screen with a 3D hardware-accelerated draw context... then it will realize that it'd be pointless to keep drawing the "2D world", and so it will stop spending its time each frame doing 2D VRAM copies to render the 2D-composited layer. It takes the whole OS window-drawing VRAM-copy command-queue out of the loop. (And also — once there was OS support for this — switching to full-screen mode would also cause the GPU to flush out all the VRAM textures for rendered windows, fonts, icons, etc — giving a 3D app or game far more VRAM to work with. Coming out of full-screen mode would likewise ping the OS to reload all the system brushes and textures into VRAM; and then ping all the running apps to redraw themselves.)

kalleboo 2y ago

> Haha, wow, I hadn't realized they'd finally moved ahead with blocking screenshots on my own computer Windows has been doing this since Vista, 17 years ago https://en.wikipedia.org/wiki/Protected_Media_Path https://en.wikipedia.org/wiki/Protected_Media_Path