Move passing of WebRTC rendering frames to IO thread

content/renderer/media/webmediaplayer_ms.h

Index: content/renderer/media/webmediaplayer_ms.h
diff --git a/content/renderer/media/webmediaplayer_ms.h b/content/renderer/media/webmediaplayer_ms.h
index 7076f26896241ba47a30797e66078562683c158e..b4905632ca8850d997d2eb17931d0de962ca6b68 100644
--- a/content/renderer/media/webmediaplayer_ms.h
+++ b/content/renderer/media/webmediaplayer_ms.h
@@ -220,9 +220,7 @@ class CONTENT_EXPORT WebMediaPlayerMS
   // Used for DCHECKs to ensure methods calls executed in the correct thread.
   base::ThreadChecker thread_checker_;
 
-  // WebMediaPlayerMS owns |compositor_| and destroys it on
-  // |compositor_task_runner_|.
-  std::unique_ptr<WebMediaPlayerMSCompositor> compositor_;
+  scoped_refptr<WebMediaPlayerMSCompositor> compositor_;

[DaleCurtis, 2016/12/03 01:17:54]

Can we avoid this? 

[emircan, 2016/12/03 01:42:13]

I can think of a way of avoiding this, but I mentioned briefly in the CL
description why I preferred not to. Let me know if I am missing smt, you can
think of another way or prefer this.
I still need to post WebMediaPlayerMSCompositor::Enqueue frame on
media_task_runner. (Main and compositor are janky, and using IO all the way here
is too long of a task for IO.) If this class is not ref counted, I would need a
WeakPtr to access it. Then, I would need two WeakPtrFactory's since there is
already one in use for compositor thread here. In dtor(or earlier), I need to
make sure that both are invalidated in their respective threads. That would
require synchronization/blocking until the other is completed.

[DaleCurtis, 2016/12/06 01:00:42]

Is this true? Or would it be sufficient to just generate a cancellable callback
you can hand out?

 
   const scoped_refptr<base::SingleThreadTaskRunner> compositor_task_runner_;