Connect WebMediaPlayerImpl to WebContentDecryptionModuleImpl for EME WD (Chromium side)

content/renderer/media/webmediaplayer_impl.cc

Index: content/renderer/media/webmediaplayer_impl.cc
diff --git a/content/renderer/media/webmediaplayer_impl.cc b/content/renderer/media/webmediaplayer_impl.cc
index ee637a6879a20a4af3f0f904c8faf60ead91dc80..1f3a140d36e0d2b9474600b7f02e1d3f243c98c2 100644
--- a/content/renderer/media/webmediaplayer_impl.cc
+++ b/content/renderer/media/webmediaplayer_impl.cc
@@ -50,6 +50,7 @@
 #include "media/filters/opus_audio_decoder.h"
 #include "media/filters/video_renderer_impl.h"
 #include "media/filters/vpx_video_decoder.h"
+#include "third_party/WebKit/public/platform/WebContentDecryptionModule.h"
 #include "third_party/WebKit/public/platform/WebMediaSource.h"
 #include "third_party/WebKit/public/platform/WebRect.h"
 #include "third_party/WebKit/public/platform/WebSize.h"
@@ -168,6 +169,10 @@ WebMediaPlayerImpl::WebMediaPlayerImpl(
 
   pipeline_.reset(new media::Pipeline(media_loop_, media_log_.get()));
 
+  // Grab a copy of the current CDM. This may be updated at any time by calls

[ddorwin, 2013/12/18 23:47:35]

It's not really a copy.

+  // to mediaKeysChanged().
+  cdm_ = client_->getWebContentDecryptionModule();

[ddorwin, 2013/12/18 23:47:35]

A WebContentDecryptionModule is not that interesting - it has no useful
interfaces. We really need the Decryptor from the MediaKeys from the
WebContentDecryptionModuleImpl.

It seems WebContentDecryptionModuleImpl is going to require a static_cast. Is
there a better way to do that?

We may still want to save the WebContentDecryptionModule for detaching, but we
should demonstrate in this CL how we are getting to something interesting so we
can evaluate whether the Blink APIs make sense.

[ddorwin, 2013/12/19 00:26:27]

I don't think this is the right time to set cdm_ (other than to NULL in the
initializer list). We should get it when we need it, which is when initializing
the pipeline. It might make more sense to be getting these objects there too.

We may end up with code that needs to be shared with mediaKeysChanged, in which
case we should consider a helper function if things get complicated.

+
   // |gpu_factories_| requires that its entry points be called on its
   // |GetMessageLoop()|.  Since |pipeline_| will own decoders created from the
   // factories, require that their message loops are identical.
@@ -853,6 +858,11 @@ WebMediaPlayerImpl::CancelKeyRequestInternal(
   return WebMediaPlayer::MediaKeyExceptionNoError;
 }
 
+void WebMediaPlayerImpl::mediaKeysChanged(
+    blink::WebContentDecryptionModule* cdm) {
+  cdm_ = cdm;

[ddorwin, 2013/12/18 23:47:35]

We need to stop any current uses of the old one (unless the pointers are the
same for whatever reason - might be a DCHECK here and Blink should prevent
that).

That makes things interesting because that operation will be asynchronous.
Therefore:

We also need to ensure that the previous CDM is not destroyed while the pipeline
is still using them. We should probably maintain a reference count to the
objects (MediaKeys/Decryptor?) that the pipeline is using in the pipeline
(Decoders?) and in WebCDMImpl.

We also need to figure out a way to prevent applications from attaching the
still-in-use MediaKeys implementation to another HTMLMediaElement. I'm going to
pursue this in a spec bug. Regardless, we will probably need some way to
indicate this is complete.

+}
+
 void WebMediaPlayerImpl::OnDestruct() {
   Destroy();
 }