Add CdmService to keep track of CDMs

content/public/browser/cdm_service.h

+// Copyright 2016 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#ifndef CONTENT_PUBLIC_BROWSER_CDM_SERVICE_H_
+#define CONTENT_PUBLIC_BROWSER_CDM_SERVICE_H_
+
+#include <vector>
+
+#include "content/common/content_export.h"
+#include "content/public/common/cdm_info.h"
+
+namespace content {
+
+class CONTENT_EXPORT CdmService {

[xhwang, 2016/03/26 07:46:34]

Previously you mentioned that we can't put this under content/public/browser
because "CdmService will eventually be needed by
content/zygote/zygote_main_linux.cc ... to get the list of CDMs for loading". Is
this not a concern any more?

[jrummell, 2016/03/29 23:48:45]

As we discussed offline, the zygote doesn't use the PluginService. It simply
calls the equivalent of AddContentDecryptionModules() to get the list of
plugins. So we'll do the same.

[xhwang, 2016/03/30 05:11:18]

Great. It's even better now we can keep this in content/public/browser!

[jrummell, 2016/04/01 21:15:53]

Agreed.

+ public:
+  // Returns the CdmService singleton.
+  static CdmService* GetInstance();
+
+  virtual ~CdmService() {}
+
+  // Determines the list of available CDMs and registers them.
+  virtual void RegisterAllAvailableCdms() = 0;

[xhwang, 2016/03/26 07:46:34]

Why this is on the public API? Who should call it? Shouldn't this be called
internally when CdmServiceImpl constructs itself?

[jrummell, 2016/03/29 23:48:45]

ddorwin@ asked in a previous comment to make it explicit. This also matches up
with PluginServiceImpl::RegisterPepperPlugins().

[xhwang, 2016/03/30 05:11:17]

RegisterPepperPlugins() is a private helper function in PluginServiceImpl. It's
not part of content public API. Do you remember why ddorwin@ suggests to add
this?

[jrummell, 2016/04/01 21:15:53]

As discussed offline, this is now renamed Init() (which is the public call on
PluginService).

+
+  // Registers a CDM with the specified CDM information.
+  // If |add_at_beginning| is true the CDM will be added earlier in
+  // the list so that it can override any older registrations.
+  virtual void RegisterCdm(const CdmInfo& info, bool add_at_beginning) = 0;

[xhwang, 2016/03/26 07:46:34]

Today in pepper we always append at end. This is important so that we don't end
up using the information in a older CDM for rMKSA, but load the newer CDM in
createMediaKeys(). Only after we restart the browser will the new CDM take
effect if there was an old CDM.

So for this API, when will we need |add_at_beginning| to be true?

[jrummell, 2016/03/29 23:48:45]

The component updater adds new versions to the front of the list.

However, either way we have possible problems between the timing of the RMSKA()
call and the timing of CreateMediaKeys() if we don't pass versions around (e.g.
the former could see v1, while v2 is available by the time of the latter).
Currently the view is that v2 will still be a better fit, as capabilities should
normally be increasing. Obviously if they decrease, there will be possible
problems later on.

[xhwang, 2016/03/30 05:11:18]

This model is seems a bit complicated. How would we decide wether
|add_at_beginning| should be true or false?

I am a big fan of simple solutions that work. Can we just keep the current
behavior such that the second registration will not take effect? In the
component CDM's case, after we restart the browser, the old CDM will be removed
from disk and we'll only register the new CDM.

[jrummell, 2016/04/01 21:15:53]

Done.

+
+  // Returns the list of all registered CDMs and the associated data.
+  virtual const std::vector<CdmInfo>& GetAllRegisteredCdms() = 0;
+};
+
+}  // namespace content
+
+#endif  // CONTENT_PUBLIC_BROWSER_CDM_SERVICE_H_