GitLab

Per https://crbug.com/1116241, always instantiating and adding the
AVCaptureStillImageOutput to the capture session does, in some cases,
result in high CPU load due to the macOS process VTDecoderXPCService
converting pixel formats and producing MJPEG. But this work is only
needed if the ImageCapture.takePhoto() API is invoked, which most
MediaStreamTrack-using web pages never use.

This CL lazily instantiates _stillImageOutput when takePhoto() is
called and keeps it alive until 60 seconds of time has passed without
another takePhoto() call. We keep it alive like this because
instantiation involves noticeable delays that is avoided if takePhoto()
is called after instantiation.

The delays are due to two reasons:
1. Delays inherent to instantiating AVCaptureStillImageOutput.
2. This CL introduces a async delay of 3 seconds after instantiation.
   If we don't wait before taking the photo, the 3A has not stabilized
   and the photo is too dark.
Because performance is critical to the success of WebRTC applications,
the pros are believed to outweigh the cons.

To achieve its goal, this CL:
- Makes it possible to mock the frame receiver.
- Adds helper utils.
- Adds video_capture_device_avfoundation_mac_unittest.mm.
- Replaces a thread checker with a task runner to allow posting tasks.
- Introduces MOCK_TIME in the tests.

Bug: chromium:1124652, chromium:1116241
Change-Id: I91ebcb45d44fda3fcdb613b8907a10dfa89a9615
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2388100Reviewed-by: Guido Urdaneta <guidou@chromium.org>
Reviewed-by: Markus Handell <handellm@google.com>
Reviewed-by: ccameron <ccameron@chromium.org>
Commit-Queue: Henrik Boström <hbos@chromium.org>
Cr-Commit-Position: refs/heads/master@{#806083}