[macOS Capture] Lazily instantiate takePhoto()'s _stillImageOutput.
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}
Showing
This diff is collapsed.
Please register or sign in to comment