There's a newer capture related call introduced in 10.15 we should set on video layers when content capture is active.

https://source.chromium.org/chromium/chromium/src/+/main:ui/accelerated_widget_mac/ca_renderer_layer_tree.mm;drc=a3d665ee5b870abe22cce8ce2eef0abcd38025b5;l=1189

Not sure if this would fall under graphics or media.

Hey Brad, trying to find someone to look at this. Chrome implemented this a while back on new versions of the OS. This might fall on media team, not sure. Curious if you have any thoughts.

(In reply to Jim Mathies [:jimm] from comment #1)

Hey Brad, trying to find someone to look at this. Chrome implemented this a while back on new versions of the OS. This might fall on media team, not sure. Curious if you have any thoughts.

Yeah, we can set that property on AVSampleBufferDisplayLayer. We use that layer when the gfx.core-animation.specialize-video pref is set, which it is now for all Apple Silicon since Bug 1772024 landed. Bug 1747999 is the blocker that keeps us from turning it on for Intel macOS. Anyway, in time, all our video will use this layer and we can start using its DRM-preserving capabilities now.

I'll build a patch that sets the DRM-appropriate flag in this layer when needed.

(In reply to Jim Mathies [:jimm] from comment #0)

Not sure if this would fall under graphics or media.

Because of the WebRender pipeline, this DRM flag will probably have to pass through to RenderTextureHost which makes it a graphics issue. Actually setting the flag on the layer is trivial.

Looks like this will be a 3-step process:

1. Annotate the video at the decoder level (in the VideoInfo structure?) that it comes from a DRM source. I'm surprised this isn't already available. It's possible that TrackInfo::mCrypto::IsEncrypted() signifies this.
2. Propagate that information through WebRender so that the video texture is annotated with DRM-ness as it emerges from WebRender and is sent to the compositor as a native texture. This will be tricky and will require touching a lot of code in small ways.
3. When the compositor displays the native texture, check the DRM flag and set the property on the video layer. This is the easy part.

(Edited) I was mistaken. Firefox does not black out Netflix content, currently.

Interestingly, when testing this with Netflix content in a window, I found that the macOS Capture tool already blacks-out the video portion of the captured region. I'm not sure what mechanism accomplishes this. YouTube can be captured normally.

This also modifies Image to track whether or not it is from a DRM source.
Later parts of the patch move this characteristic into the textures that
are used by compositors.

At point of display, we need the TextureHost to know whether or not its
texture was created from a DRM Image. The throughline of data is:

Image -> TextureClient -> TextureHost

The TextureClient is generated by the Image, so it has access to the DRM
state of the Image, but the TextureHost is built from the raw texture data
and from TextureFlags. This patch updates TextureFlags to include a
DRM_SOURCE bit for use by the TextureHost.

The TextureClient and TextureHost are platform-specific classes. The
creation of the TextureClient by the Image is done in a platform-specific
subclass of Image. This patch only implements this pipeline for macOS.
There doesn't seem to be a way to do this in cross-platform classes, but
other platforms can follow the pattern used here.

Depends on D155295

Depends on D155296

This creates a new test for checking that we black out canvas capture of
EME content. The existing test, test_eme_canvas_blocked, tests a lot of
EME content and is disabled on various platforms for incompatibility with
certain EME features. This uses a much shorter lists of video-only
encrypted media and will pass on more platforms.

I didn't realize that we already had an established canvas snapshot protection mechanism which is tested by (test_eme_canvas_blocked.html)[https://searchfox.org/mozilla-central/source/dom/media/test/test_eme_canvas_blocked.html). I assume that doesn't protect against OS screenshot tools, which is why this Bug exists. Alastor, is that correct? If so, do you have any advice on how to construct a test that exercises something like an OS-based screenshot?

Yes, that is what I understand as well. We prohibit stream capturing for encrypted content, but there is no way for a media element against OS level screen shot.

I don't know much about screenshot. I found some codes which seem related with screenshot, but not sure if they are also implemented based on canvas.

https://hg.mozilla.org/mozilla-central/rev/6fa7ede8ee41
https://hg.mozilla.org/mozilla-central/rev/26f3e8647964
https://hg.mozilla.org/mozilla-central/rev/7e2decd8cf2c