media: add video capture device for ARC++ camera HAL v3

media/capture/video/chromeos/video_capture_device_arc_chromeos.h

Index: media/capture/video/chromeos/video_capture_device_arc_chromeos.h
diff --git a/media/capture/video/chromeos/video_capture_device_arc_chromeos.h b/media/capture/video/chromeos/video_capture_device_arc_chromeos.h
new file mode 100644
index 0000000000000000000000000000000000000000..70cac49481506f634e097990041115b803f64a5a
--- /dev/null
+++ b/media/capture/video/chromeos/video_capture_device_arc_chromeos.h
@@ -0,0 +1,101 @@
+// Copyright 2017 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_CAPTURE_VIDEO_CHROMEOS_VIDEO_CAPTURE_DEVICE_CHROMEOS_H_
+#define MEDIA_CAPTURE_VIDEO_CHROMEOS_VIDEO_CAPTURE_DEVICE_CHROMEOS_H_
+
+#include <stdint.h>
+
+#include <memory>
+#include <string>
+
+#include "base/macros.h"
+#include "base/threading/thread.h"
+#include "media/capture/video/chromeos/mojo/arc_camera3.mojom.h"
+#include "media/capture/video/video_capture_device.h"
+#include "media/capture/video/video_capture_device_descriptor.h"
+#include "media/capture/video_capture_types.h"
+
+namespace display {
+
+class Display;
+
+}  // namespace display
+
+namespace media {
+
+class CameraHalDelegate;
+class CameraDeviceDelegate;
+
+// Implementation of VideoCaptureDevice for ChromeOS with ARC++ camera HALv3.
+class CAPTURE_EXPORT VideoCaptureDeviceArcChromeOS final
+    : public VideoCaptureDevice {
+ public:
+  // Converts the HAL pixel format |from| to Chromium pixel format.  Returns
+  // PIXEL_FORMAT_UNKNOWN if |from| is not supported.
+  static VideoPixelFormat PixFormatHalToChromium(
+      arc::mojom::HalPixelFormat from);
+
+  // Converts the Chromium pixel format |from| to DRM pixel format.  Returns 0
+  // if |from| is not supported.
+  static uint32_t PixFormatChromiumToDrm(VideoPixelFormat from);
+
+  VideoCaptureDeviceArcChromeOS(
+      scoped_refptr<base::SingleThreadTaskRunner> ui_task_runner,
+      const VideoCaptureDeviceDescriptor& device_descriptor,
+      scoped_refptr<CameraHalDelegate> camera_hal_delegate);
+
+  ~VideoCaptureDeviceArcChromeOS() final;
+
+  // VideoCaptureDevice implementation.
+  void AllocateAndStart(const VideoCaptureParams& params,
+                        std::unique_ptr<Client> client) final;
+  void StopAndDeAllocate() final;
+  void TakePhoto(TakePhotoCallback callback) final;
+  void GetPhotoCapabilities(GetPhotoCapabilitiesCallback callback) final;
+  void SetPhotoOptions(mojom::PhotoSettingsPtr settings,
+                       SetPhotoOptionsCallback callback) final;
+
+ private:
+  const VideoCaptureDeviceDescriptor device_descriptor_;
+
+  // A reference to the CameraHalDelegate instance in the VCD factory.  This is
+  // used by AllocateAndStart to query camera info and create the camera device.
+  const scoped_refptr<CameraHalDelegate> camera_hal_delegate_;
+
+  // A reference to the thread that all the VideoCaptureDevice interface methods
+  // are called.

[chfremer, 2017/05/24 23:36:43]

... are expected to be called on?

[jcliang, 2017/05/25 14:23:47]

Done.

+  const scoped_refptr<base::SingleThreadTaskRunner> capture_task_runner_;
+
+  // The thread that all the Mojo operations of |camera_device_delegate_| take
+  // place.  Started in AllocateAndStart and stopped in StopAndDeAllocate, where
+  // the access to the base::Thread methods are sequenced on
+  // |capture_task_runner_|.
+  base::Thread device_thread_;

[chfremer, 2017/05/24 23:36:43]

At this point, as a reader, I do not understand why we need two separate
threads, |module_thread_| for operating CameraHalDelegate and |device_thread_|
for operating CameraDeviceDelegate. Since the operation should mostly consist of
sending and receiving Mojo messages, I would not expect a lot of congestion, so
why is a single thread for all Mojo communication not sufficient?

[jcliang, 2017/05/25 14:23:47]

I've thought about this. The reason that I keep them two separate threads is
because the CameraDeviceDelegate may need to do some heavy lifting for the
captured frame: in CameraDeviceDelegate::SubmitCaptureResult it calls
client_->OnIncomingCapturedData which does cpu-hogging format conversion and/or
memory copy. The workload gets heavier when we have higher resolution cameras,
and Chrome can open multiple cameras at the same time. Running two (high
resolution) preview streams on the same thread may increase latency
significantly.

[chfremer, 2017/05/25 17:13:07]

Thanks. That sounds reasonable.

+
+  // Internal delegate doing the actual capture setting, buffer allocation and
+  // circulation with the camera HAL. Created on |module_task_runner_| of
+  // |camera_hal_delegate_| in OnOpenedDevice and deleted in StopAndDeAllocate

[chfremer, 2017/05/24 23:36:43]

Isn't this created in AllocateAndStart()?

[jcliang, 2017/05/25 14:23:48]

Done.

+  // on |capture_task_runner_|.  The creation and deletion of
+  // |camera_device_delegate_| is serialized through a WaitableEvent.
+  // All methods of |camera_device_delegate_| operate on |device_thread_|.
+  scoped_refptr<CameraDeviceDelegate> camera_device_delegate_;
+
+  class ScreenObserverDelegate;
+
+  void SetRotation(int rotation);
+  void SetDisplayRotation(const display::Display& display);

[chfremer, 2017/05/24 23:36:43]

Please move class forward declaration and methods above members inside the
private section.

[jcliang, 2017/05/25 14:23:47]

Done.

+
+  scoped_refptr<ScreenObserverDelegate> screen_observer_delegate_;
+  const VideoFacingMode lens_facing_;
+  const int camera_orientation_;
+  // Whether the incoming frames should rotate when the device rotates.
+  const bool rotates_with_device_;
+
+  DISALLOW_IMPLICIT_CONSTRUCTORS(VideoCaptureDeviceArcChromeOS);
+};
+
+}  // namespace media
+
+#endif  // MEDIA_CAPTURE_VIDEO_CHROMEOS_VIDEO_CAPTURE_DEVICE_CHROMEOS_H_