[Cast] VideoFrameFactory interface to vend frames with encoder affinity.

media/cast/sender/video_frame_factory_pool_impl.h

Index: media/cast/sender/video_frame_factory_pool_impl.h
diff --git a/media/cast/sender/video_frame_factory_pool_impl.h b/media/cast/sender/video_frame_factory_pool_impl.h
new file mode 100644
index 0000000000000000000000000000000000000000..2b336ef1e91626b44a021652081ab6fd48d55404
--- /dev/null
+++ b/media/cast/sender/video_frame_factory_pool_impl.h
@@ -0,0 +1,42 @@
+// Copyright 2014 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_CAST_SENDER_VIDEO_FRAME_FACTORY_POOL_IMPL_H_
+#define MEDIA_CAST_SENDER_VIDEO_FRAME_FACTORY_POOL_IMPL_H_
+
+#include "media/base/video_frame_pool.h"
+#include "media/cast/cast_config.h"
+#include "media/cast/sender/video_frame_factory.h"
+
+namespace media {
+
+class VideoFrame;
+
+namespace cast {
+
+// Implementation of the VideoFrameFactory interface using |VideoFramePool|.

[Alpha Left Google, 2014/11/17 20:23:14]

I see no user of this class other than unit test. Do we really need this? Are we
going to use it?

[jfroy, 2014/11/17 21:23:06]

I wanted this code path to always be usable, so I provided a reasonable default.
It is an opt-in interface. I haven't looked at leveraging it in other areas in
Chrome, but perhaps a good candidate would be for tab mirroring on OS X where
hardware encoding could be leverage to reduce CPU load and power usage on
laptops?

[Alpha Left Google, 2014/11/18 02:57:58]

On OSX we have no plan to support H264. Even if hardware encoding is used on OSX
the frame comes from a browser process, there's no creation of VideoFrame in the
renderer (owner of CastSender). On supported platforms we expect the VideoFrame
passed into VideoFrameInput is already optimized for encoding. I see the need to
create a VideoFrame via VidoeFrameInput a special case. I suggest you keep the
interface but move the implementation of this to the unit test.

[jfroy, 2014/11/18 18:03:59]

Using hardware encoding where available seems like a good idea, but that's way
off topic. Sorry for bringing it up.

What should the interface do for other encoders? Return null? If so, do we still
need another method to query "supports specialized frame allocation", or is a
null return value sufficient?

+class VideoFrameFactoryPoolImpl : public VideoFrameFactory {
+ public:
+  explicit VideoFrameFactoryPoolImpl(const VideoSenderConfig& video_config);
+
+  // VideoFrameFactory
+  scoped_refptr<VideoFrame> CreateFrame(base::TimeDelta timestamp) override;
+
+ protected:
+  ~VideoFrameFactoryPoolImpl() override {}
+
+ private:
+  friend class base::RefCountedThreadSafe<VideoFrameFactoryPoolImpl>;
+
+  VideoFramePool pool_;

[Alpha Left Google, 2014/11/17 20:23:14]

There's really not need for a software based VideoFrame pool. If it is unit test
only it should only be in the test.

[jfroy, 2014/11/17 21:23:06]

I think I answer that in my comment above.

+  int width_;
+  int height_;
+
+  DISALLOW_COPY_AND_ASSIGN(VideoFrameFactoryPoolImpl);
+};
+
+}  // namespace cast
+}  // namespace media
+
+#endif  // MEDIA_CAST_SENDER_VIDEO_FRAME_FACTORY_POOL_IMPL_H_