Introduce GpuVideoDecodeAcceleratorFactory.

media/video/video_decode_accelerator.h

Index: media/video/video_decode_accelerator.h
diff --git a/media/video/video_decode_accelerator.h b/media/video/video_decode_accelerator.h
index c0f6b1e862b8d78cbe4f932f98ca1514a5a064e0..777d4376ede305327a6a24fa3035ea76bbe1ab1c 100644
--- a/media/video/video_decode_accelerator.h
+++ b/media/video/video_decode_accelerator.h
@@ -10,6 +10,8 @@
 #include <memory>
 #include <vector>
 
+#include "base/memory/ref_counted.h"
+#include "base/memory/weak_ptr.h"
 #include "media/base/bitstream_buffer.h"
 #include "media/base/surface_manager.h"
 #include "media/base/video_decoder_config.h"
@@ -18,6 +20,10 @@
 
 typedef unsigned int GLenum;
 
+namespace base {
+class SingleThreadTaskRunner;
+}
+
 namespace media {
 
 // Video decoder interface.
@@ -223,16 +229,37 @@ class MEDIA_EXPORT VideoDecodeAccelerator {
   // unconditionally, so make sure to drop all pointers to it!
   virtual void Destroy() = 0;
 
-  // GPU PROCESS ONLY.  Implementations of this interface in the
-  // content/common/gpu/media should implement this, and implementations in
-  // other processes should not override the default implementation.
-  // Returns true if VDA::Decode and VDA::Client callbacks can run on the IO
-  // thread. Otherwise they will run on the GPU child thread. The purpose of
-  // running Decode on the IO thread is to reduce decode latency. Note Decode
-  // should return as soon as possible and not block on the IO thread. Also,
-  // PictureReady should be run on the child thread if a picture is delivered
-  // the first time so it can be cleared.
-  virtual bool CanDecodeOnIOThread();
+  // TO BE CALLED IN THE SAME PROCESS AS THE VDA IMPLEMENTATION ONLY.
+  //
+  // A decode "task" is a sequence that includes a Decode() call from Client,
+  // as well as corresponding callbacks to return the input BitstreamBuffer
+  // after use, and the resulting output Picture(s).
+  //
+  // If the Client can support running these three calls on a separate thread,
+  // it may call this method to try to set up the VDA implementation to do so.
+  // If the VDA can support this as well, return true, otherwise return false.
+  // If true is returned, the client may submit each Decode() call (but no other
+  // calls) on |decode_task_runner|, and should then expect that
+  // NotifyEndOfBitstreamBuffer() and PictureReady() callbacks may come on
+  // |decode_task_runner| as well, called on |decode_client|, instead of client
+  // provided to Initialize().
+  //
+  // NOTE 1: some callbacks may still have to come on the main thread and the
+  // Client should handle both callbacks coming on main and |decode_task_runner|
+  // thread.
+  //
+  // NOTE 2: VDA implementations of Decode() must return as soon as possible and
+  // never block, as |decode_task_runner| may be a latency critical thread
+  // (such as the GPU IO thread).
+  //
+  // One application of this is offloading the GPU Child thread. In general,
+  // calls to VDA in GPU process have to be done on the GPU Child thread, as
+  // they may require GL context to be current. However, some VDAs may be able
+  // to run decode operations without GL context, which helps reduce latency and
+  // offloads the GPU Child thread.
+  virtual bool TryInitializeDecodeOnSeparateThread(

[kcwu, 2016/03/02 09:00:12]

When to call this method? From the your implementation, looks like this method
could be either called before or after Initialize(). Would you like to document
this?

Furthermore, "TryInitialize", the name seems suggest this method can suppress
Initialize(), which is false. Do you feel this is an issue?

[Pawel Osciak, 2016/03/02 10:16:49]

Done.

+      const base::WeakPtr<Client>& decode_client,
+      const scoped_refptr<base::SingleThreadTaskRunner>& decode_task_runner);
 
   // Windows creates a BGRA texture.
   // TODO(dshwang): after moving to D3D11, remove this. crbug.com/438691