Screen capture devices should suspend while there are no consumers |
|||
Issue descriptionScreen capture (e.g., tab capture) is a very resource-intensive feature. Thus, when applications/extensions wish to leave a MediaStream in an opened state, but are not ready to consume video frames, the browser should suspend GPU readback and other resource-intensive operations. Since the screen capture implementations share infrastructure with other video capture devices, it makes sense to create an interface for notifying any media::VideoCaptureDevice that wishes to optimize by "turning down to an idle state" in these situations.
,
Sep 29 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a84c86dcab6fda82917b411bf0e47a9d5c2f5ee2 commit a84c86dcab6fda82917b411bf0e47a9d5c2f5ee2 Author: miu <miu@chromium.org> Date: Thu Sep 29 06:42:20 2016 Screen Video Capture: Implement suspend optimization. Implements frame delivery suspend/resume functionality in tab capture, Aura window/desktop capture, and Android screen capture. This allows the screen capture devices to minimize resource utilization while there are no consumers of the video frames attached downstream. Prerequisite change: https://codereview.chromium.org/2365223002/ BUG= 650113 Review-Url: https://codereview.chromium.org/2364413002 Cr-Commit-Position: refs/heads/master@{#421763} [modify] https://crrev.com/a84c86dcab6fda82917b411bf0e47a9d5c2f5ee2/chrome/test/data/extensions/api_test/tab_capture/end_to_end.js [modify] https://crrev.com/a84c86dcab6fda82917b411bf0e47a9d5c2f5ee2/content/browser/media/capture/aura_window_capture_machine.cc [modify] https://crrev.com/a84c86dcab6fda82917b411bf0e47a9d5c2f5ee2/content/browser/media/capture/aura_window_capture_machine.h [modify] https://crrev.com/a84c86dcab6fda82917b411bf0e47a9d5c2f5ee2/content/browser/media/capture/web_contents_video_capture_device.cc [modify] https://crrev.com/a84c86dcab6fda82917b411bf0e47a9d5c2f5ee2/content/browser/media/capture/web_contents_video_capture_device.h [modify] https://crrev.com/a84c86dcab6fda82917b411bf0e47a9d5c2f5ee2/content/browser/media/capture/web_contents_video_capture_device_unittest.cc [modify] https://crrev.com/a84c86dcab6fda82917b411bf0e47a9d5c2f5ee2/media/capture/content/screen_capture_device_core.cc [modify] https://crrev.com/a84c86dcab6fda82917b411bf0e47a9d5c2f5ee2/media/capture/content/screen_capture_device_core.h
,
Sep 29 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/25f8a1a991cb03ab2c386f25603b9bb468cde68c commit 25f8a1a991cb03ab2c386f25603b9bb468cde68c Author: mcasas <mcasas@chromium.org> Date: Thu Sep 29 15:23:39 2016 VideoCaptureImpl cleanup: merge ctor+Init() and DeInit()+dtor. VideoCaptureImpl::ctor and Init() are always called in sequence, and so are DeInit() and the destructor. This CL just bundles them. Some strange comments about threading are made irrelevant. This CL follows up on some comments in https://crrev.com/2365223002/ TEST= ./out/gn/content_unittests --gtest_filter=VideoCaptureImpl* and video capture WAI using any demo BUG= 650113 Review-Url: https://codereview.chromium.org/2377163002 Cr-Commit-Position: refs/heads/master@{#421824} [modify] https://crrev.com/25f8a1a991cb03ab2c386f25603b9bb468cde68c/content/renderer/media/video_capture_impl.cc [modify] https://crrev.com/25f8a1a991cb03ab2c386f25603b9bb468cde68c/content/renderer/media/video_capture_impl.h [modify] https://crrev.com/25f8a1a991cb03ab2c386f25603b9bb468cde68c/content/renderer/media/video_capture_impl_manager.cc [modify] https://crrev.com/25f8a1a991cb03ab2c386f25603b9bb468cde68c/content/renderer/media/video_capture_impl_manager_unittest.cc [modify] https://crrev.com/25f8a1a991cb03ab2c386f25603b9bb468cde68c/content/renderer/media/video_capture_impl_unittest.cc
,
Sep 29 2016
,
Feb 14 2017
,
Feb 15 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/7239bff66dcb73541208ba0924470f5e74dad72a commit 7239bff66dcb73541208ba0924470f5e74dad72a Author: miu <miu@chromium.org> Date: Wed Feb 15 05:57:18 2017 Tab/Desktop capture: Fix for super-old frame after resume. After a Resume() operation, set a flag that will force the next frame refresh operation to be of the "active" kind (i.e., actually execute a capture of the current screen) rather than the "passive" kind (i.e., pull the last frame back out of the buffer pool). This will ensure that, since the screen may have changed during the Suspend(), the next frame emitted contains the most up-to-date content. BUG= 692261 , 650113 Review-Url: https://codereview.chromium.org/2692393002 Cr-Commit-Position: refs/heads/master@{#450575} [modify] https://crrev.com/7239bff66dcb73541208ba0924470f5e74dad72a/media/capture/content/screen_capture_device_core.cc [modify] https://crrev.com/7239bff66dcb73541208ba0924470f5e74dad72a/media/capture/content/screen_capture_device_core.h |
|||
►
Sign in to add a comment |
|||
Comment 1 by bugdroid1@chromium.org
, Sep 29 2016