On Windows, only four applications can use DXGI duplication APIs concurrently.
So this change adds a reference counter of DxgiDuplicatorController to unload
DXGI components when the reference counter reaches 0.
BUG=webrtc:7808
Review-Url: https://codereview.webrtc.org/2933893003
Cr-Commit-Position: refs/heads/master@{#18668}
Before 10.12, OSX may report 1X cursor on Retina screen. (See crbug.com/632995.)
After 10.12, OSX may report 2X cursor on non-Retina screen. (See
crbug.com/671436.) So scaling the cursor if the image size doesn't meet the
expected size on either Retina or non-Retina screen.
Also corrects the cursor caching and change detection, so we can only do scalingat cursor changing for better performance.
As to screen capture on OSX, the captured frame already contains the current
cursor. So the MouseCursorMonitorMac is not needed for ScreenCapture for
performance purpose.
BUG=671436
Review-Url: https://codereview.webrtc.org/2908853002
Cr-Commit-Position: refs/heads/master@{#18393}
On Linux, during Windwo sharing, the cursore capture may happen in the parent
window of the target. And the parent window may have some decorations added by
window manager(Chrome windows don't have those decorations.), so the relative
cursor position to the parent window with decorations may differ to its child
target window. The offset includes the height of caption bar and the around
shadow and border.
This problem only happens with Window sharing on Linux.
The fix is to translate the coordinates from the parent window to the coordinates space of the target window.
BUG=723889
Review-Url: https://codereview.webrtc.org/2889063002
Cr-Commit-Position: refs/heads/master@{#18243}
DesktopRect::UnionWith() function has been added by change
https://codereview.webrtc.org/2845213002. This change adds test cases to cover
the newly added logic. More specifically, union between an empty rectangle and a
non-empty one or two empty rectangles.
BUG=webrtc:7541
Review-Url: https://codereview.webrtc.org/2891593003
Cr-Commit-Position: refs/heads/master@{#18201}
This small piece of logic is duplicated in DxgiDuplicatorController,
DxgiAdapterDuplicator and desktop_configuration.mm. Meanwhile, the
implementation in desktop_configuration.mm is not safe. So I think a function in
DesktopRect to cover the requirement could be more efficient and safer.
BUG=webrtc:7541
Review-Url: https://codereview.webrtc.org/2845213002
Cr-Commit-Position: refs/heads/master@{#18171}
Windows may return a DesktopCoordinate out of the first quadrant
(x >= 0 && y >= 0), this typically happens when the primary and secondary
monitors are swapped. i.e. The secondary monitor is on the left but the primary
one is on the right.
This change "moves" the entire screen from any quadrant to the (0, 0), so we can
capture the monitors in other quadrants.
BUG=chromium:715689
Review-Url: https://codereview.webrtc.org/2848443004
Cr-Original-Commit-Position: refs/heads/master@{#17935}
Committed: 049ec71e65
Review-Url: https://codereview.webrtc.org/2848443004
Cr-Commit-Position: refs/heads/master@{#17938}
Reason for revert:
TranslateRect() is placed in a wrong position.
Original issue's description:
> Allow Windows to return a monitor out of the first quadrant
>
> Windows may return a DesktopCoordinate out of the first quadrant
> (x >= 0 && y >= 0), this typically happens when the primary and secondary
> monitors are swapped. i.e. The secondary monitor is on the left but the primary
> one is on the right.
> This change "moves" the entire screen from any quadrant to the (0, 0), so we can
> capture the monitors in other quadrants.
>
> BUG=chromium:715689
>
> Review-Url: https://codereview.webrtc.org/2848443004
> Cr-Commit-Position: refs/heads/master@{#17935}
> Committed: 049ec71e65TBR=sergeyu@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:715689
Review-Url: https://codereview.webrtc.org/2852783002
Cr-Commit-Position: refs/heads/master@{#17936}
Windows may return a DesktopCoordinate out of the first quadrant
(x >= 0 && y >= 0), this typically happens when the primary and secondary
monitors are swapped. i.e. The secondary monitor is on the left but the primary
one is on the right.
This change "moves" the entire screen from any quadrant to the (0, 0), so we can
capture the monitors in other quadrants.
BUG=chromium:715689
Review-Url: https://codereview.webrtc.org/2848443004
Cr-Commit-Position: refs/heads/master@{#17935}
This is a trivial change to forward capturer id from various DesktopFrame
related implementations.
BUG=chromium:679523, chromium:650926
Review-Url: https://codereview.webrtc.org/2851513003
Cr-Commit-Position: refs/heads/master@{#17918}
Make all rtc_source_test target that contains tests that
are included in a test executable only be visible to the
rtc_test target. Doing this exposed a couple of errors and
dependency problems that were resolved. Having this could
have prevented duplicated execution of tests like the case that
was recently fixed by deadbeef@ in
https://codereview.webrtc.org/2820263004
New targets:
* //webrtc/modules/rtp_rtcp:fec_test_helper
* //webrtc/modules/rtp_rtcp:mock_rtp_rtcp
* //webrtc/modules/remote_bitrate_estimator:mock_remote_bitrate_observer
The mock files and targets should probably be moved into webrtc/test in
the future, but that's out of the scope of this CL.
BUG=webrtc:5716
NOTRY=True
Review-Url: https://codereview.webrtc.org/2828793003
Cr-Commit-Position: refs/heads/master@{#17863}
Once the buffer returned by Windows is not newly allocated, it may contain
legacy images from previous capturing attempts. This usually is not a problem,
as implementations other than ScreenCapturerWinDirectx paint each pixel on the
frame. But due to the one capturer per monitor design of
ScreenCapturerWinDirectx, part of the frame may not be covered by any
DxgiOutputDuplicator, and cause the legacy image to be shown.
So a very simple fix is to clear the DesktopFrame in DxgiFrame.
BUG=708766
Review-Url: https://codereview.webrtc.org/2827983007
Cr-Commit-Position: refs/heads/master@{#17847}
obvious, WindowCapturerWin should not return Result::SUCCESS with an empty
frame.
This issue was original introduced into the code base in change
https://codereview.webrtc.org/1988783003/.
I am also considering whether we should move the
previous_size_ = frame->size();
window_size_map_[window_] = previous_size_;
into the true branch. But since this change needs to be merged into M58 and M59,
I would prefer to keep it as small as possible.
BUG=712615
Review-Url: https://codereview.webrtc.org/2835553002
Cr-Commit-Position: refs/heads/master@{#17799}
The key change of this CL is to merge ScreenCapturerWinDirectx::frames_ and
contexts_ into a new DxgiFrame class. So consumers of DxgiDuplicateController
does not need to maintain two objects. DxgiDuplicateController::Duplicate*()
functions are also updated to accept DxgiFrame parameter instead of
SharedDesktopFrame + Context. The advantages of this change are,
1. Once the screen resolution changes or an existing monitor has been removed,
DxgiFrame can automatically reset the frame without needing to return a capture
failure.
2. Remove public APIs of DxgiDuplicatorController. Some public APIs are not
needed anymore, i.e. consumers of DxgiDuplicatorController do not need to take
care about these internal states anymore. It also helps to remove several lock
acquiements.
3. Reduce the complexity of ScreenCapturerWinDirectx.
But the disadvantage is, instead of a boolean value,
DxgiDuplicateController::Duplicate*() now return an enumeration. Clients need to
use the enumeration to decide whether the error can be recovered or not.
This change also removes a duplicating logic in ScreenCapturerWinDirectx. i.e.
ResolutionChangeDetector, DxgiDuplicateController now takes care of the screen
resolution changes.
I have verified the scenarios with and without SharedMemoryFactory, also the
Desktop capture API example. So far no regression is detected.
BUG=704205
Review-Url: https://codereview.webrtc.org/2788863006
Cr-Commit-Position: refs/heads/master@{#17795}
The root cause is because the offset used in DxgiOutputDuplicator should always
depend on the position of the monitor in the system instead of the offset in the
target frame. Otherwise, once switching between two monitors with different
screen size, the updated region in the context would base on the old monitor,
and cause the copied regions to be out of the source DesktopFrame.
This issue also impacts the SpreadContextChange() function, the updated region
stores in the Context should also only depend on the position of the monitor.
BUG=chromium:706797
Review-Url: https://codereview.webrtc.org/2801433002
Cr-Commit-Position: refs/heads/master@{#17548}
XServerPixelBuffer contains x_image_ field, that may be allocated using
XGetImage() or XShmCreateImage() depending how the last frame was captured.
x_image_ is passed XShmGetImage(), which may crash if it gets image
allocated with XGetImage(). Added x_shm_image_ to ensure that SHM and
non-SHM capture paths are separate and XShmGetImage() is allways called
with the correct XImage.
The linked bug appears to be a regressiona after
https://codereview.webrtc.org/2044693002
BUG=chromium:697823
Review-Url: https://codereview.webrtc.org/2796673002
Cr-Commit-Position: refs/heads/master@{#17518}
capturer_id() field has not been forward to the shared DesktopFrame.
BUG=650926, 679523
Review-Url: https://codereview.webrtc.org/2796583002
Cr-Commit-Position: refs/heads/master@{#17516}
I have verified this change on my laptop, which cannot reproduce the issue anymore.
BUG=704205
Review-Url: https://codereview.webrtc.org/2781253002
Cr-Commit-Position: refs/heads/master@{#17494}
Once the first capture attempt failed, we should keep the
context->updated_region unchanged for next attempt. This change can (partially?)
fix issue 704205.
BUG=704205
Review-Url: https://codereview.webrtc.org/2780093002
Cr-Commit-Position: refs/heads/master@{#17456}
When screen/window capturers fail to use shared memory, they are
supposed to fall back to XGetImage(). It's slower, but should still
allow to capture desktop content. This wasn't implemented correclty in
XScreenPixelBuffer - it was failing completely when shmget() returns an
error.
BUG=705146
Review-Url: https://codereview.webrtc.org/2775793003
Cr-Commit-Position: refs/heads/master@{#17401}
constexpr function should be preferred than a macro. So this change replaces
FOURCC() macro with a constexpr uint32_t FourCC() function.
BUG=679523, 650926
Review-Url: https://codereview.webrtc.org/2771573002
Cr-Commit-Position: refs/heads/master@{#17351}
This change adds a DesktopCapturerId namespace, and attaches an int to each
DesktopFrame. ScreenCapturerWinGdi and ScreenCapturerWinDirectx now actively set
this field to differentiate themselves.
BUG=679523, 650926
Review-Url: https://codereview.webrtc.org/2759493002
Cr-Original-Commit-Position: refs/heads/master@{#17329}
Committed: 41e3d9ff3b
Review-Url: https://codereview.webrtc.org/2759493002
Cr-Commit-Position: refs/heads/master@{#17347}
Reason for revert:
I suspect that this CL breaks Chromium WebRTC FYI bots. (Thanks kjellander@ for spotting.) The added dep in BUILD.gn would be the problem.
Example:
https://luci-logdog.appspot.com/v/?s=chromium%2Fbb%2Fchromium.webrtc.fyi%2FLinux_Builder%2F15058%2F%2B%2Frecipes%2Fsteps%2Fcompile%2F0%2Fstdout
FAILED: newlib_pnacl/obj/third_party/webrtc/api/libjingle_peerconnection_api/mediaconstraintsinterface.o
/b/c/goma_client/gomacc ../../native_client/toolchain/linux_x86/pnacl_newlib/bin/pnacl-clang++ -MMD -MF newlib_pnacl/obj/third_party/webrtc/api/libjingle_peerconnection_api/mediaconstraintsinterface.o.d -DNACL_TC_REV=5dfe030a71ca66e72c5719ef5034c2ed24706c43 -DV8_DEPRECATION_WARNINGS -DUSE_OPENSSL_CERTS=1 -DNO_TCMALLOC -DFULL_SAFE_BROWSING -DSAFE_BROWSING_CSD -DSAFE_BROWSING_DB_LOCAL -DCHROMIUM_BUILD -DENABLE_MEDIA_ROUTER=1 -DFIELDTRIAL_TESTING_ENABLED -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D_FORTIFY_SOURCE=2 -DNDEBUG -DNVALGRIND -DWEBRTC_RESTRICT_LOGGING -DEXPAT_RELATIVE_PATH -DHAVE_SCTP -DENABLE_EXTERNAL_AUTH -DHAVE_WEBRTC_VIDEO -DHAVE_WEBRTC_VOICE -DLOGGING_INSIDE_WEBRTC -DUSE_WEBRTC_DEV_BRANCH -DFEATURE_ENABLE_VOICEMAIL -DEXPAT_RELATIVE_PATH -DGTEST_RELATIVE_PATH -DNO_MAIN_THREAD_WRAPPING -DNO_SOUND_SYSTEM -DWEBRTC_CHROMIUM_BUILD -DWEBRTC_POSIX -I../.. -Inewlib_pnacl/gen -I../../third_party/webrtc_overrides -I../../third_party -fno-strict-aliasing -Wno-builtin-macro-redefined -D__DATE__= -D__TIME__= -D__TIMESTAMP__= -fcolor-diagnostics -Wall -Werror -Wextra -Wno-missing-field-initializers -Wno-unused-parameter -Wno-c++11-narrowing -Wno-covered-switch-default -Wno-deprecated-register -Wno-unneeded-internal-declaration -Wno-inconsistent-missing-override -O2 -fno-ident -fdata-sections -ffunction-sections -g0 -fvisibility=hidden -fvisibility-inlines-hidden -std=gnu++11 -fno-rtti -fno-exceptions -c ../../third_party/webrtc/api/mediaconstraintsinterface.cc -o newlib_pnacl/obj/third_party/webrtc/api/libjingle_peerconnection_api/mediaconstraintsinterface.o
In file included from ../../third_party/webrtc/api/mediaconstraintsinterface.cc:11:
In file included from ../../third_party/webrtc/api/mediaconstraintsinterface.h:27:
In file included from ../../third_party/webrtc/api/peerconnectioninterface.h:77:
In file included from ../../third_party/webrtc/api/dtmfsenderinterface.h:16:
In file included from ../../third_party/webrtc/api/mediastreaminterface.h:33:
In file included from ../../third_party/webrtc/media/base/mediachannel.h:28:
../../third_party/webrtc/base/socket.h:18:10: fatal error: 'sys/socket.h' file not found
#include <sys/socket.h>
^
1 error generated.
Original issue's description:
> Add DesktopCapturerId and attach it to DesktopFrame
>
> This change adds a DesktopCapturerId namespace, and attaches an int to each
> DesktopFrame. ScreenCapturerWinGdi and ScreenCapturerWinDirectx now actively set
> this field to differentiate themselves.
>
> BUG=679523, 650926
>
> Review-Url: https://codereview.webrtc.org/2759493002
> Cr-Commit-Position: refs/heads/master@{#17329}
> Committed: 41e3d9ff3bTBR=sergeyu@chromium.org,zijiehe@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=679523, 650926
Review-Url: https://codereview.webrtc.org/2767003002
Cr-Commit-Position: refs/heads/master@{#17336}
This change adds a DesktopCapturerId namespace, and attaches an int to each
DesktopFrame. ScreenCapturerWinGdi and ScreenCapturerWinDirectx now actively set
this field to differentiate themselves.
BUG=679523, 650926
Review-Url: https://codereview.webrtc.org/2759493002
Cr-Commit-Position: refs/heads/master@{#17329}
CreateRawScreenCapturer() and CreateRawWindowCapturer() in
DesktopCapturer are allowed to return nullptr when capturer cannot be
initialized for some reason. CreateWindowCapturer() and
CreateScreenCapturer() in DesktopCapturer were not handling this case
correctly, which may lead to crash.
BUG=chromium:702745
Review-Url: https://codereview.webrtc.org/2754403002
Cr-Commit-Position: refs/heads/master@{#17298}
I cannot even imagine this change is useful. But it consistently reduces average
capture time by 0.375% (4.07 -> 4.055), and average encode time by 0.313%
(8.042 -> 8.016) without other impacts. Considering this is a one-line change,
it's worthy to be added.
BUG=679523
Review-Url: https://codereview.webrtc.org/2743233002
Cr-Commit-Position: refs/heads/master@{#17235}
Previously we grab a run loop source and add a source with mode
kCFRunLoopDefaultMode. With this mode, it won't callback when context menu popup
(which needs the NSEventTrackingRunLoopMode), then screen capture can't get
refreshed frame with context menu until the context menu is gone.
The fix is to use kCFRunLoopComonModes, which includes default,modal and event
tracking modes by default.
BUG=chromium:697780
Review-Url: https://codereview.webrtc.org/2732393003
Cr-Commit-Position: refs/heads/master@{#17171}
DisplayStream refresh rects are in display coordinates. When the whole screen is
being captured, the coordinates passed to the ScreenCapturerHelper need to be in
screen coordinates. This CL translates display coordinates to screen
coordinates for whole screen capture.
BUG=chromium:699672
Review-Url: https://codereview.webrtc.org/2740823002
Cr-Commit-Position: refs/heads/master@{#17153}
Previusly errors from XServerPixelBuffer::CaptureRect() were not always
handled, which results in a black frame returned from the capturer
instead of an error.
BUG=webrtc:7305
Review-Url: https://codereview.webrtc.org/2738513005
Cr-Commit-Position: refs/heads/master@{#17101}
DXGI capturer highly depends on video adapter and its driver, as well as Windows
itself. I recently found it cannot work on my virtualbox instance any more,
which indicates it may not work well on some specific systems. What worse is,
the APIs do not return a failure in such case.
So this change adds a BlankDetectorDesktopCapturerWrapper, which samples several
pixels in the frame returned by a DesktopCapturer implementation. If all the
pixels selected are blank, this wrapper returns a failure. A typical usage is to
combine BlankDetectorDesktopCapturerWrapper with FallbackDesktopCapturerWrapper,
and use GDI capturer in case of failure.
Usually less than 10000 pixels are checked, so the
BlankDetectorDesktopCapturerWrapper should not significant impact the capturer
performance.
This change is expected to resolve bug 682112 in another dimension.
BUG=682112
Review-Url: https://codereview.webrtc.org/2709523003
Cr-Original-Commit-Position: refs/heads/master@{#16984}
Committed: c4e9d210b3
Review-Url: https://codereview.webrtc.org/2709523003
Cr-Commit-Position: refs/heads/master@{#17024}
Reason for revert:
Misses deps for RTC_HISTOGRAM in Chrome.
email sent separately.
Also see https://codereview.chromium.org/2725143004/.
Original issue's description:
> BlankDetectorDesktopCapturerWrapper to detect a blank DesktopFrame
>
> DXGI capturer highly depends on video adapter and its driver, as well as Windows
> itself. I recently found it cannot work on my virtualbox instance any more,
> which indicates it may not work well on some specific systems. What worse is,
> the APIs do not return a failure in such case.
>
> So this change adds a BlankDetectorDesktopCapturerWrapper, which samples several
> pixels in the frame returned by a DesktopCapturer implementation. If all the
> pixels selected are blank, this wrapper returns a failure. A typical usage is to
> combine BlankDetectorDesktopCapturerWrapper with FallbackDesktopCapturerWrapper,
> and use GDI capturer in case of failure.
>
> Usually less than 500 pixels are checked, so the
> BlankDetectorDesktopCapturerWrapper should not impact the capturer performance.
>
> This change is expected to resolve bug 682112 in another dimension.
>
> BUG=682112
>
> Review-Url: https://codereview.webrtc.org/2709523003
> Cr-Commit-Position: refs/heads/master@{#16984}
> Committed: c4e9d210b3TBR=sergeyu@chromium.org,zijiehe@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=682112
Review-Url: https://codereview.webrtc.org/2726983005
Cr-Commit-Position: refs/heads/master@{#16993}
DXGI capturer highly depends on video adapter and its driver, as well as Windows
itself. I recently found it cannot work on my virtualbox instance any more,
which indicates it may not work well on some specific systems. What worse is,
the APIs do not return a failure in such case.
So this change adds a BlankDetectorDesktopCapturerWrapper, which samples several
pixels in the frame returned by a DesktopCapturer implementation. If all the
pixels selected are blank, this wrapper returns a failure. A typical usage is to
combine BlankDetectorDesktopCapturerWrapper with FallbackDesktopCapturerWrapper,
and use GDI capturer in case of failure.
Usually less than 500 pixels are checked, so the
BlankDetectorDesktopCapturerWrapper should not impact the capturer performance.
This change is expected to resolve bug 682112 in another dimension.
BUG=682112
Review-Url: https://codereview.webrtc.org/2709523003
Cr-Commit-Position: refs/heads/master@{#16984}
A bug has been reported to complaint the ScreenCapturerWinDirectx cannot capture
the first frame, which is used in "Report an issue" page.
A simple solution here is to skip the first frame.
This change also removes the friend relationship between
DxgiDuplicatorController / DxgiAdapterDuplicator / DxgiOutputDuplicator, which
is not really necessary.
BUG=682112
Review-Url: https://codereview.webrtc.org/2703123002
Cr-Commit-Position: refs/heads/master@{#16815}
This is a trivial change to remove duplicate logic, i.e. fallback capturer, from
ScreenCapturerWinMagnifier.
BUG=webrtc:7215
Review-Url: https://codereview.webrtc.org/2704943002
Cr-Commit-Position: refs/heads/master@{#16781}
Update the year in copyright headers from 2016 to 2017, and also rename a
variable in FallbackDesktopCapturerWrapperTest to follow coding style.
BUG=webrtc:7205
Review-Url: https://codereview.webrtc.org/2706193005
Cr-Commit-Position: refs/heads/master@{#16759}
FallbackDesktopCapturerWrapper is a DesktopCapturer implementation, which owns
two DesktopCapturer implementations. If the main DesktopCapturer fails, it uses
the secondary capturer. The logic is now used in ScreenCapturerWinMagnifier, and
it can also be shared in ScreenCapturerWinDirectx to fallback to Gdi capturer on
privilege prompt or login screen.
BUG=684937
Review-Url: https://codereview.webrtc.org/2697453002
Cr-Commit-Position: refs/heads/master@{#16677}
This change adds a ResolutionChangeDetector to help dxgi components, say
DxgiDuplicatorController and DxgiTexture to detect resolution changes.
BUG=684162
Review-Url: https://codereview.webrtc.org/2682913002
Cr-Commit-Position: refs/heads/master@{#16654}
The tests need "x11/shared_x_display.h" which is not included when use_x11 is false and we're on linux.
The problem is:
screen_capturer_integration_test.cc
- requires ->
screen_drawer.h
- requires ->
screen_drawer_linux.cc
- requires ->
x11/shared_x_display.h
which is not included when use_x11 is false.
BUG=None
NOTRY=True
Review-Url: https://codereview.webrtc.org/2684683003
Cr-Commit-Position: refs/heads/master@{#16529}
