Relevant discussion thread:
https://groups.google.com/a/chromium.org/forum/?utm_medium=email&utm_source=footer#!topic/headless-dev/usTF9tb7CM0

Maybe I don't quite understand the problem, but when I connect to a remote headless session through http://localhost:9222 this executes just fine:

let clearKeyOptions = [
  {
    initDataTypes: ['keyids', 'webm'],
    audioCapabilities: [
      { contentType: 'audio/webm; codecs="opus"' },
      { contentType: 'audio/webm; codecs="vorbis"' }
    ],
    videoCapabilities: [
      { contentType: 'video/webm; codecs="vp9"' },
      { contentType: 'video/webm; codecs="vp8"' }
    ]
  }
];
window.navigator.requestMediaKeySystemAccess('org.w3.clearkey', clearKeyOptions);

Am I missing something?

With this particular example it does work - So EME's are not fully disabled, but maybe in only some cases?

For instance, the one we use is by using keySystem='com.widevine.alpha':

const config = [{
    "label":"audio-video-webm-secure-decode",
    "initDataTypes":["cenc"],
    "audioCapabilities":[
        {"contentType":"audio/mp4; codecs=\"mp4a.40.2\"","robustness":"SW_SECURE_CRYPTO"},
        {"contentType":"audio/webm;codecs=\"opus\"","robustness":"SW_SECURE_DECODE"}
    ],
    "videoCapabilities":[
        {"contentType":"video/webm;codecs=\"vp8\"","robustness":"SW_SECURE_DECODE"}
    ],
    "distinctiveIdentifier":"optional",
    "persistenceState":"optional",
    "sessionTypes":["temporary"]
}]
const res = navigator.requestMediaKeySystemAccess('com.widevine.alpha', config);
res.then(keySys => console.log('success', keySys), err => console.log('error', err));

This fragment has the behaviour I described: On Chrome desktop it logs success, on Chrome --headless it logs error.

Just in case, I'm running on linux 4.10.0-40-generic (Ubuntu 17.04)

Assign to jrummell@ to take a look. It's either Widevine CDM is not registered, or the content setting to disable EME is checked.

Take a look at the configuration. The button says "offline," but offline licenses are not supported on desktop in M62.

ddorwin: Good point! If this is Chrome 62, offline is not supported on desktop Chrome yet. But from the description it seems like the config was supported if --headless is not specified.

victor: Could you please help clarify? When you try desktop Chrome, were you running Chrome 62 or 64?

xhw: That's right, in Chrome 62 the example URL doesn't work in Desktop either. Sorry that I got confused between different chrome versions when testing (Last stable version for linux is Chrome 62).

But the example in my other Comment https://bugs.chromium.org/p/chromium/issues/detail?id=788662#c3 does reproduce this behavior in 62 (Works in desktop, fails in headless). I'll try it now in last stable chrome @ windows and report back.

Tested in windows with Chrome Canary 65.0.3286.0 and both examples are reproducible (the URL example, and the code snippet in the comment)

Tried the script from #3. In headless mode it fails as 'com.widevine.alpha' is not registered. Normally Widevine is added (if present) in ChromeContentRendererClient::AddSupportedKeySystems() [1]. However, in headless mode HeadlessContentRendererClient is used. HeadlessContentRendererClient does not add any CDMs to the list (it uses the default implementation in base class ContentRendererClient [2]). So only the default 'org.w3.clearkey' is available in headless mode.

All the key system support is in chrome/renderer/media/, which is not accessible to the headless code. Not sure if it can be extracted into a generic place, due to the existing dependency on pepper plugins. Does headless mode even support plugins like Flash and the PDF viewer?

It is annoying that --headless mode doesn't handle (allow?) setting the log level.

[1] https://cs.chromium.org/chromium/src/chrome/renderer/chrome_content_renderer_client.cc?l=1443
[2] https://cs.chromium.org/chromium/src/content/public/renderer/content_renderer_client.cc?l=175

Any update on this?  We've run into needing EME enabled on headless mode as well and are blocked on using Chrome/Chromium for testing purposes in our Jenkins setup until this is fixed.  (Understandable if the response is just "we've got a lot of bugs and this one's low pri" too)

Someone needs to help answer questions raised in #11. And at the very least, fix HeadlessContentRendererClient to register the CDM. It should be straightforward to do so, but you are right that we have a lot of higher pri bugs to deal with.

Hi, is there any update on this issue? Running in to a similar problem with EMEs on our CI setup.

#13: Would registering the CDM in HeadlessContentRendererClient be enough? From #11, it sounds like we'd need to draw in implementation that currently lives in chrome/. That's not possible (headless can't depend on chrome/), this implementation would first have to be refactored into a separate component to be reusable by headless/.

#11: Headless does not support a number of chrome/ features, including chrome extensions, flash, or the PDF viewer.
 
Regarding logging in headless mode: Headless should support the --log-level switch AFAICT [1], and probably also base's --v=X.

[1] https://cs.chromium.org/chromium/src/headless/lib/headless_content_main_delegate.cc?type=cs&sq=package:chromium&l=147

Given #11 and that headless doesn't support Pepper plugins, it sounds like this might be infeasible.

Hello, as #11 points out, is there a ticket open to support Pepper plugins? 

The large video company I work for would like to utilize headless Chrome to test at scale using cloud functions/lambda to the point of simulating peak user load. 

However missing DRM for playback etc blocks us currently from using headless.

Widevine CDM has migrated to using mojo instead of pepper, so the lack of pepper plugins is unrelated in this discussion.

However, Chromium based browsers need the component updater to work to get the Widevine CDM. Is component updater supported in headless mode. Note that most component updater code is also in chrome/

https://cs.chromium.org/chromium/src/chrome/browser/component_updater/

Taking a step back. Given the fact that headless mode doesn't support some chrome/ features, what's rule of deciding what should and should not be supported in headless mode? If testing is driving force, then shall we have feature parity between head and headless mode Chrome since in theory we should be able to test everything Chrome supports in headless mode? (Sorry for my ignorance.)

Hi guys, has there been any discussion on this since the 20th?  We are currently blocked in testing and are having to consider buying actual machines so that we can use full chrome.  Obviously it'd be preferred if headless is a viable option.  Thanks!

Some headless mode owners need to help answer questions in #19.

+Sami and Pavel FYI

#19: I don't think we currently support the component updater in headless mode. How feasible do you think it would be to extract the component updater into a component? That should let us use it in headless mode.

Ideally we'd support all features in headless mode, but the chrome/content split makes this difficult in practice for features that live in the Chrome layer. 

+waffles on whether it's feasible to move component updater code to a component.

Please pardon my ignorance, but I am a bit confused about the design decision of headless mode. If the purpose is to be able to test Chrome/Chromium without display, why don't we just use chrome/ as the embedder, and optionally have some features (e.g. display related) disabled? I don't think it'll scale well if we want to have feature parity as Chrome, but use a different content embedder.

The main obstacle will be the content dependencies in widevine_cdm_component_installer.cc. Other than those, you can probably move the installer to components/component_updater and the rest should be fairly straightforward.

#include "content/public/browser/browser_thread.h"
#include "content/public/browser/cdm_registry.h"
#include "content/public/common/cdm_info.h"

We only keep the component installers and a couple other minor things in chrome/, most of the actual code is already in components/component_updater and components/update_client (has to be, to work on iOS).

Even we are limited to automate DRM playback related tests in headless chrome.