Add a GpuMemoryBuffer pool that creates hardware backed VideoFrames.

media/video/gpu_memory_buffer_video_frame_pool.h

Index: media/video/gpu_memory_buffer_video_frame_pool.h
diff --git a/media/video/gpu_memory_buffer_video_frame_pool.h b/media/video/gpu_memory_buffer_video_frame_pool.h
new file mode 100644
index 0000000000000000000000000000000000000000..18ab86fe79c783a12a25dfd0b4f892e39244ffb7
--- /dev/null
+++ b/media/video/gpu_memory_buffer_video_frame_pool.h
@@ -0,0 +1,43 @@
+// Copyright (c) 2015 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.
+
+#ifndef MEDIA_VIDEO_GPU_MEMORY_BUFFER_VIDEO_FRAME_POOL_H_
+#define MEDIA_VIDEO_GPU_MEMORY_BUFFER_VIDEO_FRAME_POOL_H_
+
+#include "base/macros.h"
+#include "base/memory/ref_counted.h"
+#include "media/base/video_frame.h"
+
+namespace base {
+class SingleThreadTaskRunner;
+}
+
+namespace media {
+class GpuVideoAcceleratorFactories;
+
+// Interface to a pool of GpuMemoryBuffers that can be used to back VideoFrames.
+// Calling the method MaybeCreateHardwareFrame with a software frame will
+// create and return a VideoFrame containing only mailboxes to the native
+// resources needed to draw. If it's not possible to create an hardware
+// VideoFrame the object passed as parameter will be returned.

[DaleCurtis, 2015/05/12 17:23:20]

Needs a lot more details about OOM situations and some minor details about how
recycling is implemented.

[Daniele Castagna, 2015/05/12 21:21:30]

Shouldn't the comment on the interface be only high level view on what it does
and how to use it?

More details on how recycling is implemented are in the .cc file.

Why are you so concerned about OOMing? Don't we just fail everywhere else in
Chromium if we OOM? The renderer process is probably going to crash before the
failed allocation reaches the pool.

+class GpuMemoryBufferVideoFramePool {
+ public:
+  explicit GpuMemoryBufferVideoFramePool(
+      const scoped_refptr<base::SingleThreadTaskRunner>& task_runner,
+      const scoped_refptr<GpuVideoAcceleratorFactories>& gpu_factories);

[reveman, 2015/05/12 03:20:26]

I dunno about media put in other parts of chromium we typically always use a raw
pointer when passing a ref-counted instance to a function

[DaleCurtis, 2015/05/12 17:23:20]

media passes these via const& which should do the same thing and avoid
accidentally losing some refs.

[Daniele Castagna, 2015/05/12 21:21:30]

Leaving the const& as suggested by dalecurtis.

+  ~GpuMemoryBufferVideoFramePool();
+
+  const scoped_refptr<VideoFrame> MaybeCreateHardwareFrame(

[reveman, 2015/05/12 03:20:25]

why 'const' return type?

[Daniele Castagna, 2015/05/12 21:21:30]

Because if we can't create the hardwareframe we just retun the param, that is
const, so the return value needs to be const as well.

[DaleCurtis, 2015/05/13 02:52:14]

Is this still true after using const& it should just make a copy or something?

[Daniele Castagna, 2015/05/13 04:29:45]

No, changed it.

+      const scoped_refptr<VideoFrame>);

[reveman, 2015/05/12 03:20:25]

nit: missing param name

[DaleCurtis, 2015/05/12 17:23:20]

Should be const&

[Daniele Castagna, 2015/05/12 21:21:30]

Done.

[Daniele Castagna, 2015/05/12 21:21:30]

Done. Also changed it to &.

+
+ private:
+  class PoolImpl;
+  scoped_refptr<PoolImpl> pool_impl_;
+
+  DISALLOW_COPY_AND_ASSIGN(GpuMemoryBufferVideoFramePool);
+};
+
+}  // namespace media
+
+#endif  // MEDIA_VIDEO_GPU_MEMORY_BUFFER_VIDEO_FRAME_POOL_H_