media: Add MediaDrmBridgeCdmContext.

media/base/cdm_context.h

Index: media/base/cdm_context.h
diff --git a/media/base/cdm_context.h b/media/base/cdm_context.h
index 82e088d1200813a25e5008432461442db54324e0..65e25b342caa1111964107916745ec01a30defec 100644
--- a/media/base/cdm_context.h
+++ b/media/base/cdm_context.h
@@ -13,9 +13,14 @@ namespace media {
 
 class Decryptor;
 
-// An interface representing the context that a media pipeline needs from a
+// An interface representing the context that a media player needs from a
 // content decryption module (CDM) to decrypt (and decode) encrypted buffers.
 // Only used for implementing SetCdm().
+//
+// There are CDMs that support neither Decryptor nor CDM ID, but use other ways

[ddorwin, 2016/03/21 21:40:25]

We should probably move this to the new subclass as an explanation of how it
works. Changing the comments (and thus definitions) below will make this
behavior not so unexpected.

[xhwang, 2016/03/22 17:08:32]

Done.

+// to connect the CDM with a media player. In this case, the CdmContext

[ddorwin, 2016/03/21 18:06:09]

Is there a reason that the CDM ID couldn't be used to obtain the MediaCrypto? I
guess we'd have to do a lookup in a manager, which wouldn't be ideal, but
neither is casting.

If that's not ideal, should we even support CDM ID? Any implementation needing
to use an ID could implement it. The primary argument against this is likely
that we still use the ID in the renderer process (right?).

Using the same type for very different reasons in different processes makes
improvements here difficult. We're doing/allowing some things very specific to
the privileged process usage of this interface that don't make sense on the
renderer side.

If we make even AesDecryptor a Mojo service (implemented in the renderer) I
wonder if we even need these interfaces in the renderer side once we switch all
platforms to Mojo. In the meantime, I wonder if we shouldn't have different
objects, starting with PlatformMediaKeys : public MediaKeys, which would allow
different CdmContexts to be returned.

Perhaps we should formalize the pattern recommended here by having a void*
returning method, though that might not be any better.

Alternatively, if we think a CetFooReadyCB might be useful, we could add such a
method that takes a void* and let the implementation do the casting. It seems
better for the casting to be clearly intended that way and to be done by the
implementation than to put that responsibility on the caller/user of the API.

[xhwang, 2016/03/22 17:08:32]

Acknowledged.

+// implementation should add APIs to support such connection. The media player
+// should cast the CdmContext to the correct type to access such APIs.

[ddorwin, 2016/03/21 18:06:09]

It seems strange to provide such recommendations in an API definition,
especially since there are some subtleties, such as ensuring that is the only
possible type.

[xhwang, 2016/03/22 17:08:32]

Done.

 class MEDIA_EXPORT CdmContext {
  public:
   // Indicates an invalid CDM ID. See GetCdmId() for details.