Media Remoting: Add remoting control logic for encrypted contents.

media/remoting/remoting_cdm_controller.cc

+// 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.
+
+#include "media/remoting/remoting_cdm_controller.h"
+
+#include "base/bind.h"
+#include "base/callback_helpers.h"
+#include "base/logging.h"
+#include "base/threading/thread_checker.h"
+
+namespace media {
+
+RemotingCdmController::RemotingCdmController(
+    scoped_refptr<RemotingSourceImpl> remoting_source)
+    : remoting_source_(std::move(remoting_source)) {
+  remoting_source_->AddClient(this);
+}
+
+RemotingCdmController::~RemotingCdmController() {
+  DCHECK(thread_checker_.CalledOnValidThread());
+
+  remoting_source_->RemoveClient(this);
+}
+
+void RemotingCdmController::OnStarted(bool success) {
+  DCHECK(thread_checker_.CalledOnValidThread());
+
+  DCHECK(!cdm_check_cb_.is_null());
+  is_remoting_ = success;
+  base::ResetAndReturn(&cdm_check_cb_).Run(success);

[xhwang, 2016/11/01 08:21:28]

Is it possible that |cdm_check_cb_| is null, e.g. ShouldCRC() never called?

[xjz, 2016/11/01 21:55:53]

No. The RemotingCdmController will only call StartRemoting and get is
OnStarted() call when ShouldCRC() is called and |cdm_check_cb_| is not null.

+}
+
+void RemotingCdmController::OnSessionStateChanged() {
+  DCHECK(thread_checker_.CalledOnValidThread());
+
+  if (is_remoting_ &&
+      remoting_source_->state() == RemotingSessionState::SESSION_STOPPING) {
+    remoting_source_->Shutdown();

[xhwang, 2016/11/01 08:21:28]

It's a bit confusing to me on the ownership of |remoting_source_|. It seems we
can pass a remoting_source out by remoting_source(). Then who should call
Shutdown()?

[xjz, 2016/11/01 21:55:52]

After SetCdm() is called, |remoting_source_| is owned by both
RemotingCdmController and RemotingRendererController. Shutdown() will only be
called from RemotingCdmController though.

+    is_remoting_ = false;
+  }
+}
+
+void RemotingCdmController::ShouldCreateRemotingCdm(
+    const CdmCheckCallback& cb) {
+  DCHECK(thread_checker_.CalledOnValidThread());
+  DCHECK(!cb.is_null());
+
+  if (is_remoting_) {
+    cb.Run(true);
+    return;
+  }
+
+  DCHECK(cdm_check_cb_.is_null());
+  cdm_check_cb_ = cb;
+  remoting_source_->StartRemoting(this);

[xhwang, 2016/11/01 16:52:37]

For the majority (say >99%) of playback sessions where user is not casting the
tab, |is_remoting_| will always be false, so we'll always end up calling
StartRemoting() which is a mojo IPC to the browser and wait for the response
back. This could increase the start-to-play latency.

I think remoting should not introduce new latency for normal playbacks. To
achieve this, is it possible to cache some values about whether the tab is being
casted in the render process, and if it's false, do not try remoting at all?
There's a slight chance of race here that user just clicked to cast, and then
started a playback, so the render process side cache is not updated, but I think
the chance for this to happen is very small, and even if it happens, we can
always fall back to mirroring.

[xjz, 2016/11/01 21:55:52]

IIUC, this StartRemoting() call does not always end up a mojo IPC call. If
remote sink is not available (e.g., not in mirroring), we will not start
remoting, and will run the callback and return false immediately.

[xhwang, 2016/11/02 06:47:05]

I see. Thanks for pointing this out.

So now it seems we can have this in one big callstack:

RemotingCdmFactory::Create()
  CreateRemotingCdmController();
    remoter_factory_->Create(std::move(remoting_source),....
    new RemotingSourceImpl...
  remoting_cdm_controller_ptr->ShouldCreateRemotingCdm()...
    remoting_source_->StartRemoting(this);
      case SESSION_UNAVAILABLE:  // this is the default state, and we are not
getting sink availability info from browser yet
        client->OnStarted(false);
          CreateCdm(..., false);  // so we'll always use the default CDM

If this is true, then we'll never create the RemotingCdm. We should probably
break this big callstack to wait for sink availability update, but then CDM
create will be delayed since we are waiting for browser to notify us.

I feel the root problem is that we only create RemotingSourceImpl when we are
about to create the CDM. Someone in the render process should probably try to
get info about whether the tab is being casted as soon as it's available at the
RenderProcess level...

FWIW, I have no idea about what kind of latency I am talking about. If we have
data to prove it's negligible then we are probably still fine.

[xjz, 2016/11/02 17:38:11]

+miu

We currently only create the RemotingSourceImpl when Create() is called is
because the CdmFactory is shared by the whole RenderFrameImpl. Does this sound a
problem? 

[miu, 2016/11/03 00:03:08]

xhwang brings up a good point. What if we created the RemotingSourceImpl when
the factory is created (which is long before this RemotingCdmController)? That
way, it would get the OnSinkAvailable/Gone() notifications from the browser
process long before RemotingCdmController is created. Then, in this method, we
could simply:

  if (remoting_source_->state() == STATE_UNAVAILABLE) {
    // Do local CDM!
  } else if (not stopped) {
    // Do remote CDM!
  }

[xjz, 2016/11/03 00:30:15]

Yes, we can do that. So there will be always a spare RemoutingSourceImpl living
in RemotingCdmFactory. We don't need these codes though. The condition will be
checked in RemotingSourceImpl::StartRemoting().

+}
+
+}  // namespace media