This is a follow up to
https://webrtc-review.googlesource.com/c/src/+/200161
I forgot to actually upload the code that addressed reviewer's comments,
and since they were minor comments I went ahead and completed the CL
before I realized.
Fortunately no harm done because all of this code is behind a disabled
build flag. This is a great example of move fast, make mistakes. Lesson
learned.
Bug: webrtc:9273
Change-Id: I5e35b31719b264855568de4b5e595fe0f192654e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/204420
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Austin Orion <auorion@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#33095}
This change refactors WgcWindowCapturer into WgcCapturerWin, a source
agnostic capturer, and finishes the implementation to enable both window
and screen capture.
This CL depends on another which must complete first:
196622: Add ability to load CreateDirect3DDeviceFromDXGIDevice from
d3d11.dll | https://webrtc-review.googlesource.com/c/src/+/196622
This feature remains off by default behind a build flag, due to it
adding a depency on the Win10 SDK vv10.0.19041 which not all consumers
of WebRTC have upgraded to. A follow up change later will enable the
rtc_enable_win_wgc build flag, but for now it should remain off.
The basic operation of this class is as follows:
Consumers call either WgcCapturerWin::CreateRawWindowCapturer or
CreateRawScreenCapturer to receive a correctly initialized
WgcCapturerWin object suitable for the desired source type.
Callers then indicate via SelectSource and a SourceId the desired
capture target, and the capturer creates an appropriate WgcCaptureSource
for the correct type (window or screen) using the
WgcCaptureSourceFactory supplied at construction.
Next, callers request frames for the currently selected source and the
capturer then creates a WgcCaptureSession and stores it in a map for
more efficient capture of multiple sources.
The WgcCaptureSession is supplied with a GraphicsCaptureItem created by
the WgcCaptureSource. It uses this item to create a
Direct3D11CaptureFramePool and create and start a
GraphicsCaptureSession.
Once started, captured frames will begin to be deposited into the
FramePool. Typically, one would listen for the FrameArrived event and
process the frame then, but due to the synchronous nature of the
DesktopCapturer interface, and to avoid a more complicated multi-
threaded architecture we ignore the FrameArrived event. Instead, we
wait for a request for a frame from the caller, then we check the
FramePool for a frame, and process it on demand.
Processing a frame involves moving the image data from an
ID3D11Texture2D stored in the GPU into a texture that is accessible
from the CPU, and then copying the data into the new WgcDesktopFrame
class. This copy is necessary as otherwise we would need to manage the
lifetimes of the CaptureFrame and ID3D11Texture2D objects, lest the
buffer be invalidated.
Once we've copied the data and returned it to the caller, we can unmap
the texture and exit the scope of the GetFrame method, which will
destruct the CaptureFrame object. At this point, the CaptureSession
will begin capturing a new frame, and will soon deposit it into the
FramePool and we can repeat.
Bug: webrtc:9273
Change-Id: I02263c4fd587df652b04d5267fad8965330d0f5b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/200161
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Reviewed-by: Guido Urdaneta <guidou@webrtc.org>
Commit-Queue: Austin Orion <auorion@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#33083}
This change moves several functions used to create test windows from
WindowCaptureUtilsTest into a reusable file test_window.cc. This is so
we can reuse this code in the window capturer tests in this CL:
196624: Finish implementing WGC Window Capturer and add unit tests. |
https://webrtc-review.googlesource.com/c/src/+/196624
Bug: webrtc:9273
Change-Id: I62dc53e6c3475e49ca4ae4cf6d1ef02fc8781b89
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/196623
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Austin Orion <auorion@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#32838}
For some time now, calls to EnumerateCapturableWindows could lead to a
deadlock if an application's main thread is waiting on the thread that
is running EnumerateCapturableWindows. This is because calls to
GetWindowText and GetWindowTextLength send a message to the window if
the window is owned by the current process. Since the main thread is
waiting on us, it will never reply to this message and we will hang.
This happens occasionally in Chromium when tearing down the
NativeDesktopMediaList object, e.g. when a user clicks "cancel" on
the capture target picker.
We can avoid this deadlock by checking if the window we are querying
is owned by the current process, and if it is then we must ensure it
is responding to messages before we call a GetWindowText* API.
This change also adds a unit test for this scenario. We create a
window and force it to be unresponsive by creating a deadlock, and
then call GetWindowList and (with the new changes) we should not
hang. Without the new changes to GetWindowListHandler, this test
would hang.
Change-Id: I2523cd735f96fd7ea60708c30cd22e5b525803f0
Bug: chromium:1152841
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/195365
Commit-Queue: Austin Orion <auorion@microsoft.com>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#32734}
* Add OpenOfficeApplicationHandler for MacOS and MS Windows.
* List of available sources for FullScreenWindowDetector on MacOS can include a window with empty title along with titled window for one application.
* List of available sources for FullScreenWindowDetector on MS Windows can include a window with empty title or invisible ones.
Bug: webrtc:11462
Change-Id: Id09537579ef6617dee29759c66dc9f7493166ca8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/171723
Commit-Queue: Jamie Walch <jamiewalch@chromium.org>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Reviewed-by: Wez <wez@google.com>
Cr-Commit-Position: refs/heads/master@{#32561}
The DxgiOutputDuplicator uses a vector<byte> to hold the rects
that have changed on the screen. It then iterates over the
vector to grab each rect and apply it to the updated_region.
There is vector resizing logic which checks the 'capacity' of
the vector and determines whether there is enough space for the
changed rect data. Often the 'capacity' and 'size' of the
vector are equal but that isn't always true. When the capacity
is greater than size, and the number of changed rects is high
enough, rect data will be written past the element pointed to
by (data() + size()) and this is the error that ASAN is warning
of.
The fix is to use size() instead of capacity() when determining
whether to resize the vector and as the buffer size we provide
to the Windows API. There are no other usages of this vector so
there aren't any problems caused by the size/capacity discrepancy
in the existing builds. The ASAN issue is worth fixing in case
someone comes along and decides to use the vector differently (e.g
rely on the size instead of capacity so some of the rects are
not counted).
Bug: chromium:1138446
Change-Id: I3041091423de889e0f8aabc56ece9466a3000b4f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/188900
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Joe Downing <joedow@google.com>
Cr-Commit-Position: refs/heads/master@{#32425}
The desktop_capture code logs failed HRESULTs in several places,
the problem is that it tries to use a wchar* (when a char*
is required) for the error message and doesn't display the HRESULT
in hex. This makes the error logging less useful than it could be.
Example failure: error 08406B28, with code -2005270488
In this CL, I add a simple utility function to convert a _com_error
object to a std::string whic can be logged. With this change the
output looks like this (linebreak added for CL description):
Failed to capture frame: HRESULT: 0x887A0026,
Message: 'The keyed mutex was abandoned.'
I also adjusted the formatting of a few logging statements to be
more consistent (adding '<<' operators mostly).
Bug: webrtc:12051
Change-Id: I3e88ff6f2ff079fbe210626e1e89b2b053a742a9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/188522
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Joe Downing <joedow@google.com>
Cr-Commit-Position: refs/heads/master@{#32417}
Previously windows other than the selected window will also be captured if they share the same process & thread, to allow child windows (e.g. popup menus) to be captured. This could result in child windows of other top-level windows run by the same process and thread being unintentionally captured. In attempt to err on the side of caution this check has been removed leaving some context menus and tooltips not recognized.
Bug: webrtc:11455
Change-Id: I66acc4b133baa51a128202727c655c63b07b19ab
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/176462
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Reviewed-by: Wez <wez@google.com>
Commit-Queue: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#32395}
This reverts commit 61709a3233174618d5ab46e1ee5847e4b150c7ef.
Reason for revert: Some downstream projects have issues building this
change due to the inclusion of the <windows.graphics.capture.h> header
which is newly available in the Win 10 SDK v10.0.19041.
To get around this issue for now, this change adds an off-by-default
build flag for these files. However, in the future we will want to
toggle this flag on, and the downstream projects will either need to
update their SDK versions or toggle this flag in their WebRTC clone.
Original change's description:
> Revert "Begin implementing WGC CaptureFrame"
>
> This reverts commit e820cef5340610b9beebbcb63868743b95b97fcd.
>
> Reason for revert: Breaks downstream client. I will investigate and
> get back with a suggestion to fix.
>
> Original change's description:
> > Begin implementing WGC CaptureFrame
> >
> > This change introduces the design that will allow us to deliver frames
> > synchronously to callers despite the Windows.Graphics.Capture APIs being
> > inherently asynchronous.
> >
> > We achieve this by having WindowCapturerWinWgc create and maintain a
> > WgcCaptureSession object for each window that it is asked to capture a
> > frame for. The capture session object will be the class that actually
> > uses the WGC APIs, and it will store the frames it receives in a frame
> > pool and deliver them via GetMostRecentFrame.
> >
> > The next CL will add the necessary functionality to the
> > WgcCaptureSession class.
> >
> > Bug: webrtc:9273
> > Change-Id: I44e164f4874503d8ccc8e6a210e74f9c8458f6c4
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/184220
> > Commit-Queue: Austin Orion <auorion@microsoft.com>
> > Reviewed-by: Tommi <tommi@webrtc.org>
> > Cr-Commit-Position: refs/heads/master@{#32240}
>
> TBR=mbonadei@webrtc.org,jamiewalch@chromium.org,tommi@webrtc.org,auorion@microsoft.com
>
> Change-Id: I114944357ce5be7d1e2da817703dc95d544aa99a
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: webrtc:9273
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/186045
> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
> Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#32248}
Bug: webrtc:9273
Change-Id: I9644fbf8f1fd1a84cb716176b8f14e3683a3f7cb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/186423
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32286}
This reverts commit e820cef5340610b9beebbcb63868743b95b97fcd.
Reason for revert: Breaks downstream client. I will investigate and
get back with a suggestion to fix.
Original change's description:
> Begin implementing WGC CaptureFrame
>
> This change introduces the design that will allow us to deliver frames
> synchronously to callers despite the Windows.Graphics.Capture APIs being
> inherently asynchronous.
>
> We achieve this by having WindowCapturerWinWgc create and maintain a
> WgcCaptureSession object for each window that it is asked to capture a
> frame for. The capture session object will be the class that actually
> uses the WGC APIs, and it will store the frames it receives in a frame
> pool and deliver them via GetMostRecentFrame.
>
> The next CL will add the necessary functionality to the
> WgcCaptureSession class.
>
> Bug: webrtc:9273
> Change-Id: I44e164f4874503d8ccc8e6a210e74f9c8458f6c4
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/184220
> Commit-Queue: Austin Orion <auorion@microsoft.com>
> Reviewed-by: Tommi <tommi@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#32240}
TBR=mbonadei@webrtc.org,jamiewalch@chromium.org,tommi@webrtc.org,auorion@microsoft.com
Change-Id: I114944357ce5be7d1e2da817703dc95d544aa99a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:9273
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/186045
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32248}
This change introduces the design that will allow us to deliver frames
synchronously to callers despite the Windows.Graphics.Capture APIs being
inherently asynchronous.
We achieve this by having WindowCapturerWinWgc create and maintain a
WgcCaptureSession object for each window that it is asked to capture a
frame for. The capture session object will be the class that actually
uses the WGC APIs, and it will store the frames it receives in a frame
pool and deliver them via GetMostRecentFrame.
The next CL will add the necessary functionality to the
WgcCaptureSession class.
Bug: webrtc:9273
Change-Id: I44e164f4874503d8ccc8e6a210e74f9c8458f6c4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/184220
Commit-Queue: Austin Orion <auorion@microsoft.com>
Reviewed-by: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32240}
The former was unused, the latter is replaced with the explicit C++11
deletions. The related RTC_DISALLOW_COPY_AND_ASSIGN is left for now,
it is used in a lot more places.
Bug: None
Change-Id: I49503e7f2b9ff43c6285f8695833479bbc18c380
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/185500
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32224}
For Non-DPI aware windows, we need to figure out the current DPI
and scale the content accordingly, the current behavior works ok
for until the clipped region pushes the content outside of the
frame and then the capture will fail. When this happens, the
captured frame may be blank or it could cause the browser to crash.
The issue is that the left and top clipped regions are not being
scaled along with the content (the captured window region is
contained within a larger window frame). When the clipped window
and window frame are scaled, the original offset for left and top
are not adjusted so after a certain DPI, this offset causes the
clipped region to get pushed outside of the frame which is why
the capture fails.
The fix is to scale the left and top clipped regions and translate
the clipped region accordingly. This change will only affect non-DPI
aware windows.
Bug: chromium:1083527
Change-Id: I893c2cb362cbaa01170d1e58465e43c3517139ad
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/183660
Commit-Queue: Joe Downing <joedow@google.com>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#32065}
This name change communicates that the recursive critical section
should not be used for new code.
The relevant files are renamed rtc_base/critical_section* ->
rtc_base/deprecated/recursive_critical_section*
Bug: webrtc:11567
Change-Id: I73483a1c5e59c389407a981efbfc2cfe76ccdb43
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/179483
Commit-Queue: Markus Handell <handellm@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31754}
This change implements the GetSourceList and SelectSource APIs from the
DesktopCapturer interface for WindowCapturerWinWgc. No functional
changes were made as the WGC capturer is not in use yet.
I refactored the source enumeration functionality out of the GDI
capturer and into the utils file, so both of the capturers can share
the implementation.
This change also renames the window capturers to include Win in the
name, and updates some of the out dated code style.
I've tested these changes by running the related unit tests and
applying them to a Chromium enlistment and testing on
https://webrtc.github.io/samples/src/content/getusermedia/getdisplaymedia/
Bug: webrtc:9273
Change-Id: If0ca023cb13900ab2b897aec0f38333f75a1b748
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/178960
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Austin Orion <auorion@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#31748}
This change lays the foundation for the new DesktopCapturer
implementation which will use the Windows.Graphics.Capture API.
In line with the other platform specific DesktopCapturer
implementations, I've moved the actual implementations into the win/
subdirectory and repurposed window_capturer_win.cc to instantiate
the most appropriate implementation. This will be where the WebRTC
field trial (or similar mechanism) and Windows version checks will go
when we begin to roll out the new implementation.
I've verified that the existing window capture functionality still works
by dropping these changes into the third_party/webrtc folder of a
Chromium enlistment, going to
https://webrtc.github.io/samples/src/content/getusermedia/getdisplaymedia/
and stepping through this new path under a debugger, and running the
existing WindowCapturerTests.
The next change in this series will begin to add functionality to the
new window_capturer_win_wgc files.
Bug: webrtc:9273
Change-Id: Ifc36ec69aed19563b9c20ef022760fb9c45cae25
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/178403
Commit-Queue: Austin Orion <auorion@microsoft.com>
Reviewed-by: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31690}
std::vector::reserve has the effect to reserve space in memory but does
not affect the result of size(), which keeps on returning 0. If size is
0, however, data() might either return null or not [1].
This CL fixes the use of reserve() in favour of resize() which
effectively allocates the memory in the vector and updates its size.
This way size() returns a value bigger than 0 and data() returns a valid
pointer.
[1] https://en.cppreference.com/w/cpp/container/vector/data
Fixed: chromium:1059764
Change-Id: Ida3dbe643710c6895f09b9da87b0075b7d7b28df
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/170470
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Armando Miraglia <armax@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30836}
This CL was generated by running:
git ls-files | grep ".cc" | xargs perl -i -ne 'BEGIN {undef $/}; s/("[\s\n]*<<[\s\n]*")/" "/g; print;'; git cl format
After that I manually edited modules/audio_processing/gain_controller2.cc to preserve its original
formatting.
This primary benefit of this change is a small reduction in binary size.
Bug: None
Change-Id: I689fa7ba9c717c314bb167e5d592c3c4e0871e29
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/165961
Reviewed-by: Alessio Bazzica <alessiob@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Jonas Olsson <jonasolsson@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30251}
This change avoids inadvertent capture of certain system windows (e.g.
the Start menu, other taskbar menus, and notification toasts) when
capturing a specific window on Windows.
It stops using EnumWindows for detection of overlapping windows, because
this API excludes these system windows from its enumeration. Using
FindWindowEx instead enumerates these windows.
The enumeration logic is refactored somewhat because a callback is no
longer necessary.
Bug: webrtc:10835
Change-Id: I1cccd44d6ef07f13a68e8daf2d2573d422001201
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/161153
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#30022}
* Introduce a FullScreenWindowDetector to manage routines for updating the list of sources being application agnostic, inspired by FullScreenChromeWindowDetector.
* Introduce a FullScreenApplicationHandler to make a decision about changing window to share in application specific way, inspired by FullScreenChromeWindowDetector.
* Remove FullScreenChromeWindowDetector as redundant.
* Add FullScreenApplicationHandler for MS PowerPoint and Apple Keynote on MacOS.
* Add FullScreenApplicationHandler for MS PowerPoint on Windows.
Bug: webrtc:3852
Change-Id: I06507d929308e85b882b2f8210a025afef7f26a9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/156020
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Reviewed-by: Justin Uberti <juberti@webrtc.org>
Reviewed-by: Wez <wez@google.com>
Cr-Commit-Position: refs/heads/master@{#29993}
This change adds logic to WindowCapturerWin to capture overlapping
owned/pop-up windows (e.g. menus, dialogs, tooltips). This makes window
capture behavior more consistent regardless of whether
CroppingWindowCapturerWin is used & its conditions for using crop-from-
screen capture are met (in ShouldUseScreenCapturer). (I.e. regardless
of OS version, window shape / translucency, occlusion by another
potentially top-most window, or whether the capturing app has opted in
to using the cropping capturer).
Owned/pop-up windows associated with the selected window are enumerated
then captured individually, with their contents composited into the
final frame.
This change also:
- Crops out the top window border (which exposed a bit of the background
when using the cropping capturer, and resulted in an inconsistent
appearance compared to the side & bottom borders being cropped out).
Bug: chromium:980864
Change-Id: I81c504848a0c0e6bf122aeff437b400e44944718
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/148302
Commit-Queue: Jamie Walch <jamiewalch@chromium.org>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#28922}
A cloaked window is composited but not visible to the user.
When Win10 feature 'Cortana' is enabled it creates a window
that is always invisible and its z-order is top most. Because
of that the cropping capturer detects occlusion everywhere
preventing it from capturing anything.
The solution is to ignore all cloaked windows like if
::IsWindowVisible would return false.
Bug: chromium:978885
Change-Id: Id5aa8dc81dcf4979ffb30dd808fa2a553934c6e6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/143980
Commit-Queue: Julien Isorce <julien.isorce@chromium.org>
Reviewed-by: Sergey Ulanov <sergeyu@chromium.org>
Reviewed-by: Guido Urdaneta <guidou@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28510}
In debug mode I hit the assert so this function can return 0. So
just skip the window in that case like for other desktop elements
Bug: None
Change-Id: I92abf2a1f450b677632f5eb4332ca218cfd850ec
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/143860
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28408}
And fill-in icc profile from the various window and screen capturers.
Done on WindowCapturerMac, ScreenCapturerMac, WindowCapturerX11
and ScreenCapturerX11. Follow-up CLs will do it on ScreenCapturerWinDirectx
and ScreenCapturerPipeWire.
Useful to build the gfx::ColorSpace in chromium, especially
from src/content/browser/media/capture/desktop_capture_device.cc.
We do not build the color space directly here to avoid duplicating
ui/gfx/icc_profile.h,cc code from chromium, which one implements
icc profile caching.
Bug: chromium:945468
Change-Id: Id6e3920233771e035f7578847406bf1f519dcd49
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/133580
Commit-Queue: Julien Isorce <julien.isorce@chromium.org>
Reviewed-by: Sergey Ulanov <sergeyu@chromium.org>
Reviewed-by: Brave Yao <braveyao@webrtc.org>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#27697}
As a library, WebRTC should not assume UNICODE and _UNICODE to be
defined globally.
This CL explicitly selects wide character functions and types in
order to build WebRTC with /UUNICODE and /U_UNICODE.
Bug: None
Change-Id: Ie4e2bcb4c5c34aee6f68dc7b5b54b76f088ee3e4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/128904
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Reviewed-by: Noah Richards <noahric@chromium.org>
Cr-Commit-Position: refs/heads/master@{#27313}
On Windows 10, the hidden taskbar won't be totally hidden, but having a
2 pixel margin on the screen. While a maximized app window will use up
the full screen, there will be overlapping between a hidden taskbar and
a maximized app window, which will impact window capture to that
maximized window. If the target window doesn't support GDI methods well,
the capture may be black (i.e. Chrome) or still (i.e. Word).
Because there is no solid way to identify a hidden taskbar window, we
have to make an exemption to the overlapping to a maximized window is
2-pixel X screen-width/height, which is thin enough to be noticed in
the cropping result.
Bug: chromium:838062
Change-Id: I9e0fbdf43b4445ca9fbbf5ed43bb266ae726a5b8
Reviewed-on: https://webrtc-review.googlesource.com/c/123261
Commit-Queue: Brave Yao <braveyao@webrtc.org>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#26755}
With a recent change, the webrtc::DesktopFrame is created and
initialized with 0. So it's not necessary to call memset() to
the frame again any more.
See https://webrtc-review.googlesource.com/c/src/+/97184/
Bug: webrtc:9703
Change-Id: I27d096058ead075765f4c49bf60cb8d725da1afd
Reviewed-on: https://webrtc-review.googlesource.com/c/120700
Commit-Queue: Brave Yao <braveyao@webrtc.org>
Reviewed-by: Brave Yao <braveyao@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26504}
The type rtc::scoped_refptr<T> is now part of api/. Please include it from
api/scoped_refptr.h.
More info: See: https://groups.google.com/forum/#!topic/discuss-webrtc/Mme2MSz4z4o.
Bug: webrtc:9887, webrtc:8205
No-Try: True
Change-Id: Ic6c7c81e226e59f12f7933e472f573ae097b55bf
Reviewed-on: https://webrtc-review.googlesource.com/c/119041
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26414}
This reverts commit d1208c26b1cdb536fdec942207033711101d5d26.
Reason for revert: This cl causes the crashing issue as in
chromium:916961 at starting desktop capture on Windows.
Original change's description:
> Desktop capturer: Add OnDisplayChanged callback
>
> This adds support for a new DesktopCapturer::Callback method
> OnDisplayChanged that is sent at the start of a desktop capture
> session and whenever the display geometry changes.
>
> This cl adds the basic structure to call this api at the start
> of the capture session. Currently Windows only.
>
> A follow-up cl will add support to call this whenever the display
> geometry changes.
>
> Bug: webrtc:10122, chromium:915411
> Change-Id: Ie7283be5992454180daab1a60f58a3b2efdfed56
> Reviewed-on: https://webrtc-review.googlesource.com/c/114020
> Commit-Queue: Gary Kacmarcik <garykac@chromium.org>
> Reviewed-by: Brave Yao <braveyao@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#26053}
TBR=jamiewalch@chromium.org,braveyao@webrtc.org,braveyao@chromium.org,garykac@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: webrtc:10122, chromium:915411, chromium:916961
Change-Id: Id0471e01bb90bb5accdf58262ae2b130cf343ecd
Reviewed-on: https://webrtc-review.googlesource.com/c/115433
Commit-Queue: Brave Yao <braveyao@webrtc.org>
Reviewed-by: Brave Yao <braveyao@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26095}
This adds support for a new DesktopCapturer::Callback method
OnDisplayChanged that is sent at the start of a desktop capture
session and whenever the display geometry changes.
This cl adds the basic structure to call this api at the start
of the capture session. Currently Windows only.
A follow-up cl will add support to call this whenever the display
geometry changes.
Bug: webrtc:10122, chromium:915411
Change-Id: Ie7283be5992454180daab1a60f58a3b2efdfed56
Reviewed-on: https://webrtc-review.googlesource.com/c/114020
Commit-Queue: Gary Kacmarcik <garykac@chromium.org>
Reviewed-by: Brave Yao <braveyao@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26053}
Running clang-format with chromium's style guide.
The goal is n-fold:
* providing consistency and readability (that's what code guidelines are for)
* preventing noise with presubmit checks and git cl format
* building on the previous point: making it easier to automatically fix format issues
* you name it
Please consider using git-hyper-blame to ignore this commit.
Bug: webrtc:9340
Change-Id: I694567c4cdf8cee2860958cfe82bfaf25848bb87
Reviewed-on: https://webrtc-review.googlesource.com/81185
Reviewed-by: Patrik Höglund <phoglund@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23660}
Chrome uses Windows native framework to show the notification of the
ongoing presenting. This notification window is enumerated as a
separated window which is on top most. If this window blocks the target
window, Chrome can't do the cropping and has to switch to GDI methods.
If GDI methods can't capture the target window, then capturing will fail
until the notification is dismissed.
It's hard to identify the notification window in EnumWindows() callback.
So far it works if we ignore window with no title and class name
prefixed with "Chrome_WidgetWin_" and with certain extended styles,
as so does in this CL.
Bug: chromium:847664
Change-Id: Iafabcb1f685adb91bf092475642151e1475cdf61
Reviewed-on: https://webrtc-review.googlesource.com/79742
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Brave Yao <braveyao@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23474}
While investigating some screen-capture-track-end-in-meeting issues, the
relevant rtc error logs are not uploaded to server as other webrtc
modules do, which cause great hardness to identify the reason.
This cl is to use existing trace event methods to store error logs of
desktop capturers.
Bug: chromium:831756
Change-Id: Id0c1b439f9b63916fb9417cf4e6f2b8f3c556fcd
Reviewed-on: https://webrtc-review.googlesource.com/69783
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Brave Yao <braveyao@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22866}
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}
This is a trivial change to add more logs in DX capturer components for
debugging purpose.
Bug: chromium:764258
Change-Id: I406127d838a522f0226720434e840c7163b4719d
Reviewed-on: https://webrtc-review.googlesource.com/3541
Commit-Queue: Zijie He <zijiehe@chromium.org>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#19960}
