Sharing virtual desktop applications may not be captured
Reported by
skadb...@cyviz.com,
Dec 19 2017
|
||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0 Steps to reproduce the problem: 1. Using chrome.desktopCapture.chooseDesktopMedia, open the application sharing dialog. 2. Using window "Task View", a virtual desktop feature in Windows 10, change to a secondary virtual desktop. 3. Open an application, intended to be shared. 4. Change back to primary virtual desktop. 5. Select the application to share. What is the expected behavior? The application is shared. What went wrong? The application is only shared if another window in the primary virtual desktop occupies the same actual screen area as the application on the secondary virtual desktop. Otherwise the video displays a black or corrupted image at the resolution of the shared application. Did this work before? N/A Does this work in other browsers? N/A Chrome version: Version 63.0.3239.108 (Official Build) (64-bit) Channel: stable OS Version: 10.0 Flash Version: N/A May be related to https://bugs.chromium.org/p/chromium/issues/detail?id=796078
,
Dec 21 2017
@Inhouse: Could some one from TE-Hyd team have a look into this issue which is related to virtual desktop, hence adding label TE-NeedsTriageFromHYD, for further investigation. Thanks!
,
Jan 3 2018
Adding braveyao@ for more updates on this issue.
,
Jan 4 2018
I can reproduce this issue. It seems that when the virtual desktop on which the shared window residents is not on screen, the shared window is still enumerated as on top. So we will crop from the current screen capture and get a wrong result. We need to find a way to detect whether the target desktop is on screen. And the expected result should be: When the target desktop is not shown, the target window should be marked as not-on-top. If it's support BitBlt/printWindow, its content is still able to be captured. If it doesn't support BitBlt/printWindow, black frame will be captured.
,
Jan 5 2018
When a video source is unavailable, such as a minimized window, there is currently a consistent way of detecting no signal. In that case, the video stream remains flagged as active while the resolution changes to 0x0px. This allows me to actively notify the user of potential video issues, instead of assuming that the user continuously monitors the outgoing video preview. It would be great if same or similar technique could be applied in the suggested solution, instead of attempting to detect black frames.
,
Jan 19 2018
,
Apr 12 2018
The following revision refers to this bug: https://webrtc.googlesource.com/src.git/+/8944f6a3f5f301a9fe400b22dfcd72d548c78558 commit 8944f6a3f5f301a9fe400b22dfcd72d548c78558 Author: braveyao <braveyao@webrtc.org> Date: Thu Apr 12 19:22:15 2018 [desktopCaptuer Win] exclude windows not on current virtual desktop Since Windows 10, Windows starts to support virtual desktops. The problem is when one virtual desktop is not the current one, we can still enumerate the windows on it, which are still marked as visible by OS. This causes troubles to decide if a window is on top to be cropped out. This cl is to utilize a COM API, IsWindowOnCurrentVirtualDesktop of VirtualDesktopManager, to make sure only the windows on current desktop will be enumerated. Bug: chromium:796112 Change-Id: I6e0546e90fbdb37365a8d98694ded0e30791628e Reviewed-on: https://webrtc-review.googlesource.com/65882 Reviewed-by: Jamie Walch <jamiewalch@chromium.org> Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org> Commit-Queue: Brave Yao <braveyao@webrtc.org> Cr-Commit-Position: refs/heads/master@{#22842} [modify] https://crrev.com/8944f6a3f5f301a9fe400b22dfcd72d548c78558/modules/desktop_capture/cropping_window_capturer_win.cc [modify] https://crrev.com/8944f6a3f5f301a9fe400b22dfcd72d548c78558/modules/desktop_capture/win/window_capture_utils.cc [modify] https://crrev.com/8944f6a3f5f301a9fe400b22dfcd72d548c78558/modules/desktop_capture/win/window_capture_utils.h [modify] https://crrev.com/8944f6a3f5f301a9fe400b22dfcd72d548c78558/modules/desktop_capture/window_capturer_win.cc [modify] https://crrev.com/8944f6a3f5f301a9fe400b22dfcd72d548c78558/rtc_base/win32.h
,
Apr 13 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/c42eb293fc9fab232250d9550fc37f0677ede892 commit c42eb293fc9fab232250d9550fc37f0677ede892 Author: webrtc-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com <webrtc-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com> Date: Fri Apr 13 23:06:02 2018 Roll src/third_party/webrtc/ 3ef3bfc2a..3acffc3b1 (52 commits) https://webrtc.googlesource.com/src.git/+log/3ef3bfc2aafa..3acffc3b1668 $ git log 3ef3bfc2a..3acffc3b1 --date=short --no-merges --format='%ad %ae %s' Created with: roll-dep src/third_party/webrtc BUG= chromium:811683 ,chromium:None,chromium:831093,chromium:None,chromium:None,chromium:b/77825904,chromium:None,chromium:None,chromium:None,chromium:831996,chromium:None,chromium:796112,chromium:None,chromium:None,chromium:None,chromium:None,chromium:None,chromium:None,chromium:None,chromium:None,chromium:None,chromium:None,chromium:None,chromium:827917 The AutoRoll server is located here: https://webrtc-chromium-roll.skia.org Documentation for the AutoRoller is here: https://skia.googlesource.com/buildbot/+/master/autoroll/README.md If the roll is causing failures, please contact the current sheriff, who should be CC'd on the roll, and stop the roller if necessary. CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_archive_rel_ng;master.tryserver.chromium.mac:mac_chromium_archive_rel_ng;master.tryserver.chromium.win:win-msvc-dbg TBR=webrtc-chromium-sheriffs-robots@google.com Change-Id: Ib12df502703e5c0d6c0d1dcb935f69f0166fa0be Reviewed-on: https://chromium-review.googlesource.com/1012762 Commit-Queue: webrtc-chromium-autoroll <webrtc-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com> Reviewed-by: webrtc-chromium-autoroll <webrtc-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#550776} [modify] https://crrev.com/c42eb293fc9fab232250d9550fc37f0677ede892/DEPS
,
Apr 17 2018
Verified with Canary 68.3397.
,
Apr 17 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/c42eb293fc9fab232250d9550fc37f0677ede892 commit c42eb293fc9fab232250d9550fc37f0677ede892 Author: webrtc-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com <webrtc-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com> Date: Fri Apr 13 23:06:02 2018 Roll src/third_party/webrtc/ 3ef3bfc2a..3acffc3b1 (52 commits) https://webrtc.googlesource.com/src.git/+log/3ef3bfc2aafa..3acffc3b1668 $ git log 3ef3bfc2a..3acffc3b1 --date=short --no-merges --format='%ad %ae %s' Created with: roll-dep src/third_party/webrtc BUG= chromium:811683 ,chromium:None,chromium:831093,chromium:None,chromium:None,chromium:b/77825904,chromium:None,chromium:None,chromium:None,chromium:831996,chromium:None,chromium:796112,chromium:None,chromium:None,chromium:None,chromium:None,chromium:None,chromium:None,chromium:None,chromium:None,chromium:None,chromium:None,chromium:None,chromium:827917 The AutoRoll server is located here: https://webrtc-chromium-roll.skia.org Documentation for the AutoRoller is here: https://skia.googlesource.com/buildbot/+/master/autoroll/README.md If the roll is causing failures, please contact the current sheriff, who should be CC'd on the roll, and stop the roller if necessary. CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_archive_rel_ng;master.tryserver.chromium.mac:mac_chromium_archive_rel_ng;master.tryserver.chromium.win:win-msvc-dbg TBR=webrtc-chromium-sheriffs-robots@google.com Change-Id: Ib12df502703e5c0d6c0d1dcb935f69f0166fa0be Reviewed-on: https://chromium-review.googlesource.com/1012762 Commit-Queue: webrtc-chromium-autoroll <webrtc-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com> Reviewed-by: webrtc-chromium-autoroll <webrtc-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#550776} [modify] https://crrev.com/c42eb293fc9fab232250d9550fc37f0677ede892/DEPS
,
Jun 7 2018
[bulk-edit: disregard if N/A] Can the owner please set milestone to this bug if applicable?
,
Jun 7 2018
|
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by guidou@chromium.org
, Dec 19 2017