PPAPI, even with NaCl, restricts the methods that you can call. Attempting to LoadLibrary() or interacting with drivers won't work.
Thanks in advance for your insights.
--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
When possible, it is best to run the CDM in a separate sandboxed process. Chromium currently uses Pepper APIs for this purpose, but this is an implementation detail and Pepper is not the “CDM API”. The actual CDM is hosted within a wrapper that calls the content_decryption_module.h interface. This API is more stable but not guaranteed not to change over time.
or the CDM needs platform support (e.g. talk to some driver), the “CDM” needs to call platform APIs. Thus, the renderer must IPC to a higher-privilege process, such as the browser process. For this, we have the BrowserCdm path.
When possible, it is best to run the CDM in a separate sandboxed process. Chromium currently uses Pepper APIs for this purpose, but this is an implementation detail and Pepper is not the “CDM API”. The actual CDM is hosted within a wrapper that calls the content_decryption_module.h interface. This API is more stable but not guaranteed not to change over time.Am I correct in my assumption that the external clear-key CDM provides a basic implementation of this technique?
or the CDM needs platform support (e.g. talk to some driver), the “CDM” needs to call platform APIs. Thus, the renderer must IPC to a higher-privilege process, such as the browser process. For this, we have the BrowserCdm path.The prototyping scenario I have sounds more along these lines. I was under the impression that I could use the external clear-key CDM as the hook for facilitating this, but maybe I'm going about this the wrong way. Could you comment on whether the technique below would even work on Windows Chromium?
- HTML5/JS declares an instance of a custom-DRM plugin.
- Chromium interprets the HTML5/JS and instantiates an instance of my Pepper Plugin, which embodies the CDM.
- Chromium, in an ongoing manner, keeps the Pepper Plugin CDM appraised of the required render location for the video.
- My Pepper Plugin CDM allocates any necessary D3D11 surfaces to comply with the location requirements from [3] and any security/protection requirements from the DRM. (It's not clear to me whether I should allocate the surface in the Pepper Plugin CDM or in my elevated process.)
- My Pepper Plugin CDM passes the D3D11 surface(s) to a different/elevated process (e.g. a Windows Service) over IPC. If I need to talk to drivers or other privileged functions, they would probably reside in this privileged Windows Service process, so as to not burden the chrome process or the sandboxed CDM with a requirement to run in an elevated manner. Drawing to the surface happens in this elevated process in a secure manner, as demanded by any DRM robustness rules.
--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
How will the media pipeline look like in your system? Will the CDM handle all the decryption, decoding and rendering?
If so, there's a (new) path to support customized media pipeline/CDM in the browser process, or a different child process (e.g. utility process). If you are interested in this path, you can take a look at MojoMediaApplication and ENABLE_MOJO_MEDIA_IN_BROWSER_PROCESS.
Also, what .html file or webpage should I use to ensure the execution path goes to MojoMediaApplication?
--
Ah. OK. I did not realize there were separate GN and GYP build processes.Out of curiosity, do EME-related transactions flow between Chrome/EME and MojoMediaApplication, or is MojoMediaApplication only wired up to handle basic windowing placement and input events? I noticed references to CDM in the code, but I am not sure if those are just stubs.
--
Are you making a GN build instead of a gyp build? The new mojo media application path is only supported in GN builds.
ERROR at dynamically parsed input that //build/config/win/visual_studio_version.gni:27:7 loaded :1:15: Invalid token.vs_path = ""C:/Program Files (x86)/Microsoft Visual Studio 12.0""^I have no idea what this is.
--