Implement setPreventsCapture support for DRM video on Mac
Categories
(Core :: Audio/Video: GMP, enhancement)
Tracking
()
Tracking | Status | |
---|---|---|
firefox106 | --- | fixed |
People
(Reporter: jimm, Assigned: bradwerth)
References
Details
Attachments
(3 files, 1 obsolete file)
There's a newer capture related call introduced in 10.15 we should set on video layers when content capture is active.
Not sure if this would fall under graphics or media.
Reporter | ||
Comment 1•2 years ago
|
||
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.
Assignee | ||
Comment 2•2 years ago
|
||
(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.
Assignee | ||
Comment 3•2 years ago
|
||
(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.
Assignee | ||
Comment 4•2 years ago
|
||
Looks like this will be a 3-step process:
- 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 thatTrackInfo::mCrypto::IsEncrypted()
signifies this. - 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.
- When the compositor displays the native texture, check the DRM flag and set the property on the video layer. This is the easy part.
Reporter | ||
Updated•2 years ago
|
Assignee | ||
Comment 5•2 years ago
•
|
||
(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.
Assignee | ||
Comment 6•2 years ago
|
||
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.
Assignee | ||
Comment 7•2 years ago
|
||
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
Assignee | ||
Comment 8•2 years ago
|
||
Depends on D155296
Assignee | ||
Comment 9•2 years ago
|
||
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.
Updated•2 years ago
|
Assignee | ||
Comment 10•2 years ago
|
||
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?
Comment 11•2 years ago
|
||
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.
Comment 12•2 years ago
|
||
Comment 13•2 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/6fa7ede8ee41
https://hg.mozilla.org/mozilla-central/rev/26f3e8647964
https://hg.mozilla.org/mozilla-central/rev/7e2decd8cf2c
Description
•